Hallo,
ich habe gestern meine Firewall-Rules strikter gesetzt. Heute nun habe ich keine zugriff mehr auf meine Nextcloud, da das DynDNS Update Limit bereits vor 08:00 Uhr überschritten war. Die Nextcloud läuft auf einen Debian-Server. Auf diesem wiederum das „APT Debian DDNS IPv64 Package“. Funktionierte bis gestern alles wunderbar.
Ich vermute also einen Zusammenhang mit den veränderten Firewall-Rules. An der DOMAIN oder DOMAIN KEY selbst hat sich ja nichts geändert. Dennoch liefert das Skrypt „ipv64-ddns-update --check“ nun stets den Fehler „[API-AUTH] | Die Angaben sind falsch gesetzt: DOMAIN oder DOMAIN KEY“, was aber auch daran liegen kann, dass für heute mein Update-Limit bereits überschritten ist.
Die Firewall-Rules habe ich bereits wieder auf die bis zur Änderung gestern gültigen Regeln zurückgesetzt. TCP, also auch die TCP Ports 80 und 443 konnte der Debian-Server mit der Nextcloud aber immer erreichen und auch einen DNS-Server.
Damit das Update-Limit morgen zwischen Mitternacht und aufwachen nicht wieder gleich voll läuft habe ich das „APT Debian DDNS IPv64 Package“ auch vorerst deaktiviert.
- systemctl stop ipv64-ddns-update.service
- systemctl disable ipv64-ddns-update.service
Hier noch ein Auszug aus dem Logfile des „APT Debian DDNS IPv64 Package“
Ab 16:08 Uhr wird nun praktisch im Minutentakt die Subdomain (Präfix) meiner Nextcloud upgedatet. Was natürlich dann dazu fürt, das das Tageslimit für Updatens von 64 schnell erreicht ist.
Da ich wie gesagt nur Änderungen an den Firewall-Rules vorgenommen habe, kann es eigentlich nur daran liegen, dass ich da notwendige Prots oder Protokolle (z.B. UDP, ICMP) versperrt habe.
laut github, schau halt einfach mal ins log der FW was geblockt wird
https://ipv64.net/ipcheck.php
https://ipv64.net/update.php
Ja, werde ich dann morgen machen. Für heute ist das DynDNS-Updatelimit bei IPv64.net ja bereits überschritten. Da werd ich mich wohl oder übel bis morgen gedulden müssen.
kannst ja trotzdem ins log schauen
Könnte ich. Kann aber auch bis morgen warten, dann im Terminal einen tail -f auf die relevanten logfiles in der pfsense wie auch auf dem Debian-Server legen und live mitverfolgen was passiert, wenn ich auf dem Debian-Server das Update anstoße. Das erspart mir jetzt die Suche nah relevanten Einträgen irgendwo in den Tiefen der logfiles, zumal ich ja nicht mal sicher weiß, wann das letzte mal heute Nacht das Update-Limit noch nicht überschritten war.
Derzeit habe ich den ipv64-ddns-update.service ohnehin disabled
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.
