Kann es sein dass das DynDNS nach dem erneuten Angriff noch nicht richtig funktioniert?
Äussert sich bei mir damit, dass die F!B korrekt die IPv6 Adresse (habe Glasfaser mit DSLite) an ipv64 übermittelt. Also IPv6 Adresse in F!B = IPv6 Adresse unter meiner DynDNS Domain bei ipv64. Aber: dig AAAA auf die dynDNS Adresse z.B. über Quad9 oder Google DNS liefert eine andere IPv6 Adresse. Komischerweise passt die IPv4 Adresse über das CDN. Da mein Smartphone über O2 aber mit IPv6 Adressen arbeitet, kriege ich keine Wireguard Verbindung zu meiner F!B mehr hin. Desweiteren ist mein eingerichteter Healthcheck seit dem DDOS Angriff ebenfalls down.
Kann ich noch was ändern bzw. neu anlegen so dass es wieder funktioniert?
Könnte es sein, dass die AAAA auch auf die die IPv6-Adresse des CDN passt?
was haste denn konfiguriert?
- CDN-Portmapper oder
- CDN-Reverse-Proxy?
Mit dem CDN-Reverse-Proxy kann es gar nicht klappen und mit dem CDN-Portmapper nur bei Verwendung des nun gemappten Ports.
CDN-Reverse-Proxy ist disabled. Und jetzt habe ich auch verstanden was Du meinst: ich habe beim Portmapper die Option “IPv4 only” aktiv. Also sollte die für das DynDNS von der F!B gemeldete IPv6 Adresse gleich der CDN IPv6 Adresse sein. Im GUI ist sie das auch. Nur wenn man die DynDNS Domain abfragt kommt eine andere IPv6 Adresse. Ich löse das CDN mal kurz komplett auf und lege es neu an. Mal sehen was das bringt.
Bis zum DDOS Angriff hat es auch problemlos funktioniert.
OK, das war’s. Einmal CDN Proxy raus und wieder rein hat es gebracht. Die über z.B. Quad9 aufgelöste IPv6 Adresse entspricht wieder der meiner F!B und Wireguard geht wieder.
Jetzt habe ich mich auch wieder erinnert warum ich nicht den “Full-Proxy” gewählt habe. Das funktioniert zwar, aber der HealthCheck schlägt dann fehl, weil die IPv6 Adresse meiner ipv64.net Domäne eben nicht die tatsächliche IPv6 Adresse der F!B ist. Gibt es dazu eine Lösung?
Also die Option “IPv4 only” aktiv ist für dich nicht die optimale Lösung.
Das Problem bei Wireguard und CDN-Portmapper ist doch dann der abweichende Port. Auf der Fritte hast du z.B. den UDP-Port 51820. Der Portmapper weist dir nun aber einen anderen Port zu, z.B. UDP-Port 54321.
Solange du nun per IPv6 direkt und ohne Portmapper die Wireguard-Verbindung zu deiner Fritte herstellen kannst ist das okay. Was aber, wenn du im Ausland bist, im Hotel-WLAN, etc. und dort im Roaming-Netz oder WLAN nur IPv4 verfügbar ist? Dann würden dein Smartphone per IPv4 die Verbindung aufbauen wollen, aber eben zu UDP-Port 51820 statt des CDN-Ports UDP 54321.
Und schon bekommst du keine Verbindung hin.
Nope. Der CDN Portmapper mappt den gleichen Port auf die Fritte. Bei Ports über einem bestimmten Wert ist Quellport = Zielport. Das funktioniert schon so wie es soll. In meinem Fall kommt der Wireguard Client von außen (egal ob v4 oder v6) am Port 52852 an. Und der CDN Proxy mappt auf die tatsächliche IPv6 der F!B auf Port 52852. Das wurde von Dennis auch in seinem YT Video so gezeigt. Sonst wäre die ganze CDN Proxy Sache sinnlos. Man macht die CDN Proxy Sache ja nur, weil manche ISPs über DS Lite arbeiten, der Router also keine öffentliche IPv4 Adresse hat.
Beim Full-Proxy Mode könnte man natürlich auch über tatsächlich unterschiedliche Ports gehen. Oder auch nicht. Wäre dann egal. Aber wie gesagt, im Full Proxy funktioniert der Health Check dann nicht mehr. Dafür suche ich noch eine Lösung.
Glück gehabt. Klappt nur dann, wenn der Quellport auch als Zielport noch frei ist. Üblich sind bei Wireguard ja die Ports ab 51820 aufwärts. Ich verwende in meiner pfsense 51820 und 51821. Waren beide natürlich nicht mehr frei und daher hat der Portmapper mir andere Ports zugewiesen.
Aber auch dafür gibt es eine Lösung, die sogar den Healthcheck bedenkt. Zwei DynDNS-Updates (bei Fritten durch Leerzeichen getrennt) für die eigentliche Domain und zudem die Domain mit Domain-Prefix. Die Domain geht ans CDN. Der Healthcheck wird an die Domain mit Domain-Prefix gerichtet, also z.B. Fritzbox.DeineDomain.ipv64.net.
Was heißt Glück gehabt? Ich habe nur den einen Portmap, also klappt das in meinem Fall immer.
Danke für den Tipp mit dem Domain-Prefix für den Health-Check. Werde ich mal ausprobieren.
Also den Tipp mit dem zweiten DynDNS in der F!B und neu angelegter Subdomain/Prefix habe ich nicht hinbekommen. Obwohl laut Anleitung der F!B zwei “connection strings” mit Leerzeichen getrennt möglich sein sollen, klappt das bei mir nicht. Er updated dann nur mit dem zweiten Teil des Strings. Aber mir ist noch eine andere Möglichkeit eingefallen: myFritz. Ist im Prinzip ja auch ein DynDNS Anbieter. Da habe ich die F!B drin, weil nur damit das Wetter auf den Fritz!Phones funktioniert. Ich habe einen DS Lite Anschluß. Somit liefert die myfritz Domain auch nur eine IPv6 Adresse. Nachdem ich den Healthcheck auf die MyFritz Domäne umgestellt habe, habe ich das CDN auf Full-Proxy umgestellt. Jetzt klappt das so wie es soll. Healthcheck geht über meine myfritz Domain einwandfrei.
Trotzdem ist gestern Morgen bei der täglichen Trennung und Neuverbindung meines Internetanschlusses es doch wieder zu einem Fehler gekommen. Neue IPv6 Adresse wird einwandfrei im DynDNS aktualisiert. Aber bei den DNS Servern (Quad9, Google, … und auch beim eigenen ipv64 DNS Server) wird die Änderung nicht rausrepliziert. Ach ja, das war noch die alte Methode mit CDN nur auf IPv4. Somit sollte heute Morgen DynDNS IPv6 und CDN IPv6 noch gleich sein. Inzwischen ist natürlich durch Full Proxy DynDNS IPv6 und CDN IPv6 unterschiedlich. Mal sehen was dann morgen nach der Verbindungstrennung passiert.
Wozu auch? Deine DynDNS-Adresse sollte ja jetzt nicht mehr auf die IPv6-Adresse am WAN-Interface der Fritte zeigen, sondern auf die IPv6-Adresse des CDN-Servers. Ganz genau so wie die IPv4-Adresse. Bei Full-Proxy (also IPv6 und IPv4 via CDN) macht alles andere doch auch gar keinen Sinn mehr.
Ja, richtig. Aber heute morgen war ich noch auf IPv4 only Proxy. Und da hat es eben nicht funktioniert.