Nginx Proxy Manager und Lets Encrypt interner Fehler

diwoma
Goto Top
Hi,

Ich komme zu diesem Forum, weil ich über das Problem 2 Einträge (mit Hilfe-Versuchen) gefunden habe, die aber nicht beendet wurden. In anderen Foren wurde es teilweise als gelöst gemeldet, aber ich komme trotzdem nicht weiter.

Ausgangslage:
In einem LXC-Container (Debian Buster) in Proxmox habe ich den NPM (Version 2.9.5) als Docker-Container über Docker-Compose aufgesetzt. In meinem Router eine Port-Weiterleitung für Ports 80 und 443 eingerichtet. Die Ports sind von aussen zu erreichen (getestet mit einer VM in Azure mit telnet, also sicher aus dem Internet und nicht nur im Intranet).
Der Zugriff erfolgt über Subdomains meiner bei DynDns gehosteten DynDomain.
Im NPM habe ich mehrere HTTP-Routings zu verschiedenen RPI's eingetragen, die alle funktionieren!

Das Problem habe ich nun, wenn ich über die NPM-interne Funktion SSL-Zertifikate für die Subdomains einrichten will: ich bekomme immer den schon bekannten internal error

Der Auszug des LetsEncryt-Vorganges bei dem Versuch, ein Zertifikat zu erstellen (Subdomain- und Domain-Namen sind geändert):

Ein Detail fällt mir dabei auf:
Detail: Fetching http://sub.mydomain.gotdns.com/.well-known/acme-challenge/g0LyH7L7_-dLO ...: Timeout during connect (likely firewall problem)

Wenn ich ein curl auf diese Adresse bekomme, dann erhalte ich sofort den Inhalt des Service auf den die subdomain weitergeroutet ist.
Und ich verstehe nicht wer dieses .well-known-Verzeichnis hätte anlegen sollen, und wo es angelegt wäre, auf dem NGINX oder auf dem gerouteten Service.

Ein Detail noch:
Es könnte auch ein Zertifikat auf die gesamte Domain sein, aber ich weiss nicht, welcher DNS-Dienst in der Challenge ausgewählt werden müsste, bzw. wie ich ein entsprechendes Token von DynDns.org bekommen könnte.

Oder wäre ein anderer DynDNS-Dienst besser?

Ich hoffe, jemand in diesem Forum (oder viele) können mir dabei weiterhelfen.
Wenn diese erste Hürde geschafft ist, habe nämlich noch weitere Fragen :) face-smile

-- diwoma

Content-Key: 1454784794

Url: https://administrator.de/contentid/1454784794

Ausgedruckt am: 28.06.2022 um 20:06 Uhr

Mitglied: Dani
Dani 01.11.2021 um 16:40:10 Uhr
Goto Top
Moin,
Wenn ich ein curl auf diese Adresse bekomme, dann erhalte ich sofort den Inhalt des Service auf den die subdomain weitergeroutet ist.
Machst du das auf dem Rechner, der auch im LAN steht oder in der Azure VM? Falls es das Letztere ist, versuch das Erstere noch.

Detail: Fetching http://sub.mydomain.gotdns.com/.well-known/acme-challenge/g0LyH7L7_-dLO ...: Timeout during connect (likely firewall problem)
Vermutlich liegt es am fehlenden NAT Hairpinning.


Gruß,
Dani
Mitglied: diwoma
diwoma 02.11.2021 um 05:39:08 Uhr
Goto Top
Guten Morgen, Dani,

Danke für die Antwort.

Zitat von @Dani:
Machst du das auf dem Rechner, der auch im LAN steht oder in der Azure VM? Falls es das Letztere ist, versuch das Erstere noch.

Das ist intern (im Intranet) und extern (Azure) das gleiche Ergebnis

Detail: Fetching http://sub.mydomain.gotdns.com/.well-known/acme-challenge/g0LyH7L7_-dLO ...: Timeout during connect (likely firewall problem)
Vermutlich liegt es am fehlenden NAT Hairpinning.
Das ist ein für mich unverständliches Schlagwort.
Was ist damit gemeint, wie kann man es feststellen und was kann man dagegen machen?

-- diwoma
Mitglied: diwoma
diwoma 02.11.2021 um 15:04:31 Uhr
Goto Top
Ich habe mich mal über das NAT-Hairpinning schlau gemacht.
Ich denke, ich werde das noch untersuchen, weil es anscheinend noch andere Probleme geben kann
Mitglied: Dani
Dani 02.11.2021 aktualisiert um 16:00:02 Uhr
Goto Top
Moin,
Das ist intern (im Intranet) und extern (Azure) das gleiche Ergebnis
Okay. Du weißt aber, dass die Challenge (in diesen Fall g0LyH7L7_-dLO) nur solange existiert wie certbot Abfrage ausgeführt wird?! Daher lege am Besten eine Textdatei in .well-known/acme-challenge/ um dem Zugriff zu testen.


Gruß,
Dani
Mitglied: diwoma
diwoma 02.11.2021 um 15:56:28 Uhr
Goto Top
Danke für den Tip.
Mitglied: diwoma
Lösung diwoma 03.11.2021 um 18:20:29 Uhr
Goto Top
So, jetzt kann ich meine Lösung präsentieren:
Der Bug befand sich, wie fast immer, vor dem Keyboard :) face-smile

Nachdem ich auf einer der möglichen Webseiten einen Port-Check gemacht habe und dieser Portcheck das Port 80 als geschlossen angezeigt hat, bin ich nachdenklich geworden. Von meiner Azure-VM (in Deutschland) geht es und von der Port-Web-Check-Site nicht.
Dann habe ich mich erinnert, dass ich in meinem Router einen Geo-Ip-Block eingerichtet habe, in dem ich einige Länder eingetragen habe (China, Russland und ein paar andere). Und siehe da, kaum habe ich den Block deaktiviert, ist auch das Port von der Website als offen erkannt worden.
Und was soll ich noch schreiben: Auch Lets Encrypt hat sofort ein Zertifikat ausgestellt.
Aber vielen Dank an @Dani, seine Antworten haben mich zum Nachdenken angeregt und mir bei der Lösung somit geholfen.

-- diwoma