ich habe seit einer Weile eine DynDNS bei ipv64 und auch eine Portweiterleitung zu meinem Homeserver eingerichtet. Diese Weiterleitung dient dazu, per SSH “nach Hause” zu kommen. Seit ein paar Tagen funktioniert das nicht mehr. ssh mit -v zeigt mir folgendes:
dietpi@DietPi:~$ ssh -i id_ed26452 -p 53925 root@meine_domain.ipv64.de -v
Warning: Identity file id_ed26452 not accessible: No such file or directory.
OpenSSH_8.4p1 Debian-5+deb11u5, OpenSSL 1.1.1w 11 Sep 2023
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to meine_domain.ipv64.de [1234:::1] port 53925.
debug1: Connection established.
debug1: identity file /home/dietpi/.ssh/id_rsa type -1
debug1: identity file /home/dietpi/.ssh/id_rsa-cert type -1
debug1: identity file /home/dietpi/.ssh/id_dsa type -1
debug1: identity file /home/dietpi/.ssh/id_dsa-cert type -1
debug1: identity file /home/dietpi/.ssh/id_ecdsa type -1
debug1: identity file /home/dietpi/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/dietpi/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/dietpi/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/dietpi/.ssh/id_ed26452 type 3
debug1: identity file /home/dietpi/.ssh/id_ed26452-cert type -1
debug1: identity file /home/dietpi/.ssh/id_ed26452_sk type -1
debug1: identity file /home/dietpi/.ssh/id_ed26452_sk-cert type -1
debug1: identity file /home/dietpi/.ssh/id_xmss type -1
debug1: identity file /home/dietpi/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.4p1 Debian-5+deb11u5
Wenn ich vom gleichen Client ohne den Weg über ipv64 auf den Homeserver zugreife, klappt es. Auch mit dem ssh-key. Daran sollte es also nicht liegen.
Also habe ich heute Morgen die Portweiterleitung bei ipv64 entfernt und neu eingerichtet. Jetzt bekomme ich folgende Meldung:
dietpi@DietPi:~$ ssh -i id_ed26452 -p 58890 root@meine_domain.ipv64.de -v
Warning: Identity file id_ed26452 not accessible: No such file or directory.
OpenSSH_8.4p1 Debian-5+deb11u5, OpenSSL 1.1.1w 11 Sep 2023
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to meine_domain.ipv64.de [1234:::1] port 58890.
debug1: connect to address 1234:::1 port 58890: Connection refused
debug1: Connecting to meine_domain.ipv64.de [ipv4_address] port 58890.
debug1: connect to address ipv4_address port 58890: Connection refused
ssh: connect to host meine_domain.ipv64.de port 58890: Connection refused
Wo muss ich noch schrauben, dass die Portweiterleitung wieder funktioniert?
Meinst du den CDN Portmapper mit Portweiterleitung?
Funktioniert aktuell auch bei mich nicht mehr.
Üblicherwese hat es immer gereicht in so einem Fall dann unter CDN Service → CDN Options → Set DNS Records den Proxy zu disablen und wieder zu enablen.
Das funltioniert seit heute leider auch nicht mehr als Workaround, wenn das CDN die Zwangstrennung und Neuverbindung in der Nacht nicht mitbekommen hat.
Ich habe das gleiche Problem seit gestern 14 Uhr ca. (Healthcheck hat es korrekt gemeldet
Da ich in der Vergangenheit bereits mehrfach das Problem hatte, habe ich den Server gewechselt, dass sonst geholfen hat. Diesmal war es wirkungslos..
Alles resettet und sogar einmal komplett gelöscht und neu angelegt. Ergebnis: Gleiches Problembild.
Dabei ist mir aufgefallen, dass die Übersichtsseite der CDN zwar sagt Cert erfolgreich etc. aber in der Detailansicht steht noch Cert Issued.
Gibt es hier Anstrengungen etwas dagegen zu tun oder sollte man sich anderweitig um eine Lösung kümmern? Bei mir ist hier seit zwei Tagen der CDN komplett defekt und offenbar lässt sich das auch mit keiner Aktion wiederbeleben.
Ich vermute das hat mit den vielen DDos und anderen Angriffen zu tun. Dennis wird sich bestimmt zeitnah darum kümmern. In einem anderen Beitrag Stand etwas von einer kurzen eingeschränkten Verfügbarkeit.
Genau. In diesem Beitrag hat er gestern geschrieben, dass er noch 48h außer Landes ist.
Demzufolge sollte er morgen wieder zurück sein und wird sich sicherlich zeitnah um die Angelegenheit kümmern.
Tatsächlich empfinde ich es auch ein wenig als unbefriedigend, dass man sich nicht vollends auf IPv64 verlassen kann. Das Ganze hat sehr gute Ansätze, läuft aber (noch?) nicht komplett rund.
Weiterleitung funktioniert bei mir wieder - Nur das Certificate ist das selfsigned von IPv64 und nicht das von LetsEncrypt.
Denke da liegt entweder eine Sperre vor (zu viele Anfragen) oder ein Fehler im Automatismus?
Vllt. hast Du das anders verstanden als ich es meinte. Ich werfe Dir keinerlei Absicht vor. Du machst einen super Job, das habe ich Dir auch schon mal in einer persönlichen Mail geschrieben.
Dennoch musst Du zugeben, dass IPv64 nicht rund läuft und aktuell viele Ausfälle hat - aus welchem Grund auch immer. Und bei DDoS kann man wenig machen, das ist mir auch klar. Aber ich finde, dass Du Deine Nutzer, also Deine Kunden, zumindest informieren könntest. Anhand der Reaktionen hier im Board siehst Du ja, dass keiner weiß, was Sache ist. Ein kurzer Hinweis auf der Startseite von ipv64.net oder ein angepinnter Post hier im Forum, in dem der aktuelle Status erläutert wird, wäre sicherlich hilfreich.
Kann ich leider nicht bestätigen. Vorgestern (16.9.) um 19:00 hat es noch funktioniert. Seither ist keine VPN-Verbindung zu meiner FB mehr möglich. Weder aus dem Mobilfunknetz noch aus div. WLANs hinter DSL oder Glasfaser.
Und dieser „Wackelkontakt“ wird auch leider bleiben, solange die DDoS andauern oder ständig wieder aufgenommen werden. Man könnte glatt auf den Gedanken kommen, die Geschäftsidee von Dennis gefällt dem einen oder anderen Konkurrenten mit ähnlicher Geschäftsidee nicht …
