Problem, DDNS-Updater: DOMAIN oder DOMAIN_KEY falsch?

Hallo IPV64.net Experten,

zunächst einmal finde ich euer DynDNS-Angebot echt klasse und habe mich auch explizit dafür entschieden, diesen deutschen Dienst bei mir zu nutzen. Jetzt habe ich aber leider ein Problem, welches ich nicht geöst bekomme.

Kurz zu meinem Setup: Ich habe einen kleinen PC als Homeserver mit Open Media Vault 7 und dem Docker-Compose-Plugin aufgesetzt. Auf diesem PC läuft ein Docker Container mit NextCloud. Diese NextCloud möchte ich aus dem Internet erreichbar machen. Der PC hat vier LAN-Ports, von denen ich drei zu einer LAN-Brücke „br0“ gebündelt habe über die der Traffic zu meiner Fritz!Box läuft. In der FritzBox habe ich eine entsprechende Port-Weiterleitung eingerichtet. Ich nutze in meinem Netzwerk IPv6 und IPv4 parallel (wobei ich nur per DS-Lite angebunden bin).

Im Docker Container der NextCloud habe ich einen Caddy laufen, der die HTTPS-Portanfragen aus dem Internet an NextCloud weitergibt. Ein weiterer separater Docker Container macht alle 15 Minuten einen Check der eigenen IP-Adressen und übermittelt diese an IPV64.net.

Nach einigem Tüfteln, Testen, Debuggen (und auch Fluchen) hatte ich dieses Setup gestern Abend ans Laufen gebracht. Alles funktionierte wie erwartet. Leider hat die Sache aber die DSL-Zwangstrennung in der Nacht nicht überlebt. Problem war, dass mir mein Provider eine IPv4 zugeteilt hat, die auf „.0“ endete und es scheint, als ob IPV64.net damit nicht umgehen kann. Um das zu lösen, habe ich die FritzBox neu verbinden lassen und habe danach auch eine andere IP-Adresse (nicht mehr mit „.0“ am Ende) erhalten.

Um schnell testen zu können, ob das funktioniert, habe ich den Docker Container mit dem DDNS-Checker mit einem Klick auf „down“ gestoppt und gleich wieder mit einem Klick auf „up“ neu gestartet. Dann wurde es problematisch. Der Docker-Log dieses Containers zeigt mir nun an, dass im Compose-File die Variablen DOMAIN oder DOMAIN_KEY falsch seien und der Container daher gestoppt wurde. Meine NextCloud ist nun auch über die IPV64-Adresse nicht mehr erreichbar. Selbst ein manuelles Eintragen der neuen IPv6 meines Computers auf der Webseite von IPV64.net bringt keine Abhilfe.

Weshalb zeigt mir der DDNS-Container nun diesen Fehler an? Wie kann ich ihn berichtigen? Die Angaben der beiden Variablen sind richtig und passen zu den Angaben, die ich auf der IPV64.net-Webseite sehen kann.

Vielen Dank für eure Hilfe im Voraus!

Viele Grüße
Mic.

Und warum nutzt du dann nicht die Fritte zum Update des IPv6-Prefixes und arbeitest bei IPv6 mit AAAA-Record’s im Format: „Interface-ID“ oder „EUI-64 MAC“? Wegen DS-Lite sollte IPv4 bei ipv64 eh deaktiviert (Ignore IPv4 on the updater [CG-NAT / DS-Lite]) werden.

Guten Morgen Adler,

danke für deine Rückmeldung. Ich habe „ignore IPv4“ in IPV64.net eingestellt und nur einen IPV6 (AAAA) Record eingestellt. Dass man das Update auch über die FritzBox machen kann, wusste ich nicht. Ich hatte gelesen, dass die Option DynDNS in der FritzBox nur dazu dient, der FritzBox selbst eine Web-Adresse zu geben. Das möchte ich aber nicht. Nur meine NextCloud soll über das Web erreichbar sein.

