Dynamische Provider-IPv6 am WAN-Interface / Empfohlener Umgang in Bezug auf DynDNS?

Moin zusammen,

vorweg: Ich bin kein Netzwerkprofi, und auch kein Unifi-Profi. Also habt etwas Nachsicht.

Mein "Problem": Mein ISP-Provider hat von öffentlicher IPv4 auf IPv6 mit CGNAT umgestellt. Die v6 IP ist dabei "leider" recht dynamisch, ändert sich quasi täglich.

Auf meinem UXG-Fiber (bzw. auf dem Network-Controller, der als Docker läuft) läuft ein WG-Server, so dass ich also die WAN-IP brauche (bzw. der Dyndns-Dienst, damit ich mich über einen Hostnamen connecten kann), damit die VPN-Clients sich connecten können.

Nun habe ich mittlerweile herausgefunden (siehe z. B. hier: https://community.ui.com/questions/Add-…5d-35a82684381f), dass die Unifi-DynDNS-Implementierung (welche wohl auf inadyn basiert) arge Probleme damit hat, IPv6-Adressen korrekt an Dyndns-Dienste weiterzugeben. Es funktioniert schlicht nicht. Es geht wohl (out-of-the-box) nur IPv4, was mir hier aber wegen CGNAT nicht hilft.

Ist das hier vielleicht anderen auch schon auf die Füße gefallen? Oder hat wer vielleicht schon Lösungsansätze dafür? Ich bin z. B. über ein Github-Repo gestolpert, wo jemand via Python-Script die API anzapft, um die WAN-IP zu ermitteln. Und dann könnte man das natürlich darüber auch an den gewünschten Dyndns-Anbieter weitergeben (https://github.com/gomes89/unifi-ddns6). Problem hier: So wie er das macht, scheint das nur bei der Dream Machine zu funktionieren. Ich komme über API-Abfragen zumindest aktuell bei meinem UXG Fiber noch nicht an die WAN-IP ran.

Wenn hier also jemand vielleicht ein paar Denkanstöße oder hilfreiche Tipps hätte, wäre ich dankbar.

Gruß,

Stefan

Dafür hätte der Provider gerne ganz, ganz regelmäßig immer wieder neue Münzen in sein Säckel eingeworfen bekommen.

Wenn es letztendlich dazu kommt, dann isses so. Aber im Augenblick würde ich mich gerne noch der Vorstellung hingeben, dass es auch anders geht.

ipv64 ist in der Tat der Anbieter, den ich auch schon verwende und auch gerne für ipv6-dyndns weiter verwenden würde. Derzeit habe ich es "provisorisch" über deren "Cloud-Router" konfiguriert, so dass mein UXG Fiber via Client-VPN dorthin connected. Das funktioniert auch, bedingt aber eine permanente Verbindung zwischen ipv64 und meinem UXG. Das finde ich gefühlt nicht so gut.

Mir erschließt sich allerdings technisch noch nicht, wie ich das umsetzen soll, was DoPe vorschlägt. Der "Client" wäre ja z. B. mein iPhone, mit welchem ich die VPN-Verbindung zum WG-Server aufmache. Auf dem iPhone habe ich den Hostnamen von ipv64 im VPN-Profil. Also geht die Anfrage erstmal dorthin. Und da wird doch dann "trotzdem" noch die WAN-IP vom UXG benötigt, um an den WG-Server zu kommen, oder denke ich da falsch?

Sorry, dass ich hier vielleicht mit dem Cloud-Router Verwirrung gestiftet habe. Ja, natürlich sind das zwei verschiedene paar Schuhe. Ich wollte nur (kurz) aufzeigen, dass dieser Weg zwar funktioniert, aber eben auch was ganz anderes ist. Daher: Haken dran.

Zum DDNS: Ja, genau das ist aber doch das Problem. Das UXG Fiber kann die IPv6 nicht via besagter Update-URL an ipv64 senden. Es funktioniert schlicht nicht bei einer IPv6 Adresse. Das funktioniert nur mit IPv4. Und ja, es gibt getrennte URLs für ipv4.ipv64 und ipv6.ipv64. Was aber eben hier (meiner Meinung nach) quasi irrelevant ist, weil eben das Gateway die IP technisch nicht senden kann, weil inadyn scheisse implementiert ist. Dazu gibt es auch ein dediziertes Video von Dennis bei YT, wo er das beschreibt/erklärt/bestätigt. Zumindest so, wie ich das verstehe.

Also nicht ipv64 ist das Problem, sondern das Gateway, bzw. die inadyn-Implementierung des Gateways. Und da das Gateway die IP nicht senden kann, habe ich nach möglichen Alternativen gesucht. Also z. B. die WAN IPv6 via Script "manuell" abzufragen und dann ebenfalls manuell an die API von ipv64 zu liefern.

Aber vielleicht verstehe ich das ja auch falsch? Wie gesagt, ich bin kein Profi...Letztendlich habe ich aber dyndns auf dem Gateway eingerichtet und die Update-URL (sowohl die "normale" als auch die ipv6 URL) probiert. Ergebnis: Die IP kommt bei ipv64 nicht an. Was dann auch zu besagtem YT-Video passt.

Auch auf die Gefahr hin, jetzt unhöflich zu wirken: Der Ist-Zustand von Peterfido hat nicht so richtig was mit meiner Fragestellung zu tun. Ich habe weder ne Fritte davor, noch parallel ne pfsense im Einsatz. Demzufolge ist der Beitrag auch nicht unbedingt hilfreich (sorry..). Daher würde ich auch ungerne dieses Thema hier weiter diskutieren wollen. Falls du, Tomcat, dazu Fragen hast, kannst du ihn ja bestimmt auch direkt anschreiben. Danke.

I'll try...vielen Dank für deine Hilfestellungen.

Quote from DoPe

Die IPv6 Adresse ist nur vie IPv6 erreichbar, ergo muss das Gateway den Aktualisierungrequest per IPv6 an Dennis DNS senden. Dennis hat das so gemacht, das wenn der Request korrekt aufgebaut ist, die Source IP des Requests zum Aktualisieren verwendet wird und nicht eine IP die im Request übertragen wurde. Dazu muss dein Gateway bzw, der Inadyn die WAN IP nicht kennen.

=> Das könnte eventuell der entscheidende Hinweis gewesen sein. Ich hatte für die Unifi-Komponenten (die bei mir im Management-VLAN hängen) bisher IPv6 nicht aktiviert. Habe irgendwie gedacht, dass das nicht relevant/nicht notwendig wäre, zumindest nicht für die Dyndns-Geschichte. Habe das jetzt mal aktiviert und schaue die nächsten Tage, ob die IP bei ipv64 nun upgedated wird.

Den Dyndns-Eintrag im Gateway selbst hatte ich bereits, so wie auch von dir (und in den Anleitungen von Dennis) beschrieben, angelegt.

Ergänzung: Wenn ich dich richtig verstanden habe, wird dann die IPv6-Adresse des Gateways an ipv64 übertragen und nicht die WAN-IPv6, die das Gateway vom Provider erhalten hat. Richtig? Und die funktioniert dann auch als Wireguard-Endpunkt-IP?

Ich sagte doch, ich bin kein Profi.

Dann verstehe ich allerdings nicht, warum das bei mir bisher nicht bereits funktioniert hat. Denn alles, was du empfiehlst, hatte ich bereits so umgesetzt (meiner Meinung nach). Ich habe ne v6 IP auf dem WAN Interface, ich hatte dyndns im Gateway konfiguriert und die Firewallregel existiert auch bereits. VPN auf die IP direkt funktioniert ja auch bereits bei mir. Nur eben auf den Hostnamen nicht, bzw. zumindest nicht zuverlässig, weil die WAN IPv6 halt nicht aktualisiert wird bei ipv64.

Nun gut, ich habe Dyndns nochmal neu angelegt auf dem Gateway und jetzt warte ich mal auf den nächsten Provider-IP-Wechsel.

Kleines Update: Mein ISP hat die IPv6 bisher "leider" noch nicht wieder geändert. Die letzten Tage ging das eigentlich täglich, aber da gab es auch einige Probleme mit der Leitung. Seit Donnerstag ist die v6 IP aber gleichbleibend. Ich werde also weiter abwarten müssen.

Allerdings habe ich (so wie Dennis das im Video ja auch gezeigt hat) mal auf der Shell des Gateways via curl die ipv6-Update-URL von ipv64 aufgerufen. Das hat funktioniert. Sekunden später hat ipv64 den Eintrag aktualisiert. Ich hatte spaßeshalber bei ipv64 vorher die IPv6 geändert und mit dem curl-Aufruf hat ipv64 das wieder auf die aktuelle Wan-IPv6 aktualisiert.

Der richtig manuelle Weg funktioniert also schon einmal.