NPM + DDNS: Dienste nicht aus priv. Netzwerk erreichbar

[DerSchalker92]

Liebes Forum,

ich sitze bestimmt schon mehr als 15h an einem Problem, dass mich nachts nicht schlafen lässt. Ich habe schon einige Forenbeiträge dazu gelesen, aber ich habe keine passende Antwort gefunden bzw. nur Workarounds.

Folgendes Setup:

1. Fritzbox 7590 AX, hat öffentliche IP4&6
2. Domains bei Strato
3. Ubuntu-Server mit VMs (NPM Reverse Proxy Manager, Webserver und Nextcloud)
4. "Portfreigaben" für die NPM-VM
5. DDNS mit Strato eingerichtet, die DDNS-Adresse zeigt auf den NPM
6. Im NPM sind dann Proxy Hosts eingerichtet, Zertfikate usw.
7. Die anderen Domains haben auf ihrer WWW-Subdomain Cname-Einträge auf die DDNS, die "normale" Domain hat eine Weiterleitung auf die WWW-Subdomain. Die Nextcloud-Instanz hat als Domain nur zwei Subdomains (mit und ohne WWW, also nur CName auf die DDNS-Adresse ohne Weiterleitung)

Hauptproblem ist, dass die Nextcloud und die Webseiten von meinem Laptop (meistens) nicht im lokalen Netz erreichbar sind. Es erscheint dann ein Zertifikatsfehler MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT und das Zertifikat zeigt als DNS-Namen Varianten der Fritzbox, meine DDNS-Adresse und die MyFritz-Adresse für VPN an. Gehe ich auf "Risiko aktzeptieren" schlägt der Rebind-Schutz der FB an.

Nervig ist, dass es manchmal klappt, dass es auf dem Handy (von intern und extern) immer klappt und dass es bei einigen Programmen auf dem Laptop (Ubuntu) auch klappt, z. B. Joplin, das ja aber auch auf Nextcloud-Instanz sync'ed. Nextcloud über WebDAV meckert wegen eines TLS-Fehlers aber z. B. immer, so lange ich in meinem Netzwerk bin.

Die Seiten auf dem Webserver funktionieren mit Laptop im lokalen Netz nie. Ein Unterschied bei denen ist, dass es es eine Weiterleitung gibt auf die www-Subdomain (siehe 6. oben) und bei Nextcloud nicht (nur CNAME-Einträge).


Was ich schon gemacht habe:

1. Ausnahmen für den Rebind-Schutz hinzugefügt, aber dann erscheint die GUI der FB
2. Die Portfreigaben für den NPM jeweils getrennt für IP4 und IP6 eingerichtet (also je 2x HTTP und HTTPS)
3. Geschaut, ob die NPM-VM eine interne IP6-Adresse hat.
4. Mit nslookup herumgespielt: type=A klappt immer, AAAA klappt nicht immer (dann funktioniert auch Nextcloud nicht). Ich erkenne aber kein Muster.
5. Seiten wie ssllabs.com zeigen auch, dass es keine Verbindung über IP6 gibt, DNS scheint aber zu laufen.
6. Workarounds: lokale IPs nehmen und VPN, aber ich würde es gerne richtig zum Laufen bekommen,

Ich freue mich über jede Antwort. Ich habe schon etwas über andere Workarounds gelesen (Cloudflare-Tunnel, VPS, auf dem der NPM läuft), aber ich würde es gerne erst Mal so versuchen.

 

[blurrrr]

Hi,

DDNS mit Strato eingerichtet, die DDNS-Adresse zeigt auf den NPM

IPv4-WAN-IP vom Router (+ Portweiterleitung auf interne IPv4 vom NPM) + öffentliche IPv6 direkt die vom NPM?

 

[DerSchalker92]