By the way… meine eigentliche Frage ist damit nicht beantwortet. Weshalb liefert der Docker Container immer eine Fehlermeldung?

pc:~# docker logs -f ddns-ipv64
==============================================================================================
================================ START DDNS UPDATER IPV64.NET ================================
==============================================================================================
================  ######    ########     ##     ##     #######     ##    ##   ================
================    ##      ##     ##    ##     ##    ##     ##    ##    ##   ================
================    ##      ##     ##    ##     ##    ##           ##    ##   ================
================    ##      ########     ##     ##    ########     ##    ##   ================
================    ##      ##            ##   ##     ##     ##    #########  ================
================    ##      ##             ## ##      ##     ##          ##   ================
================  ######    ##              ###        #######           ##   ================
==============================================================================================
2025-06-29 10:55:59  DOMAIN      - Sie haben eine DOMAIN gesetzt
2025-06-29 10:55:59  DOMAIN      - Deine DOMAIN xxxxxxxxxxxxxxxxxx.ipv64.de
2025-06-29 10:55:59  DOMAIN KEY  - Sie haben einen DOMAIN Key gesetzt
2025-06-29 10:55:59  SHOUTRRR    - Sie haben keine SHOUTRRR URL gesetzt
2025-06-29 10:55:59  FEHLER !!!  - Die Angaben sind falsch  gesetzt: DOMAIN oder DOMAIN KEY
2025-06-29 10:55:59    INFO !!!  - Stoppen sie den Container und Starten sie den Container mit den richtigen Angaben erneut
==============================================================================================

Ich habe mir jetzt so geholfen, dass ich statt dem Docker-Tool ein eigenes kleines SH-Skript erstellt habe. Diese Skript wird als CronJob ausgeführt und prüft alle 15 Minuten, ob sich meine IPv6-Adresse geändert hat und wenn ja, dann öffnet es den Update-Link von IPV64.net, um die IP zu aktualisieren.

Das funktioniert aktuell. Dennoch scheint das Docker-Tool (welches von IPV64.net selbst released wurde??) offensichtlich einen Fehler zu verursachen.

Danke und Grüße
Mic.

Nun, in den Anleitungen wird ja erklärt wie das mit der Fritzbox geht. Für dich wäre relevant: Mit AVM Fritzbox IPv6-Prefix Updaten.

Dann verändere die Update URL aus Mit AVM Fritzbox IPv6-Prefix Updaten wie folgt:
https://ipv64.net/nic/update?key=1234567890abcdefgh&domain=DOMAINNAME.ipv64.net&ip6lanprefix=<ip6lanprefix>
So würde nur der IPv6-Prefix des LAN’s der Fritte aktualisiert werden. Der IPv6-Prefix sind die ersten /64 der /128 IPv6-Adresse. Die zweiten /64 der /128 IPv6-Adresse würden aus der „Interface-ID“ oder „EUI-64 MAC“ gebildet werden.

Generell haben alle Updates die du von Clients hinter der Firewall oder dem Router machst einen Nachteil:
Diese Clients bekommen die Zwangstrennung und den Wechsel des IPv6-Präfixes nicht unmittelbar mit. Das ist der Firewall oder dem Router vorbehalten. Im Zweifel bemerken die Clients das erst nach Ablauf der DHCPv6-Leasetime und Neubezug einer IPv6-Adresse und erst dann würde auch der alle 15 Minuten ausgeführte Cronjob greifen können. Denn erst nach Erneuerung der geänderten IPv6-Adresse hat der Client ja auch den neuen Prefix und kann darauf reagieren.

Insofern ist die Lösung über die Firewall oder den Router immer die schnellere und daher bessere Wahl.

Hallo,

danke für den Hinweis. Ich habe jetzt den langen Update-Link aus der Anleitung unter „Mit AVM Fritzbox IPv6-Prefix Updaten“ bei meiner FritzBox eingetragen. Die in der Anleitung beschriebene Option " DynDNS-Anbieter: Benutzerdefiniert" gibt es bei mir nicht (mehr). Den Rest habe ich so eingetragen, wie in der Anleitung.

