VPN verbindet zu Hause, läuft im Hotel-WLAN aber in eine Zeitüberschreitung

Der Laptop verbindet sich mit dem Heim-WLAN, der Client baut in drei Sekunden eine Verbindung auf, und dasselbe Profil scheitert eine Stunde später im Hotel. Dazwischen wurde nichts aktualisiert. Das mit einem Kunden vor sich durchzugehen dreht sich vor allem darum zu wissen, welcher Fehler zu welcher Phase gehört, denn die nützliche Information steckt im Code, den der Client ausgibt, nicht in der Tatsache, dass er gescheitert ist. Arbeite die vier Schritte unten der Reihe nach ab, und du weißt, ob ein Name, ein Paket, ein Port oder eine Richtlinie dich abgewiesen hat.

Lies den Fehlercode als Phase, nicht als Urteil

Der Client erreicht drei getrennte Meilensteine, bevor ein Tunnel existiert. Er löst den Servernamen auf, er erhält eine Antwort von irgendetwas im Netz, und er handelt eine Sicherheitsassoziation aus. Jeder Meilenstein hat seine eigene Fehlermeldung, und gerade Windows ist großzügig mit unterschiedlichen Codes, sobald man weiß, zu welcher Phase sie gehören.

Zwei dieser Codes bedeuten, dass das Netz unschuldig ist. Eine 789 heißt, dass Pakete flossen und sich beide Enden über Krypto uneinig waren, was ein Konfigurationsproblem ist, das du zu Hause beheben kannst. Eine 868 heißt, dass kein Paket je hinausmusste, der Tunnelentwurf also irrelevant ist, bis der Name aufgelöst wird. Den Code der richtigen Phase zuzuordnen spart mehr Zeit als jede Aufzeichnung, weil sie dir sagt, welchen der nächsten drei Schritte du überspringen kannst.

Sei angemessen vorsichtig, wenn der Client nicht Windows ist. Drittanbieter-Clients fallen bei den meisten davon auf "Verbindung fehlgeschlagen" zusammen, weshalb sich die nächsten zwei Schritte überhaupt nicht auf die Meldung verlassen.

Prüfe den Namen, bevor du den Tunnel beschuldigst

Hotel- und Flughafennetze fangen ständig DNS ab, und ein Resolver, der mit einer Portaladresse antwortet, erzeugt einen Fehler, der genau wie ein toter Server aussieht. Vergleiche, was der lokale Resolver sagt, mit dem, was ein öffentlicher Resolver sagt:

Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"

Unterscheiden sich die beiden Antworten, wirst du umgeleitet, und der Rest der Diagnose ist verschwendet, bis das geklärt ist. Gerade eine Portaladresse nimmt die TCP-Verbindung bereitwillig an und bleibt dann stehen, weshalb es wie ein Firewall-Block aussehen kann, wenn du mit einem Browser testest.

Bestätige nun, dass die Adresse, die du erreichen willst, auch die verwendete ist. Manche Clients cachen die frühere Auflösung für die Lebensdauer des Profils, sodass eine Wiederverbindung nach der DNS-Änderung noch zur alten Adresse geht. Schließe den Client vollständig, bevor du erneut testest, statt im selben Fenster auf Trennen und Verbinden zu drücken.

Finde heraus, welches äußere Paket verschwindet

Der Tunnel hat einen äußeren Fluss, der ganz zum Pfad zwischen dir und dem Server gehört, und genau diesen Fluss klassifizieren Middleboxes und verwerfen ihn. Zeichne ihn am Client auf und vergleiche dann ein funktionierendes Netz mit dem scheiternden. Unter Windows reicht die eingebaute Aufzeichnung für einen ersten Blick:

pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etl

Du willst sehen, ob deine Pakete überhaupt hinausgehen und ob etwas zurückkommt. Pakete hinaus ohne Rückkehr bedeuten, dass der Pfad oder das ferne Ende sie verwirft; gar nichts hinaus bedeutet, dass der Client nie bis zum Senden kam, was auf die Namensauflösung oder auf eine lokale Firewall-Richtlinie zurückweist.

Wiederhole denselben Test über einen Handy-Hotspot. Das ist der einzige wirklich informative Vergleich, den du hast, denn er entfernt jede Box im Hotel aus dem Pfad, während Laptop, Client und Zugangsdaten gleich bleiben. Kommt der Tunnel über den Hotspot zustande, hör auf, den Server anzusehen. Scheitert er auch dort, hast du ein Client- oder Kontoproblem, das das Netz nie verursacht hat.

Ändere einen Transport und teste erneut

Weißt du einmal, dass der äußere Fluss verworfen wird, ist die praktische Frage, welchen Fluss das Netz überhaupt zulässt. Die meisten eingeschränkten Netze erlauben ausgehendes TCP 443, weil sie sonst nicht funktionieren, also ist der übliche Rat, den Listener dorthin zu verlegen. Bei OpenVPN ist das ein Schalter auf der Clientseite, bis der Server geändert wird:

openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4

IPsec-Clients haben einen entsprechenden Schalter in ihren eigenen Einstellungsfenstern, meist als IPsec über TCP oder NAT-Traversal bezeichnet. Ihn zu ändern ist ebenfalls eine Diagnose: Kommt der Tunnel über TCP zustande und stirbt über UDP, hast du bewiesen, dass das Netz UDP filtert, und du hast auch die Einstellung gefunden, die du bei jedem Besuch dieses Standorts brauchen wirst.

Widerstehe der Versuchung, Routerfunktionen beim ersten Versuch abzuschalten. Stateful Inspection oder Flut-Schutz in einem Hotelnetz abzuschalten steht dir ohnehin nicht zur Verfügung, und auf eigener Hardware tauschst du einen echten Schutz gegen einen Laptop. Notiere, welche Einstellung das Ergebnis geändert hat, stelle sie dann zurück und suche einen Transport, den das Netz bereits erlaubt.

Prüfe dasselbe Profil im zweiten Netz

Bevor du das Ticket schließt, beweise, dass die Änderung das Verlassen des Gebäudes überlebt hat. Verbinde dich im ursprünglichen Netz mit den ursprünglichen Einstellungen erneut, zeichne die ersten dreißig Sekunden auf und bestätige, dass der Client denselben Zustand erreicht wie am Hotspot:

pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddress

Die Unterscheidung, die der letzte Befehl freilegt, lohnt sich zu behalten: Das Profil kann einen verbundenen Tunnel melden, während das Routing darin falsch ist, und das erzeugt "das VPN ist oben, aber nichts funktioniert", was ein anderer Artikel ist. Hat sich der Tunneltyp nach deiner Änderung geändert, ist das Profil nicht das, das du getestet hast.

Schreibe den Befund dann dorthin, wo die nächste Person nachsehen wird. "Firmenprofil braucht an diesem Standort TCP 443; UDP 500 wird vom Hotel gefiltert" ist ein Satz, auf den ein Kollege reagieren kann. "VPN ist in Hotels wackelig" ist es nicht, und das garantiert, dass dieselbe Stunde nächsten Monat erneut verbraucht wird.