Heim-VPN-Server nicht erreichbar: die NAT-Kette abgehen

Der Server antwortet im LAN, die Portweiterleitungsregel sieht richtig aus, und dennoch kann ein externer Client keine Verbindung aufbauen. Eine Grenze nach der anderen nach außen zu gehen ist schneller, als die Regel ein viertes Mal zu bearbeiten, weil jede Grenze ihren eigenen Beleg hinterlässt: die WAN-Seite des Routers, die Übersetzung des Anbieters und der Lauscher auf dem Host. Beginnen Sie auf der Verwaltungsseite, die Sie ohnehin offen haben, und enden Sie mit einem Test aus einem Netz, das Sie nicht kontrollieren. Schreiben Sie jedes Ergebnis unterwegs mit, denn die Reihenfolge ist die Diagnose, und eine erinnerte Zahl ist kein Beleg. Wenn Sie nur einen ausgehenden Tunnel brauchen, ist die Übersetzung nicht Ihr Problem: blockiert wird nur unaufgeforderter eingehender Verkehr.

Beginnen Sie auf der WAN-Seite des Routers

Melden Sie sich am Router an und lesen Sie die Statusseite statt der Liste der Portweiterleitungen. Notieren Sie die WAN-Adresse, das Interface, zu dem sie gehört, und ob der Verbindungstyp DHCP, PPPoE oder etwas vom Anbieter Bereitgestelltes ist. Vergleichen Sie diese Adresse dann mit dem, was ein externer Dienst meldet, und nutzen Sie ein Telefon im Mobilfunknetz, damit die Beobachtung nicht über denselben Router zurückläuft. Die beiden Zahlen beantworten verschiedene Fragen, und sie zu vergleichen ist der ganze Sinn dieses Schritts.

Eine WAN-Adresse, die von der beobachteten öffentlichen Adresse abweicht, bedeutet, dass mindestens ein Übersetzer oberhalb des Routers sitzt. Das ist noch kein Fehler, denn viele Anbieter übersetzen bauartbedingt, und der Dienst funktioniert weiterhin. Stimmen beide überein, gehört die Adresse wahrscheinlich dem Router, und das Problem ist in Ihr Netz gewandert. Schreiben Sie das Paar in jedem Fall mit Datum auf, denn Anbieter vergeben Adressen neu, und ein Vergleich mit den Notizen des Vormonats ist wertlos.

Gehen Sie einen Hop nach oben

Führen Sie ein traceroute direkt auf dem Router aus und lesen Sie die ersten Hops. Wiederholte öffentliche Adressen, ein erster Hop, der mit einer privaten Adresse antwortet, oder eine Adresse im gemeinsam genutzten Bereich 100.64.0.0/10 deuten alle auf einen Übersetzer weiter oben hin. RFC 6598 definiert diesen Bereich genau für solche Bereitstellungen, und deshalb ist sein Auftauchen im WAN-Feld ein starkes Signal und keine Kuriosität. Zwei Übersetzer im Pfad machen die Spur weniger deutlich, lesen Sie also das Muster statt einer einzelnen Zeile.

Manche Anbieter zeigen die zugewiesene Adresse nur im Kundenportal, also schauen Sie dort nach, bevor Sie schließen, dass der Router lügt. Eine Portaladresse, die zu Ihrer externen Beobachtung passt, während der Router etwas anderes meldet, ist der klarste Beleg für einen Übersetzer weiter oben. Halten Sie beide Seiten im Änderungsprotokoll fest, denn die Diskussion darüber, wem welche Grenze gehört, läuft mit zwei datierten Bildern viel schneller.

Bestätigen Sie Lauscher und Weiterleitung

Ein LAN-Test beweist, dass der Dienst lokal funktioniert, und beweist nichts über die Erreichbarkeit von außen. Viele Router beantworten ihre eigene Weiterleitungsregel von innen, sodass ein Hairpin-Test gelingt, während der externe Pfad noch geschlossen ist. Bestätigen Sie, dass der Daemon an die Adresse und den Port gebunden ist, die Sie vermuten, und testen Sie dann von außen. Alles Folgende ist nur zum Lesen.

ss -lunp | grep -E '1194|51820'
ip -4 addr show | grep -E 'inet '
curl -s --max-time 5 ifconfig.me
traceroute -n -m 5 1.1.1.1

Zeigt der externe Test, dass kein Paket am Router ankommt, ist der Verlust weiter oben passiert, und keine lokale Regel wird das beheben. Kommen Pakete an und antwortet nichts, ist der Lauscher oder die Firewall des Hosts die nächste Grenze. Ein Paketmitschnitt auf dem Host entscheidet, welches der beiden Sie vor sich haben, und dauert kürzer als eine weitere Runde Regelsraten. Halten Sie Lauscher und Transport beim Vergleichen unverändert, sonst beantwortet der nächste Test eine andere Frage.

Ändern Sie die Topologie, nicht dieselbe Regel

Gehört der Übersetzer dem Anbieter, ist die Lösung ein anderer Pfad und keine weitere Weiterleitung. Ein kleiner VPS mit öffentlicher Adresse, über einen ausgehenden Tunnel von der Heimseite verbunden, stellt einen erreichbaren Endpunkt vor den Dienst. Eine vom Anbieter bereitgestellte öffentliche Adresse ist einfacher, wo es sie gibt, und meist billiger als eine eigene Maschine. IPv6 beseitigt die Übersetzung ganz, sofern das Clientnetz, die DNS-Einträge und die Firewall-Richtlinie alles unterstützen.

Dynamisches DNS aktualisiert nur einen Namen; es schafft keine Erreichbarkeit, und zeigt man es auf eine gemeinsame Adresse, schickt es Clients zu einem Anbieter-Gateway, das auch andere Teilnehmer nutzen. Dieser Fehler sieht genau wie ein toter Server aus, deshalb ist der Beleg aus den früheren Schritten wichtig. Notieren Sie, auf welche Adresse der Name bei fehlgeschlagenem Test aufgelöst wurde, und bewahren Sie die Antwort beim Testergebnis auf.

Schreiben Sie den Plan um die Grenze herum neu, die Sie kontrollieren: den Lauscher, den Tunnel und die Routen. Lassen Sie die alte Weiterleitung nur stehen, solange sie noch etwas Wahres beschreibt, denn eine Regel, die nicht mehr zur Topologie passt, ist schlimmer als keine Regel. Halten Sie fest, welche Schicht tatsächlich blockierte und welcher Beleg das zeigte. Sonst wiederholt die nächste Person, die die Verwaltungsseite öffnet, jeden Schritt dieses Wegs von vorn.