Der von dir modifizierte, kürzere Update-Link ist für ein Update der FritzBox selbst also nicht für mich geeignet…?

Mein Link: https://ipv64.net/nic/update?
image

Wann macht die FritzBox (automatisch) ein Update? Wie sehe ich, ob es geklappt hat?

Ich habe das in der FritzBox mal so eingerichtet, lasse aber sicherheitshalber im Hintergrund mein Update-Check-Skript weiter laufen.

Das Docker-Tool verursacht weiterhin die gleiche Fehlermeldung.

Danke und Grüße
Mic.

Du verwirrst mich. Du wolltest doch gerade nicht, dass die Fritte selbst per DynDNS erreichbar ist. Die ipv64-Update URL besteht aus drei Teilen.
&ip=<ipaddr>&ip6=<ip6addr>&ip6lanprefix=<ip6lanprefix>

  • &ip=<ipaddr> aktualisiert die IPv4-Adresse des WAN’s der Fritte
  • &ip6=<ip6addr>aktualisiert die IPv6-Adresse des WAN’s der Fritte
  • &ip6lanprefix=<ip6lanprefix> aktualisiert den IPv6-Prefix des LAN’s der Fritte

Wenn das ernst gemeint war, dann können &ip=<ipaddr> und &ip6=<ip6addr> also weggelassen werden. &ip=<ipaddr> kann in jedem Fall weggelassen werden, da du nur per DS-Lite angebunden bist.

Hast dir noch nie die Weboberfläche der Fritte etwas genauer angesehen? Das sieht man bereits auf der Übersichtsseite der Fritte neben DynDNS. Dort steht dann So etwas wie DynDNS: aktiviert, XXXXXX.XXXXXXX.de, IPv4-Status: erfolgreich angemeldet, IPv6-Status: erfolgreich angemeldet

Guten Abend,

dann haben wir es geschafft, uns gegenseitig zu verwirren. Ich hatte es so verstanden, dass ich für die FritzBox den Update-Link aus der Anleitung nehmen soll. Und ja, er hat nicht funktioniert. Nachdem die FritzBox das Update gemacht hat, war diese über meine IPV64.de-Adresse erreichbar… also das, was ich eben nicht wollte.

Mein kleines Update-Skript macht aber bisher seine Dienste recht zuverlässig.

Danke für den Hinweis zur WebGUI der FritzBox. Ist DynDNS deaktiviert, fehlt der Eintrag auf der Übersichtsseite. Aktiviert man DynDNS, taucht er auf einmal auf. Daher war er mir nicht aufgefallen. Nun weiß ich aber leider noch immer nicht genau, wie der Link in der WebGUI der FritzBox aussehen müsste, damit sie meine NextCloud-Adresse auf dem Linux-PC aktualisiert? So in etwa vielleicht?

https://ipv64.net/nic/update?key=********************************&domain=**********.ipv64.de

Aber weshalb aber der offizielle Docker für das IPV64.net Update nicht funktioniert, kann noch niemand beantworten.

services:
  ddns-ipv64:
    image: alcapone1933/ddns-ipv64:latest
    container_name: ddns-ipv64
    restart: unless-stopped
    environment:
      - TZ=Europe/Berlin
      - CRON_TIME=*/15 * * * *
      - DOMAIN_KEY=********************************
      - DOMAIN_IPV64=**********.ipv64.de

Vielen Dank und viele Grüße
Mic.

Er müsste so aussehen, wie ich ihn für dich bereits vor zwei Tagen erstellt und geposted hatte:

Lesekompetenzen scheinen nicht so deine Stärke zu sein?

Nachtrag: und daher zitiere ich mich gleich nochmal selbst, damit du alles hier in einem Post hast

Denn das mit dem IPv6-Prefix klappt nur zusammen mit der „Interface-ID“ oder „EUI-64 MAC“ des NC-Servers.

