Also es hatte alles nichts mit den Firewall-Rules seitens der pfsense zu tun. War wohl nur ein zufälliger zeitlicher Zusammenhang.
Wo genau der Fehler lag kann ich nicht sagen. Obwohl ich alle geänderten Firewall-Rules heute wieder auf die ursprünglichen Werte gesetzt hatte, war der Fehler heute früh noch immer da. Im Minutentakt ging der DynDNS Update-Zähler nach oben und näherte sich dem Tageslimit von 64.
Das bildete sich auch im Logfile des „APT Debian DDNS IPv64 Package“ ab.
Da ich keine andere Lösung weiß, habe ich dann bei ipv64.net den „Präfix“ (Subdomain) für meine Nextcloud gelöscht und eine neue mit gleichem Präfix angelegt. Dadurch bekam diese auch einen neuen, geänderten Präfix-/Subdomain Update Token und ich habe diesen via Skript ./ipv64-ddns-update -set sowie alle anderen erforderlichen Parameter neu übergeben.
Danach habe ich dann wieder in der Komandozeile
- systemctl daemon-reload
- systemctl enable ipv64-ddns-update.service
- systemctl restart ipv64-ddns-update.service
ausgeführt.
Nun läuft alles wieder wie gewohnt und im Logfile des „APT Debian DDNS IPv64 Package“ sind die üblichen Einträge bei unveränderter IP-Adresse zu sehen:
- 2024-08-10 07:56:26 | [API-Zugriff] | API Zugriff wurde schon geprüft
- 2024-08-10 07:56:27 | [IPv6] | DNS OK
- 2024-08-10 07:56:27 | [IPv4] | DNS OK
Merkwürdig ist das alles aber schon, denn die Einträge in der /etc/ipv64-ddns-update/config.cfg hatte ich zuvor mehrfach überprüft und auch der Präfix-/Subdomain Update Token stimmte mit der Angabe auf ipv64.net im entsprechenden Link (Anker-Symbol unter Do) zur Subdomain überein.
Zudem hätte bei falschem Präfix-/Subdomain Update Token ja eigentlich gar kein Update stattfinden dürfen, statt jede Minute ein neues.