Nein, da müsstest du mir auf die Sprünge helfen. Ich habe die vier Portfreigaben eingerichtet (getrennt nach IP4 und 6, aber das war auch nur zur Problemlösung) und die gesamte DDNS-Updater-URL eingefügt. Soll ich dann den IP6-Eintrag der Updater-URL löschen und dann unter AAAA-Record die IP6 der NPM-VM eintragen? Also die Adresse, die unter ifconfig erscheint, oder?

 

[blurrrr]

Du weisst was "NAT" ist? Damit wird Deine interne private IPv4 in die öffentliche IPv4 des WAN-Interfaces vom Router umgeschrieben (und rückwärts ebenso). Bei IPv4 brauchst Du eine Port"weiterleitung" (technisch: DNAT (Zielumschreibung)+Firewallfreigabe). Bei IPv6 ist es nur eine Port"freigabe" (technisch: Firewallfreigabe). Die Fritz!Box macht bei IPv6 kein NAT.

Hast Du nun die IPv4 und IPv6 im DNS (für Dein gewünschtes Ziel) "nur" auf die Fritz!Box gesetzt, erreichen die Pakete via IPv6 nur das WAN-Interface der Fritz!Box, was falsch ist. Dein NPM hat ja eine "öffentliche" IPv6-Adresse (kann "direkt" angesprochen werden) und eine "private" IPv4-Adresse (kann von aussen nicht angesprochen werden, daher auch die Zielumschreibung (DNAT) am Router mittels Portweiterleitung).

Im DNS hinterlegt sein müssen also:

1) Die öffentliche IPv4-WAN-IP vom Router - kommt das Paket dort an, wird es via Portweiterleitung an die private Adresse des NPM geschickt.
2) Die öffentliche IPv6-IP vom NPM - im Router ist lediglich die Freigabe zu erstellen, dass diese Pakete via http/https auch zum Ziel dürfen.

EDIT:

Soll ich dann den IP6-Eintrag der Updater-URL löschen und dann unter AAAA-Record die IP6 der NPM-VM eintragen? Also die Adresse, die unter ifconfig erscheint, oder?

Das wäre eine Möglichkeit, allerdings wirst Du dann das Problem haben, dass sich die IPv6 mit jedem IPv6-Präfixwechsel ändern wird. Wenn Du den NPM via Docker betreibst (glaube, das geht auch garnicht anders, aber keine Ahnung, nutze das Ding nicht), wäre es mitunter eine Option, wenn Du einen DynDNS-Client ebenfalls in einem Container laufen lassen würdest. Die Fritz!Box macht es leider nicht so mit, aber wenn ich mich recht erinnere, sollte ein ganz normaler DynDNS-Client (z.B. ddclient) die ersten öffentlichen IPs auf der Strecke nutzen. Aus Sicht so eines Containers wäre es a) die eigene öffentliche IPv6-Adresse (falls kein MACVLAN o.ä. im Spiel ist, wäre das die Host-Adresse) und b) die öffentliche IP Deines Routers.

 

[Barungar]

@blurrrr Besser hätte ich es nicht erklären können.

Und es scheint wieder ein Fall von "alten Denkmustern" zu sein... Es wird oft nicht bedacht, dass die Hosts bei IPv6 eine eigene öffentliche Adresse haben, und diese natürlich auch im DDNS-AAAA-Record stehen muss, sonst landet man auf der FritzBox.

Nervig ist, dass es manchmal klappt, dass es auf dem Handy (von intern und extern) immer klappt und dass es bei einigen Programmen auf dem Laptop (Ubuntu) auch klappt, z. B. Joplin, das ja aber auch auf Nextcloud-Instanz sync'ed. Nextcloud über WebDAV meckert wegen eines TLS-Fehlers aber z. B. immer, so lange ich in meinem Netzwerk bin.

@DerSchalker92 Die Antwort ist einfach, es klappt, wenn IPv4 genutzt wird und schlägt fehlt, wenn IPv6 genutzt wird. Das kann von Anwendungsfall zu Anwendungsfall ja sogar von Programm zu Programm verschieden sein. Wenn ein Programm explizit nur IPv4 auflöst, dann bekommt es natürlich auch nur den A-Record.