Der Rest ist einfach Anleitung lesen und eigene Denkleistung zur Kombination dieser beiden Teile, die dann eine vollständige /128 IPv6-Adresse der NC ergeben.

Im offiziellen Blog wird einiges erklärt zum Thema Prefix Update.

Hi @Dennis_Admin ,

cool und vielen Dank, dass du dich eingeklinkt hast. Der lange Update-Links unter deiner Anleitung funktionieren wenigstens, anders als das, was der Vogel in seiner liebenswürdigen Art als Link gepostet hat. Habe es mehrfach versucht… Ergebnis ist immer wieder gleich falsch.

Mit dem Hier werde ich es jetzt mal ausprobiere:

Prefix Update für die FRITZBOX
https://ipv64.net/nic/update?key=123456789abcdefgh&ip=<ipaddr>&ip6=<ip6addr>&ip6lanprefix=<ip6lanprefix>

Nur verstehe ich nach wie vor nicht, wieso das Docker-Tool von einem Tag auf den nächsten nicht mehr funktioniert (siehe Fehlermeldung oben). Ist dieser Docker überhaupt von dir/euch?

Wobei ein Update des Präfix schon mal eine gute Sache ist. Ein Update von Präfix und Suffix (Host-ID) hätte aber den Vorteil, dass, wenn sich mal die Host IPv6 durch einen dummen Zufall ändert, diese auch mit updated wird.

Danke dir und Grüße
Mic.

Nee, hat doch wieder mal nicht geklappt. Nach einer Weile hat sich dann doch die WebGUI der FritzBox wieder vorgedrängt.

Da du nicht verrätst, was immer wieder gleich falsch gewesen sein soll, kann man nur Vermutungen anstellen: Der Teil &domain=DOMAINNAME.ipv64.net entspricht nicht DEINEN tatsächlichen Verhältnissen und wurde von dir nicht entsprechend angepasst. Es fehlt also noch immer an eigener Denkleistung, denn ich kenne deine tatsächliche Domain ja nicht.

Auch hier wieder keine konkrete Fehlermeldung. Auch hier daher nur wieder eine Vermutung:
Weil die Fritte eben dem IPv6-Präfix auch die IPv6-Adresse aktualisiert, was sie nicht darf, wenn das ein anderes Gerät tun soll. Was zu tun ist steht im oben von Dennis verlinkten Tech Block 11. Jan 25. Bitte gründlich lesen und die richtigen Schlussfolgerungen ziehen. Ich habe sie heute morgen gelesen, die Schlussfolgerungen gezogen und mit einer Testdomain und einer 7490 damit genau das erreichen können, was du erreichen willst.

Somit ist es möglich die Fritte nur den IPv6-Präfix aktualisieren zu lassen, wenn alle Parameter stimmen.

Da du mich aber scheinbar für einen komischen Vogel hälst habe ich jetzt keine Lust dir meine Schlussfolgerungen „vorzubeten“.

Hallo,

danke für die Rückmeldung, dennoch würde ich mir eine weniger vorwurfsvolle Schreibweise wünschen. Also: Ich habe die Links – egal ob hier im Forum gepostet oder aus den Wiki-Seiten, da diese Links dann aber sehr persönliche Daten enthalten (z.B. den Update-Token) möchte ich diese hier nicht posten und belasse es in meinen Postings bei den generischen Beispielen. Im produktiven Einsatz habe ich die „Platzhalter“ für Update-Token und meinen IPV64.de-Domain ersetzt.

Für die Tests in der FritzBox gibt es keine Fehlermeldung. Das Update wird ausgeführt aber die FritzBox scheint das über Laufzeit mehrfach zu machen und irgendwann ersetzt sie (gewollt oder ungewollt) auch die Host-ID meines PC, auf dem NextCloud läuft, durch ihre eigene Host-ID. Der Fehler zeigt sich dann dadurch, dass „mein-domain.ipv64.de“ nicht mehr die WebGUI der NextCloud öffnet, sondern die WebGUI meiner FritzBox.

