ich benutze IPv64 dyn DNS um auf meinen NGINX(Installiert auf Proxmoxx) zu zeigen und von dort entsprechend meine Container und VMs extern erreichbar zu machen. Zu Hause habe ich eine FritzBox. Ich hatte alles erfolgreich eingerichtet und es hat auch alles sehr gut funktioniert.
Bis das SSL Zertifikat abgelaufen ist. Ich konnte dieses nicht verlängern. Ich habe im NGINX die Domain gelöscht und neue angelegt. Ohne Erfolg. Dasselbe habe ich auch auf IPv64. Also die Subdomain. Sogar testweise mit komplett neuen IPv64 Subdomains hat das nicht geklappt.
Wenn ich jetzt eine neue Domain auf NGINX anlege, kommt nur die Meldung internal Error. Die Domain ist dann nur als http only angelegt.
Wenn ich dann nachträglich ein SSL Certificate anlegen möchte, kommt folgende Meldung:
CommandError: Saving debug log to /tmp/letsencrypt-log/letsencrypt.log
Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /tmp/letsencrypt-log/letsencrypt.log or re-run Certbot with -v for more details.
at /app/lib/utils.js:16:13
at ChildProcess.exithandler (node:child_process:430:5)
at ChildProcess.emit (node:events:519:28)
at maybeClose (node:internal/child_process:1105:16)
at ChildProcess._handle.onexit (node:internal/child_process:305:5)
Ich weiß, es geht nicht nur um IPv64. Aber ich denke das hier mehrere mit NGINX arbeiten.
Mehr input habe ich leider nicht, da es nicht mehr Fehlermeldungen gibt. Welche Art von Input wird denn erwartet? Im Netz findet man viele User die dieses Problem haben, jedoch keine Lösung.
Der einzige Lösung die ich sehe ist NGINX immer zum Ablauf der SSL Zertifikate neu zu installieren. Da stellt sich für mich die Frage, warum diese Zertifkate überhaupt so schnell ablaufen.
Da vermutest du richtig.
Ich nutze NGINX und letsencrypt für meinen Server mit Nextcloud.
Eine Idee, aber auch nur eine Idee, weil ich zu wenig bisher weiß über dein konkretes Problem ist die, dass du Port TCP 80 (http) nicht offen haben könntest.
Meine Nextcloud und damit nginx hören nur auf Port TCP 443 (https). Darum ist bei mir in der Firewall davor auch Port TCP 80 dicht. Für die Erneuerung des Zertifikats muss aber der Port TCP 80 offen sein und an den Server mit der Nextcloud (nginx) weitergeleitet werden. Vergesse ich diesen zuvor zu öffnen scheitert die Erneuerung des Zertifikats.
Nachtrag: scheitert die Erneuerung des Zertifikats zu oft (genau Anzahl der Versuche kenne ich nicht) wird man von letsencrypt für eine Weile (ich glaube eine Woche) gesperrt. Dann geht gar nichts mehr.
Mein konkretes Proplem ist, dass ich kein SSL Zertifikat anlegen kann.
Es hatte alles wunderbar funktioniert, bis das besagte Zertifikat abgelaufen ist. Ich konnte es nicht verlängern oder neu anlegen.
In meiner Fritzbox ist der Port 80 und 443 freigegeben.
Ja das hatte ich tatsächlich schon, ist aber schon mehr als zwei Wochen her. Es gab da auch eine sehr konkrete Fehlermeldung das ich es zu oft versucht habe.
Na also. Es kann mit einer privaten IPv4 nicht funktionieren. Eventuell hast du das erste Zertifikat nicht für die Subdomain nc.DeineDomain.ipv64.net angefordert sondern für DeineDomain.ipv64.net. Dann hat das deswegen geklappt. Irgendwas muss geändert worden sein. Mit einer privaten IP aus dem Bereich 192.168 oder 10.0 … kann es nie klappen. Unmöglich. Glaub mir bitte.
Aus Neugier: wie aktualisiert du eigentlich den A-Record für die Subdomain (Präfix) nc.DeineDomain.ipv64.net?
Machst du das manuell (in dem du die IP per Hand bei ipv64 einträgst) oder z.B. über das APT Debian DDNS IPv64 Package?
Nicht dass beim Update ein Konfigurationsfehler vorliegt und das gleiche Problem in 90 Tagen wieder auftritt.
Okay, mit dem Präfix Link meinst du
„Mit AVM Fritzbox IPv6-Prefix Updaten
Mit der Fritzbox ist es möglich den IPv6-Prefix zu aktualisieren. Somit werden dann auch Clients welche als Hosts eingetragen sind aktualisiert.“?
Das mit dem Präfix Link betrifft aber nur IPv6.
Das Häkchen vor Wildcard bedeutet dass bei dir nun alle denkbaren Subdomains deiner Hauptdomain aufgelöst werden. Ähnlich wie bei dos „dir *,txt“ oder linux „ls *.txt“ alle Dateien finden würde die auf .txt enden. Bei IPv4 ergibt das Häkchen vor Wildcard setzen auch Sinn. Dann ist allerdings der Extra-A-Record-Eintrag für nc.DeineDomain.ipv64.de hier
Für den AAAA-Record ist die aktive Wildcard-Option sogar kontraproduktiv. Denn dort verweist du ja damit auf die IPv6-Adresse der FritzBox. Einer der wesentlichen Unterschiede zwischen IPv6 und IPv4 ist aber, dass IPv6-Adressen immer öffentliche IP-Adresse sind, es sei denn du verwendest ausschließlich im Netz hinter der FritzBox nur IPv6-Adressen die mit fe80: beginnen.
Solltest du also im lokalen Netz andere IPv6-Adressen verwenden, als die, die mit fe80: beginnen, dann solltest du den Wildcard nur für IPv4 verwenden und für den nc-Server (nc.DeineDomain.ipv64.de) einen AAAA-Record anlegen und zwar im Format: „Interface-ID“ (ex. ::6743:12::f9aa::44a1) oder Format: „EUI-64 MAC“ (ex. 3C:49:37:12:26:B3).
So wie du das jetzt machst kannst du den nc-Server (nc.DeineDomain.ipv64.de) ja auch mit IPv6 nur per NAT erreichen. IPv6 macht NAT aber gerade überflüssig.
Damit das dann so auch alles problemlos funktioniert solltest du in der Fritzbox unter Heimnetz - Netzwerk - Netzwerkeinstellungen - IP-Adressen - IPv6-Einstellungen noch DNS-Server, Präfix (IA_PD) und IPv6-Adresse (IA_NA) zuweisen aktivieren. Andernfalls werden die IPv6-Adressen per SLAAC von den Clients selbst ermittelt und nicht per DHCPv6-Server von der FritzBox zugewiesen.
Welche öffentliche IP meinst Du? Die „Destination“ die bei ipv64.net für meine Domain erkannt wurde (also die mit der meine FritzBox im Internet erreichbar ist)? In allen Videos zum Thema wird aber immer die interne IP verwendet.
Gruß SaRa
Kannst Du mal bitte präziser fragen? ich weiß gerade nicht auf welche meine Aussagen du dich beziehst. Quote (zitiere) doch die Stelle auf die du dich beziehst. So weiß ich einfach nichtwas du meinst und kann das daher auch nicht beantworten
Dort darf niemals eine private IP-Adresse stehen (im Beispiel die 192.168.188.57).
Ich kann mir also nicht vorstellen, dass du irgendwo ein Videos findest, das sagt da müsse eine private IP-Adresse stehen. Ich sag dir auch warum nicht:
Weil da ja eine IP-Adresse stehen mus auf die die subdomain (Präfix) nc … geroutet werden soll. Im Internet werden private IP-Adressen aber nicht geroutet. Also kann es nur eine öffentliche IP-Adresse sein, die da steht. Und im Fall von IPv4 muss es die des Routers sein, die an dessen WAN-Interface zur Zeit anliegt. Dann wird per NAT und Portweiterleitung erst vom Router die öffentliche IPv4-Adresse am WAN-Interface übersetzt in die private interne IP-Adresse des Servers der mit der Subdomain nc … erreicht werden soll. Das nennt man Network-Adress-Translation, oder eben kurz NAT.
Ich habe das ja nun direkt vor meine Nase das es wieder funktioniert.
