ich habe gestern einen Neuen Dyndns für mich eingerichtet. (wechsel vom alten Providor). Das hat auch alles soweit geklappt. Meinen alten Nginx Proxy Manager habe ich in Proxmox gelöscht. Dann einen neuen mittels Helper Script installiert. Anschließend habe ich meinen Bitwarden Server eingetragen und habe versucht ein SSL Zertifikat zu erhalten. Leider kommt immer wieder ein “Interner Fehler” Es wird auch keine E-Mail mehr abgefragt.
Bei der Suche in diesem Forum habe ich auch die Variante mit MultiDNS probiert. Auch da kommt immer ein Feher. Bin langsam am verzweifeln
Kann mir jemand weiterhelfen um das Problem zu lösen. Bin auch gerne Bereit für den Support zu zahlen.
Hallo Klaus,
ich vermute, die fähigen Leute hier im Forum benötigen etwas mehr Informationen, um helfen zu können.
Liege ich falsch, dass der neue DynDNS-Dienst IPv64 ist? Was sind die Fehlermeldungen, die du bekommst? Wie sieht dein Setup aus? Was genau hast du bisher probiert (also was wo eingetragen/eingestellt)? Was sind die Fehlermeldungen/Ergebnisse dessen?
NPM (in Docker) mit DNSMulti und IPv64-DynDNS funktioniert bei mir ziemlich problemlos, auch mit den automatischen Zertifikatserneuerungen.
vielen Dank für Deine Antwort. Ich habe nach zwei Tagen des probierens erst einmal alles wieder aufgegeben. Ich habe meine Domain bei IPV64 erst einmal wieder gelöscht. Ich versuche gerade wieder den alten Zustand herzustellen bei meinem alten Provider. Das hatte vorher mit meinem NPM wunderbar funktioniert. Aber auch da habe ich jetzt Probleme. Was da allerdings sofort wieder ging, ich konnte bei einem neuen Host Eintrag automatisch Certificate sofort wieder eintragen lassen.
Das ging bei IPV64 garnicht. Ich habe in diesem Forum viel gelesen auch zum Thema DNSMulti und ausprobiert. Auch da kam immer der Fehler.
Ich habe einen NPM (v.2.14) in einem Proxmox LXC Container eingerichtet. Da möchte ich 4 Server in meinem Home Netz erreichbar machen. Aber irgend wie ist da jetzt ein großer Wurm drinnen.
Ich würde mich freuen wenn mir da einer auf die Sprünge helfen würde. Mir eventuell ein Konzept vorschlagen wie ich vorzugehen habe um vom alten DYNDns Provider wechseln zu IPV64. Würde auch gerne dafür bezahlen. Oder mir jemand nennen kann der solche Dienste anbietet.
Mit 72 Jahren ist alles nicht mehr so einfach.
Ich habe mir fast alle Video`s von Dennis, zum Teil mehrfach angesehen. Dadurch habe ich ja auch einige Interessante selbst gehostete Server, vaultwarden, stirling, wireguard…usw. auf meinem Proxmox Host installiert. Angefangen mit der damaligen Reihe “Docker Grundlagen Training 1/4 - Portainer, NGINX Proxy Manager, Vaultwarden”. Ich habe viel gelernt und es hat auch immer funktioniert. inkl. NPM. Weil ich die Erklärungen von Dennis so super finde hatte ich ja gedacht, das ich jetzt auf seinen DynDns Dienst wechsel nach dem Motto
Erstelle bei IPV64 eine Neue Domain “klaus.home64.de”, trage es in meine Fritzbox ein (das hat funktioniert),
mache in meinen vorhandenem NPM einen neuen Eintrag “bitw.klaus.home64.de”
Und das ging leider voll in die Hose
Beim Zertifikat erstellen kam immer interner Fehler.
Moin,
ich nutze für DynDNS deSEC.io mit meinen eigenen Domains. Die DynDNS-Updates führt bei mir die pfSense automatisch durch – das läuft problemlos. Über HAProxy auf der pfSense stelle ich ca. fünf Webseiten bereit.
Ich hab es jetzt mal bei mir versucht nachzustellen.
NPM via HelperScripts mit den Standardeinstellungen installiert
vorhandene DynDNS-Domain verwendet und bei NPM ein Zertifikat für tester.myDynDNS.ipv64.net mittels DNSmulti eingerichtet/angefordert
ein paar Sekunden gewartet und parallel im Account auf IPv64.net zugeschaut wie bei myDynDNS.ipv64.net der txt-Record gesetzt und wieder gelöscht wird (immer wieder F5)
Zertifikat ist da und kann verwendet werden
Jetzt ist die Frage, wo läuft es bei dir gegen die Wand? Falls an dem home64.de-Limit liegen sollte, kannst du irgendeine andere Domain als Test verwenden, Dennis hat ja eine ganze Palette an Domains im Angebot. Wenn es da auch nicht geht, dann liegt es an deiner Konfiguration. Da benötigen wir dann aber ein paar mehr Informationen von dir…
vielen Dank für Deine Bemühung.
Ich habe es Gott sei Dank wieder in meiner alten Welt am Laufen.
Mein vaultwarden läuft wieder und meine Frau ist auch wieder zufrieden.
Aber ich möchte doch irgendwann nach IPv64 wechseln.
Meine Vorgehensweise war folgende:
Bei Ipv64 eine Domain beantragt.
In meiner FritzBox bei DynDNS den alten Provider gelöscht.
Dann die Update URL, Domainname in die FritzBox eingetragen
In meinem IPv64 Account konnte ich die Verbindung zu meiner Box sehen.
Dann in meinem Nginix (ist eine Docker Installation, nach Anleitung Dennis)
die alten Einträge auf Disable gesetzt.
Neuen Eintrag mit der Neuen Domainnamen erstellt. Zertifikat angefordert.
Da kam der „Interne Fehler“
Das Gleiche mit DNSmulti gemacht.
Der gleiche Fehler.
Was ich in der Tat nicht gemacht habe, ist eine andere Domain statt Home64 zu testen.
Kannst Du mir bestätigen das so meine Vorgehensweise vom Prinzip her Richtig war?
Und das es nur mit DNSmulti funktioniert?
Dann werde ich in ein paar wochen es erneut versuchen.
Klingt erstmal alles richtig. Ich weiß, dass es mit DNSmulti funktioniert - ob es nur damit funktioniert, weiß ich nicht.
Das Gute ist, du kannst parallel zu dem funktionierenden System die IPv64-Konfiguration probieren. Für das Ausstellen der Zertifikate (zumindest mit DNSmulti) musst du nicht einmal die IP auf die DynDNS-Domain setzen. Falls du es aber vollständig testen willst, dann müsstest du das Update der IP währenddessen manuell über die Konsole machen (die Befehle findest du hier).
Im NPM hast du dann 2 Einträge die auf das gleiche System zeigen und kannst testen, ohne dass am bestehenden funktionierenden System etwas ausfällt und du unnötigen Ärger mit deiner Frau bekommst. Sobald alles funktioniert, stellst du es dann nur in der Fritzbox und im NPM auf die produktive Domain um (theoretisch ).
Du solltest dir mal die (sofern vorhanden) Log-Files ansehen. Ein „Interner Fehler“ spricht nicht dafür, dass die Ausstellung der Zertifikate nur deswegen scheitert, weil bereits zu viele für home64.de oder eine andere Domain ausgestellt wurden, sondern für einen Fehler in der Konfiguration
wie bereits geschrieben habe ich wieder alles beim alten Provider am laufen.
Werde mir aber Deine Anregung merken wenn ich einen Neuen Versuch mache.
Danke
Ich nutze weder den NGINX Proxy Manager noch Proxmox, Daher weiß ich auch nicht was dort geloggt wird. Das von mir verwendete acme.sh schreibt jedoch ein sehr detailliertes Logfile (/var/log/UpdateACME.log). Es reicht zurück bis Nov. 2023,
Somit kann ich jetzt noch sehen, was vor 2,5 Jahren passiert ist. Evtl. suchst du mal nach einem passenden Log auf deinem System. Solltest du so etwas derzeit noch nicht haben, solltest du es aktivieren.
Wenn ich hier so das Forum durchstöbere, scheinst du aber auch ein Profi zu sein.
Ich bin Ü70 aber begeistert in der IT Welt immer wieder neues zu lernen.
Nach der netten ausdauernden Hilfe von @steveson habe ich jetzt noch einmal versucht weiter zu kommen und habe mir jetzt eine neue Domain angelegt und einfach mal in meinem Nginx einen neuen Host angelegt mit DNSMulti. Dabei ist mir jetzt aufgefallen, das hier im Forum die zwei Einträge immer ohne Leerzeichen beim “= Zeichen” beschrieben war.
Jetzt habe ich es mit Leerzeichen eingetragen. Jetzt habe ich ein SSL Zertifikat bekommen.
Da gab es keine Probleme mit der Begrenzung auf 1.000 Zertifikaten innerhalb von 168 Stunden. Das kann bei home64.de oder anderen Domains aber anders sein. Alles hat auf Anhieb funktioniert.
So jung bin ich auch nicht mehr. Ü60 sind es bei mir nun auch bereits. Und Alter bringt ja auch Erfahrung mit sich und diese Erfahrung zeigt eben, dass Logfiles und deren Auswertung für die effektive Lösung von Problemen unentbehrlich sind.
Ich habe mir das Video jetzt noch einmal angesehen. Ich betreibe allerdings keine pfsense. Ich bin bislang immer ein Freund der einfachen Installationen. Und da war der Nginx für mich der richtige Weg. Wenn ich es aber richtig verstanden habe soll das ja in der Version 3 von Nginx implementiert werden.
).