Für die Tests mit dem Docker Update Tool habe ich die einzige Fehlermeldung, die ich in den Docker-Logs bekomme, weiter oben gepostet. Die Meldung sagt mir nur, dass etwas falsch sei aber nicht was genau falsch ist. Ich habe aber am Docker Compose File nichts geändert, was dazu geführt haben könnte, dass es bis Tag X funktionierte und ein Docker-Restart („container donw“ à „container up“) dazu führte, dass es ab Tag Y nicht mehr funktioniert. Die relevanten Umgebungsvariablen im Docker Compose habe ich x-mal auf Tippfehler hin überprüft und ich habe den Docker Container sogar komplett gelöscht (mit „docker system prune -a“) und neu „gepullt“. Das half alles nichts.

Anyhow… mein kleines BASH-Skript, welches ich auf dem PC der NextCloud via CronJob (bzw. „Geplante Aufgaben“ in OMV7) alle 15 min. laufen habe, macht zuverlässig Updates, sobald sich die (ganze) IPv6-Adresse des PCs geändert hat (was i.d.R. jeden Morgen 4:00 Uhr passiert).

Damit erst einmal danke an alle für hilfreiche und supportive Tipps.

Grüße
Mic.

Ja, weil du das Ganze Konzept noch immer nicht verstanden hast. Wenn die Fritzbox den Job macht, dann darf kein anderes Gerät den gleichen Job auch noch machen, dabei aber eine andere IPv6-Adresse eintragen.

Noch mal in deutlichen Worten:
Ein Update durch ein Docker-Dings ist ÜBERFLÜSSIG, wenn die Fritte den IPv6-Prefix bereits updatet. Ich hate ja nun schon zweimal darauf verwiesen, dass dann für den Docker ein Eintrag bei ipv64 gemäß „Interface-ID“ oder „EUI-64 MAC“ gemacht werden muss. Ich hatte auch erklärt wie sich die IPv6-Adresse dann zusammensetzt. Mir erscheint es so zu sein, dass du das noch immer nicht verstanden und umgesetzt hast. Der Docker muss dann nicht mehr updaten.

Solange du mit diesem Konzept nichts anfange kannst, das nicht umsetzen kannst oder willst, so lange reden wir hier aneinander vorbei. Und nach einigen Tagen aneinander vorbeireden wird das für mich langsam nervig.

Ich mache das mit dem IPv6-Prefix und Einträgen der „Interface-ID“ oder „EUI-64 MAC“ schon eine geraume Zeit so. Kein Client im LAN meiner pfsense muss da irgendwas updaten. Das macht alles nur die pfsense. DU hast eine Fritte, die kann das aber auch. Ich habe es getestet, mit einer Fritte die an einem entfernten Standort steht, die ich aber zur Fernwrung per Wireguard erreichen kann.

Und die Fritte macht das natürlich auch deshalb mehrmals am Tag, well dein Docker ja eine andere IPv6 einträgt als die Fritte. Das merkt die Fritte und will das korrigieren, weil für die ist ja was anderes korrekt. Irgendwann kannst so dann sogar ans tägliche Updatelimit kommen. Also wirklich keine clevere Konfiguration.

NACHTRAG: mangekls anderer Infos gehe ich davon aus, dass du eine NC im Docker hast, keine Bare Metall Installation. SOllte dem nicht so sein, dann muss der Eintrag der „Interface-ID“ oder „EUI-64 MAC“ eben zum Nextcloud-Server passen.

IPv6-Adresse des PCs ändert sich erst, wenn die dhcpv6 Lease-Time abgelaufen ist und der dhcpv6-Clien eine neue IPv6-Adresse anfordert. Je nach Vorgabe der Lease-Time (und bei Fritten kann man die meines Wissens nach nicht ändern) kann das also auch deutlich nach 4 Uhr sein,

@Mic2025 Sieh dir noch mal die von @Dennis_Admin verlinkte Anleitung (Tech Blog – 11 Jan 25) an.

