Probleme mit IPv6 und DynDNS

[Der Eifelsachse]

Hallo Freunde!

Zuerst eine zugegebenermaßen etwas längere Einleitung, welche ich aber als erforderlich betrachte.
Ich betreibe seit 2019 ein, für rein private Nutzung schon etwas größeres WireGuard-Netz, bestehend aus neun aktiven in drei Ländern stationierten WG-Routern. Als Hardware nutze ich sowohl den Cudy WR3000E v1, aber auch F!B 4040 und 7412. Insgesamt sind es, einschließlich der an den entferntesten Punkten zusätzlich stationierten (voll geklonten) Reserverouter 15 derartige Geräte.
Das Betriebssystem ist selbstverständlich OpenWrt in der ggw. aktuellsten Version 25.12.3 und als DDNS-Provider wird mit sehr großer Zufriedenheit dynv6.com genutzt. Alle 9 aktiven WG-Router und die dazugehörenden Internetrouter sind alle auf einem dortigen Konto eingerichtet.
Ich lege großen Wert auf durchgehende Dualstack-Fähigkeit, schon deshalb, weil ich davon überzeugt bin, dass IPv6 das bessere Protokoll ist. Der DDNS-Provider löst mir für jedes der Geräte sauber und ordentlich den (erklärenden) Namen in seine IPv6 und IPv4 auf - wobei in der Regel fast immer die IPv6 genutzt wird. Und die Nutzer der jeweiligen Heimnetze können auch alle ihre aushäusig genutzten Geräte wie Smartphones und Laptops direkt mit ihrem (oder bei Bedarf auch meinem) Hausnetz verbinden.
Dieses ganze Konstrukt hat sich alle die Jahre sehr gut bewährt und läuft und läuft und läuft (wie mal zum Auto einer bekannten dt. Marke gesagt wurde).

Mein "Problerm":
Ich nutze von Anfang an für die internen Tunnel je Verbindung eine IPv4 (aus einem sonst nicht genutzten Netzbereich des jeweiligen Heimnetzes bspw. 192.168.20.0) und eine durch ULA bereitgestellte IPv6, bspw. fd00:: .
Jetzt stellte ich zur Zufall (beim Betrachten des Logfileviewers des internen DDNS-Clients) fest, dass ab und an (nicht immer!) versucht wird, eben jene ULA an Stelle der "offiziellen" IPv6 (200: ) an den DDNS-Provider zu melden - was selbstverständlich fehlschlägt. Der DDNS-Client nimmt also die falsche, nicht routingfähige IPv6.

Das sieht dann im Log so aus:

 161054       : Update needed - L: 'fd00:0000:0000:0000:82af:caff:fe82:18fb' <> R: '2001:09e8:4581:7000:82af:caff:fe82:18fb'
 161054 ERROR : No or private or invalid IP 'fd00:0000:0000:0000:82af:caff:fe82:18fb' given! Please check your configuration
 161054 ERROR : No update send to DDNS Provider
 161054       : Waiting 600 seconds (Check Interval); Next check at 2026-05-08 16:20

Betrieblich ist diese Störung nicht zu bemerken. Schlimmstenfalls wird mal kurzzeitig IPv4 genutzt, aber meistens bleibt es trotzdem bei IPv6. Und irgendwann erkennt der Client wieder die richtige IPv6.

Ich habe die Einstellungen des DDNS-Clients schon x-mal überprüft (kann sie bei Bedarf, wenn mir jemand helfen möchte, gern auch posten). Und ja, ich schließe einen Level 8-Fehler auch keinesfalls aus.

Und nun bitte ich die echten Wissensträger um Unterstützung.
Freundlicher Grüße aus der Eifel!

 

[Barungar]

So aus der Ferne würde ich sagen, dass es ein Fehler des DynDNS-Clients ist.
Ich weiß allerdings nicht, welchen DynDNS Client Du verwendest. Läuft er direkt auf den WG-Routern?

 

[Der Eifelsachse]

Danke @Barungar für deine Antwort.
Ja, mir ist schon klar, dass es am DynDNS-Client liegt bzw. liegen muss. Dieser lauscht ja an der IPv6-Schnittstelle (LANv6) erkennt die an den DDNS-Provider zu meldende IPv6. Es liegen ja dort immer zwei IP an.
Nur verstehe ich nicht, warum er einmal die 2001: ... und dann wieder einmal die ULA erkennt und versucht, diese zu melden. Und irgendwann erkennt er die richtige IP und meldet diese.
Ich muss nicht (mehr) alles verstehen - würde es aber gern.

 

[Barungar]

Woher bezieht er die IPv6? Ist er selbst direkt der Router, der an Wide Area Network hängt?
In dem Fall sollte nämlich eigentlich keine ULA an dem Interface hängen?
Oder liegt er hinter einem anderen Router?

 

[Der Eifelsachse]

An allen neun Standorten gibt es einen vorgeschalteten (Fiber- oder DSL-) Router für den Internetzugang. Dieser beliefert alle Geräte des jeweiligen Heimnetzes mit den für den Betrieb benötigten IPv4 und IPv6. Und natürlich auch mit den ULA.
Ich würde niemals auf einem direkt "im bösen Netz hängenden Router" ein VPN betreiben - hat was mit meiner ehemaligen beruflichen Tätigkeit zu tun, wo das alles auf einem beträchtlich (!) höheren Niveau stattfand.

