Warum ein VPN-Server hinter CGNAT nie Verbindungen annimmt

Der Router meldet eine WAN-Adresse, die mit 100.72 beginnt, der dynamische DNS-Name löst auf eine andere öffentliche Adresse auf, und der VPN-Server auf diesem Router schließt nie einen Handshake von außen ab. Portweiterleitung ist eingerichtet, der Dienst läuft, und ein Test aus dem LAN funktioniert weiterhin. Im Routerprotokoll sieht nichts nach einem Fehler aus. Diese Kombination ist Carrier-Grade-NAT, und keine Firewallregel kann einen Port auf einer Adresse öffnen, die der Anbieter hält.

Die gemeinsame Adresse zu bestätigen dauert zwei Minuten und verhindert eine Woche voller Konfigurationsänderungen.

Die Anzeichen für Carrier-NAT

Vergleichen Sie die WAN-Adresse auf der Statusseite des Routers mit der Adresse, die eine externe Abfrage meldet. Eine WAN-Adresse innerhalb von 100.64.0.0/10 ist das übliche Anzeichen, und die privaten Bereiche 10/8, 172.16/12 und 192.168/16 bedeuten dasselbe. Wenn traceroute denselben öffentlichen Hop wiederholt zeigt oder ein früher Hop mit einer privaten Adresse antwortet, sitzt ein weiterer Übersetzer zwischen Router und Internet. Manche Anbieter führen die zugewiesene Adresse nur im Kundenportal, also exportieren Sie diesen Wert zusammen mit dem traceroute.

Protokolle oder Ports zu wechseln hilft nicht, denn das Problem ist die eingehende Erreichbarkeit und nicht ein geschlossener Port.

Warum Weiterleitung und dynamisches DNS das nicht beheben können

Eine Portweiterleitungsregel bildet einen Port auf der WAN-Schnittstelle des Routers ab, aber eingehender Verkehr erreicht diese Schnittstelle nie: Der Anbieter übersetzt ihn zuerst und leitet nur weiter, was seine eigene Tabelle zulässt. Die gemeinsame Adresse in dynamischem DNS zu veröffentlichen, lenkt Clients auf ein Anbieter-Gateway, das viele Teilnehmer nutzen, weshalb der Name auflöst und der Handshake trotzdem scheitert. Hairpin-Tests gelingen, weil der Router seine eigene Regel von innen beantwortet, und UPnP hat genau denselben blinden Fleck.

Auch eine Neukonfiguration des Clients hilft nicht, da der Fehler auftritt, bevor eine Client-Einstellung gelesen wird.

Weiterleitung über einen VPS mit expliziten Routen

Setzen Sie eine öffentliche Adresse davor, indem Sie den kleinsten VPS mieten, der den Verkehr tragen kann, und lassen Sie dann den Heimrouter dorthin auswählen. Ausgehendes UDP aus dem Heimnetz passiert Carrier-NAT, also baut sich der Tunnel von innen auf, und der VPS wird zum erreichbaren Endpunkt. Die Heimseite wird zu einem Client mit fester Tunneladresse, nicht zu einem Server.

Fügen Sie auf dem VPS einen klientspezifischen Verzeichniseintrag hinzu, damit der Server weiß, welcher Peer das Heimsubnetz besitzt, und ergänzen Sie eine passende Kernelroute.

# /etc/openvpn/server/ccd/home-site.conf
ifconfig-push 10.8.0.10 255.255.255.0
iroute 192.168.50.0 255.255.255.0

# server.conf
client-config-dir /etc/openvpn/server/ccd
route 192.168.50.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"

Die Zeile iroute teilt OpenVPN mit, welcher Client den Verkehr für das Heimsubnetz erhält; die Zeile route legt dieses Subnetz in die Kerneltabelle des VPS, damit Pakete überhaupt in den Tunnel gelangen. Für einen veröffentlichten Dienst fügen Sie eine Ziel-NAT-Regel hinzu, die den öffentlichen Port auf 10.8.0.10 weiterleitet, und aktivieren Sie net.ipv4.ip_forward.

Testen Sie den Pfad von außen

Prüfen Sie jeden Hop auf der öffentlichen Seite, denn ein erfolgreicher Tunnel beweist nicht, dass der Dienst erreichbar ist. Lauschzustand und Paketmitschnitt auf dem VPS unterscheiden 'nichts angekommen' von 'angekommen und verworfen'.

ss -lunp | grep 1194
tcpdump -ni any udp port 1194
nft list ruleset | grep -A4 dnat

# from a phone on mobile data, not the home Wi-Fi
nc -vz -u 203.0.113.10 1194

Zeigt der Mitschnitt Pakete vom Telefon, aber keine Antwort, sind Serverkonfiguration oder Firewall der nächste Punkt. Zeigt der Mitschnitt nichts, löst der Client noch auf oder sendet an die falsche Adresse.

Alternativen, die zuerst einen Preisvergleich wert sind

Eine dedizierte IPv4-Adresse vom Anbieter ist die kürzeste Lösung und kostet meist eine kleine Monatsgebühr. Natives IPv6 beseitigt die Übersetzung an beiden Enden, wenn VPN, Clientnetz und DNS-Einträge es alle tragen. Ein Mesh-Overlay mit einem Subnetzrouter im Heimnetz erreicht dieselbe Weiterleitung ohne VPS, zum Preis der Abhängigkeit von einem Koordinationsdienst.

Wählen Sie die Weiterleitung, wenn die Anforderung stabiler eingehender Zugriff ist und jede Regel unter Ihrer Kontrolle bleiben soll. Wählen Sie die Anbieteradresse, wenn das Budget es erlaubt und das Ziel einfach ist, nicht mehr daran denken zu müssen.