Dort findet sich ein Bild aus einer Fritz!Box 7590 AX. Rot umrandet die IPv6 Interface-ID der Freigabe eines RaspberryPi. Um genau so eine IPv6 Interface-ID geht es.

Darunter findet sich IPv6 Prefix einrichten bei IPv64.net – Anleitung

Dennis führt dort folgende Update-URL auf
https://ipv6.ipv64.net/nic/update?key=VDz1ai1y2YZcHjwtExWemuX9UScJBA7h&ipv6prefix=auto&onlyprefix

Die enthält das Element was dir noch gefehlt hat. &onlyprefix. Gleichzeitig ist sie m.E. aber auch etwas zu unpräzise, wegen &ipv6prefix=auto

Ich hatte sie daher für meine Teste heute Morgen angepasst zu https://ipv6.ipv64.net/nic/update?key=VDz1ai1y2YZcHjwtExWemuX9UScJBA7h&ip6lanprefix=<ip6lanprefix>&onlyprefix
Damit aktualisiert eine Fritte NUR den Prefix des LAN’s der Fritte. Nichts sonst.

Nun geht man zu ipv64 und legt dort eine Passenden Eintrag an. Wie hier:

Der Eintrag unterhalb von IPv6 Prefix (DynDNS Prefix) wurde bereits von der Fritte befüllt. Den Präfix unterhalb von Domain Records kann man nutzen, muss man aber nicht. Geht auch ohne. Wichtig ist dass der AAAA-Record mit der „Interface-ID“ angelegt wird, die man der Fritte entnimmt, wie in dem rot umrandet Feld IPv6 Interface-ID der Freigabe eines RaspberryPi in der Anleitung von Dennis gezeigt. Das Ergebnis ist dann unter Destination zu sehen und sollte in Klammern und in Fettschrift den IPv6-Prefix-Teil einhalten und in Normalschrift die IPv6 Interface-ID zeigen.

Dieser IPv6 Interface-ID-Teil bleibt immer unverändert. Dafür sorgt der dhcpv6-Server der Fritte, sofern der Client (Server mit der NC drauf) den dhcpv6-Client aktiviert hat. Geändert wird nur noch der IPv6-Prefix. Das morgentliche Update besorgt die Fritte und zwar direkt nach der Zwangstrennung.

Guten Abend,

die roten Rahmen auf Denis‘ Seite habe ich gesehen. Den ersten Link habe ich auch ausprobiert aber damit ist einfach gar nichts passiert. Erst mit dem Aktivieren des zweiten Links hat sich der Update-Counter (rechts oben auf der Webseite zu sehen als z.B. „1/64“) meines IPV64.net-Zugangs hochgezählt. Meine Interpretation von diesem Verhalten ist, dass nur der zweite Link einen Effekt hat.

Erster Link:

https://ipv6.ipv64.net/nic/update?key=*********************************&ipv6prefix=auto&onlyprefix

Zweiter Link:

https://ipv64.net/nic/update?key=*********************************&ip=<ipaddr>&ip6=<ip6addr>&ip6lanprefix=<ip6lanprefix>

Jetzt habe ich deinen neuen Link (dritter Link) noch einmal ausprobiert und die FritzBox sich neu verbinden gelassen. Damit hat sie das IPv6-Präfix auf der Webseite tatsächlich geändert aber der Update-Counter wurde nicht hochgezählt.

Dritter Link:

https://ipv6.ipv64.net/nic/update?key=*********************************&ip6lanprefix=<ip6lanprefix>&onlyprefix

Allerdings bringt dein Link die Response:

{"info":"","ipv6prefix":"format error"}

Daher meine neue Frage: Kann es sein, dass ein Update nur des IPV6-Präfix nicht auf das tägliche Update-Kontingent angerechnet wird und meine obige Interpretation („es funktioniert nicht, weil der Counter nicht hochzählt“) falsch war?

Ich werde es eine weitere Nacht testen.

Mal noch eine andere Frage: Für das Update nur des Präfixes, was gibt man in der FritzBox als „Domainname“ an?