Ich wiederhole mich noch einmal: Das VPN funktioniert über alle eingerichteten Tunnel immer perfekt und stabil. Es wird nur "ab und an" versucht, eine ungeeignete IPv6, eben die ULA, an den DDNS-Provider zu senden. Sollte die vereinbarte IPv6 vorher wirklich ungültig werden, nutzt das System eben IPv4.
Ich konkretisiere deshalb meine als Problem gestellte Frage etwas: Kann ich irgendwie vermeiden, dass der DDNS-Client die ULA als geeignete IPv6 erkennt und versucht, diese weiterzumelden?
Klar könnte ich irgendwie die Firmware patchen und eine entsprechende Bedingung zur Auswahl der IP einbauen - aber das möchte ich ganz bewusst nicht.

OK?

 

[Barungar]

Sorry, das ich erst jetzt antworte. Ich war heute über den Tag nicht am PC.

Ich sehe da jetzt zwei Möglichkeiten das "zu lösen". Erstmal ist mir klar, dass das kein "vernichtender Fehler" ist. Es ist halt nur so, dass in diesem Moment der jeweilige WG-Server über IPv6 nicht erreichbar ist, das wäre besonders blöde an einem DS-Lite Anschluss.

Möglichkeit 1)
Sich beim "Hersteller" des DynDNS-Clients "beschweren" und den Bug melden, denn ein Bug ist es ganz offensichtlich, da eine ULA nicht ins Internet geroutet wird, also hat sie auch nix im öffentlichen DNS zu suchen. Und dann das Update für den DynDNS Client installieren. Eventuell man auf dem Gerät mittels Scripting einen "work-around" schalten.

Möglichkeit 2)
Am "Hauptrouter" wird die ULA-Funktion deaktiviert, somit gibt es im LAN nur noch GUA und LLA. Damit kann dann keine ULA mehr ins öffentliche DNS gemeldet werden vom DynDNS-Client. ULA haben im Heimnetz in den meisten Fällen keine Nutzen für den Anwender. Also zumindest nicht für "Otto-Normal-User". Windows Clients ignorieren ULA sowieso. Die Precedence im Windows IP-Stack für eine ULA-IPv6-Adresse liegt sogar noch hinter den IPv4-Adresse. Der Windows IP-Stack hat die Reihenfolge IPv6-GUA, IPv4 und IPv6-ULA.

 

[Der Eifelsachse]

Danke für für deine Antwort zu später Stunde. (Ja, in meinem Alter gilt das schon als späte Stunde )

Beide Antworten haben was für sich. Gut, da wir alle schon sehr lange bei unseren Providern sind (20 Jahre ++) haben wir auch alle echten Dualstack. Außerdem habe ich das Gefühl, dass, wenn eine Gegenstelle mit IPv6 kommt, die andere Seite irgendwie "nachzieht", also intern überf den Tunnel doch die richtige IPv6 durchgereicht wird. Es kam ja nie zu einem Abriss. Aber du hast ja schon richtig erkannt, dass das kein "vernichtender Fehler" ist.

Deine Möglichkeit 1) ist genau das, was ich in meinem letzten Satz in #5 meinte. Ich werde versuchen, herauszubekommen, wer der Entwickler des OpenWrt-eigenen DDNS-Clients ist und diesen bitten, mal über das Problem nachzudenken. Daraus könnte, wenn dieser mitspielt, der Königsweg entstehen.
Was deine Möglichkeit 2) betrifft, muss ich erst einmal sehr gründlich darauf herumdenken. Was Windows betrifft, habe ich ja etwas in meiner Signatur geschrieben.

Einen schönen Abend noch - und ich gehe jetzt in den Stromsparmodus.

 

[Barungar]

Ich habe mich nie mit OpenWrt befasst, aber gerade mal kurz gegoggelt. Grundsätzlich kann man den OpenWrt DynDNS-Client auf option enabled '0' setzen. Damit ist die DynDNS-Konfiguration im System aber nicht scharf. Nun schreibt man ein eigens kleines Script, das prüft, ob sich die GUA geändert hat. Falls ja, triggert das eigne Script den DynDNS-Client. So kann das eigene Script prüfen, ob es eine gültige GUA gibt. Ich vermute nämlich einfach, dass das Problem aus zwei Faktoren besteht. Einmal natürlich, dass der DynDNS Client die ULA nicht verhindert und andererseite "denke" ich, dass es eine Race-Condition vorliegt. Und zwar haben wir einen Prefix-Wechsel vom Provider. Das alte Prefix wird durch RA für ungültig erklärt, und das neue Prefix ebenfalls per RA kommuniziert. Nun kann es wenige Milisekunden geben, in denen das alte Prefix bereits deprecated ist, aber das neue Prefix noch nicht preferred. Das Device hat somit im dem Moment "nur" LLA und ULA... das könnte den DynDNS Client "verleiten" in dem Moment das Update auf die ULA zu senden.