Gibt es evtl. auch einen Link, mit dem ich die aktuell hinterlegte (komplette) IP-Adresse für meinen PC, den ich im Netz verfügbar machen möchte, abrufen kann, OHNE dass dies auf das tägliche Update-Kontingent (max. 64 Updates) angerechnet wird? Das wäre noch ein gutes Feature für mein Update-Checker-Skript. Das läuft aktuell am zuverlässigsten.

Mit diesem Link kann ich zwar eine Abfrage ohne Update machen aber der Counter geht eins hoch:

https://ipv64.net/nic/update?key=*********************************

Trotzdem würde ich nach wie vor gern wissen, wieso dieses Tool als Docker Container nicht mehr funktioniert.

Damit erst einmal allen ein entspanntes Wochenende.

Grüße
Mic.

So ist es. Auch bei meiner pfsense werden nur die Domain-Updates gezählt, nicht die Prefix-Updates.

Die Domain zu der der verwendete Update-Key gehört.

Willst du auch das Rad neu erfinden?
Warum verwendest du nicht einfach das Tool, das ipv64 dafür bereitstellt? Den Healthcheck? Für meine Nextcloud nutze ich z.B. den html-Healthcheck und werde informiert wenn etwas nicht stimmt (z.B. wegen nicht erfolgreichem Prefix-Update).

Guten Morgen,

ich habe leider schlechte Nachrichten. Als sich heute Nacht mein IPv6-Präfix geändert hat, hat die FritzBox mit dem dritten Update-Link (siehe oben) leider kein Update durchgeführt. Es steht nach wie vor das alte IPv6-Präfix in der Benutzeroberfläche von IPV64.net und meine NextCloud ist nicht mehr erreichbar. Ich bin mir aber zu 100% sicher, dass ich den Update-Link richtig in der FritzBox hinterlegt habe, da es ja gestern einmal funktionierte (als ich die FritzBox gezwungen habe, sich neu zu verbinden). Schade… aber irgendwie ist dieses Feature auf meiner FritzBox wohl nicht ganz so zuverlässig.

Jetzt muss ich nochmal blöd fragen: Was meinst du mit „das Tool, was ipv64 dafür bereitstellt“? Gibt es neben dem Docker-Tool, was bei mir nicht funktioniert (siehe Titel dieses Threads), noch ein anderes offizielles Tool? Denn dieses Tool hat bei mir einen Platten, daher muss ich hier ein „Reserverad“ erfinden… bzw. das habe ich schon und das läuft prima. Allerdings vergleicht mein Skript nur lokal, ob sich an der IP-Adresse meines Host-PC etwas geändert hat und macht (nur) dann ein Update auf IPV64.net. Sollte sich auf Seite von IPV64.net ein Fehler eingeschlichen haben (warum auch immer), bekommt dies mein Skript nicht mit.

Schönes Wochenende erst einmal.

Danke und Grüße
Mic.

Versuch es nochmal mit &ipv6prefix=auto&onlyprefix
statt &ip6lanprefix=<ip6lanprefix>&onlyprefix

Ich finde das =auto ab problematisch wegen:


der Unterscheidung Heimnetz, Gastnetz, WAN. Bei =<ip6lanprefix> ist klar, dass der Prefix des LAN’s, also Heimnetz, aktualisiert werden soll. Wie das Bild zeigt hat eine Fritte aber drei IPv6-Prefixe. =auto könnte auch bedeuten es wird der des WAN’s aktualisiert statt der des LAN’s. Ist für mich daher eben nicht eindeutig genug. Wäre aber einen Versuch wert.

In meiner pfsense verwende ich =auto. Aber in der pfsense muss man das Interface to monitor und auch das Interface to send update from im DnyDNS-Client der pfsense auch explizit auswählen. Je nach Ausstattung der pfsense mit LAN-Interfaces also WAN, LAN, opt1, opt2, opt3, usw. Eindeutigkeit wird bei mir also durch die Zuordnung zu einem bestimmten Interface hergestellt.

Die Healthchecks