VPN in einem reinen Web-Netz blockiert? Arbeiten Sie die Schichten ab

Ein Campus- oder Hotelnetz, in dem der Browser läuft und jeder Tunnel stirbt, ist kein Problem, sondern vier übereinander. Der Pfad erlaubt vielleicht nur TCP 443, verlangt einen authentifizierten Proxy, prüft den Handshake oder verbietet Fernzugriff einfach per Richtlinie. Wenn man sie der Reihe nach abarbeitet, kauft man keinen neuen Client, um eine Netzregel zu reparieren. Das Runbook unten dauert etwa zehn Minuten und endet mit einer schriftlichen Antwort, welche Schicht Sie abgewiesen hat.

Beweisen Sie, welche Schicht die Verbindung abweist

Fangen Sie nicht beim VPN-Client an. Beginnen Sie mit einer einfachen HTTPS-Anfrage an denselben Host und lesen Sie die Zeitphasen, denn die Phase, die scheitert, sagt Ihnen, welches Gerät verantwortlich ist:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

Keine Antwort und keine connect-Zeit heißt, TCP kam nie zustande, also spielen eine Firewall, eine Proxy-Anforderung oder ein falsches Ziel eine Rolle. Eine connect-Zeit ohne tls-Zeit heißt, etwas in der Mitte nahm die Verbindung an und blockierte dann den Handshake, und genau so sieht ein prüfender Proxy aus Client-Sicht aus.

Prüfen Sie nun das Zertifikat, das Sie tatsächlich erhalten. Das ist der schnellste Weg herauszufinden, ob Sie mit dem Server oder mit einer Middlebox sprechen, die die Sitzung neu signiert hat:

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

Lesen Sie die Ausstellerzeile. Ihre eigene CA heißt, Sie haben den Dienst erreicht; ein Unternehmens- oder Geräteaussteller heißt, ein Filter hat die Verbindung beendet und entscheidet, was als Nächstes passiert. Halten Sie beide Ausgaben mit Zeitstempel fest, denn derselbe Test eine Stunde später im Gästenetz kann eine andere Antwort geben.

Ein proxybewusster Client ändert das erste Paket, nicht die Richtlinie

Verlangt das Netz CONNECT über einen authentifizierten Proxy, muss der VPN-Client davon wissen, sonst versucht er, einen Socket zu einer Adresse zu öffnen, die er nicht routen kann. Testen Sie den Proxy getrennt vom Client, damit ein Fehler eine Erklärung hat:

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

Der erste Befehl beweist, dass der Proxy das Ziel trägt. Der zweite fordert den Client auf, TCP auf 443 zu verwenden, den einzigen Transport, den die meisten reinen Web-Pfade überhaupt weiterleiten. Wenn der erste Befehl gelingt und der zweite weiter scheitert, ist der Proxy nicht das Hindernis.

Manche Clients lesen den Proxy des Betriebssystems statt einer Überschreibung, manche lesen keines von beiden. Prüfen Sie die Dokumentation der Anwendung, bevor Sie annehmen, eine systemweite Einstellung gelte. Ein Client, der den Endpunkt über einen Resolver auflöst, den der Proxy nicht bedient, scheitert hier ebenfalls, und deshalb kann eine DNS-Änderung wie eine Lösung aussehen, wenn sie nur ein Umweg ist.

Achten Sie dabei auch auf das Lenkungsmuster. Ein gefiltertes Netz kann auf den Erkennungshostnamen eines Anbieters mit etwas Eigenem antworten, was ändert, welches Proxyprofil der Client wählt. Bauen Sie keinen Prozess um diese Eigenheit. Sie variiert je Standort, ändert sich ohne Ankündigung und ist nichts, was Sie für andere unterstützen können.

Port 443 ist erreichbar, nicht erlaubt

Einen Tunnel auf 443 in TLS zu verpacken löst die Erreichbarkeit und nichts weiter. Ein Filter, der den Port prüft, lässt ihn durch; ein Filter, der den Handshake mit einem Fingerabdruck vergleicht, nicht, und verschlüsseltes Client Hello verbirgt den Servernamen nur, wenn beide Seiten es unterstützen. Führen Sie den Test aus und finden Sie heraus, hinter welcher Art Filter Sie stecken, statt zu hoffen.

Es gibt auch einen Leistungspreis, den Leute später entdecken. Ein zuverlässiger Transport in einem zuverlässigen Transport verstärkt Verluste, weil der innere Stack Segmente erneut sendet, die der äußere bereits erneut gesendet hat. Auf einer sauberen Strecke merkt das niemand. In einem überlasteten Campus-WLAN wird der Tunnel genau dann unbrauchbar, wenn Sie ihn brauchen, und der Graph sieht wie Paketverlust aus, obwohl nichts absichtlich verworfen wird.

UDP ist meist das erste Opfer, und das sollte man bestätigen statt vermuten. Wenn WireGuard oder das Standard-OpenVPN nie einen Handshake abschließt, während TCP 443 funktioniert, verwirft das Netz UDP, und keine Schlüssel-Neuerzeugung ändert das:

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

Ein leerer Handshake-Zeitstempel neben einem Peer, der gestern lief, ist die UDP-Antwort. Die beiden DNS-Abfragen beantworten eine andere Frage: wenn lokaler und öffentlicher Resolver sich über die Endpunktadresse uneinig sind, werden Sie gelenkt, und das Transportargument ist das falsche.

Prüfen Sie, was die Maschine tatsächlich verlassen hat

Client-Logs beschreiben, was der Client glaubt. Ein Mitschnitt beschreibt, was das Netz sah, und die Differenz zwischen beiden ist der Ort, an dem die meisten dieser Fälle gelöst werden:

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

Sehen Sie SYN-Pakete und kein SYN-ACK, liegt die Blockade stromaufwärts und der Client ist unschuldig. Sehen Sie einen abgeschlossenen Handshake zu einer Adresse, die nicht die des Servers ist, sprechen Sie mit einem Proxy oder einem Abfänger. Sehen Sie gar nichts, prüfen Sie, ob Sie auf der richtigen Schnittstelle mitgeschnitten haben, bevor Sie etwas schließen.

Die Socket-Auflistung fängt einen subtileren Fall: ein zweiter Tunnel hält bereits die Standardroute. Zwei Clients, die um die Routing-Tabelle kämpfen, erzeugen zeitweise Fehler, die genau wie ein blockiertes Netz aussehen, und der Mitschnitt zeigt Verkehr, der über eine Schnittstelle hinausgeht, die Sie nicht erwartet haben.

Rückbau und die Notiz, die es wert ist

Machen Sie die Änderungen in umgekehrter Reihenfolge rückgängig. Entfernen Sie die Proxy-Variablen, stoppen Sie den von Hand gestarteten Client und entfernen Sie jede Routen- oder Resolver-Überschreibung, die Sie hinzugefügt haben:

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

Einen von Hand gestarteten Client laufen zu lassen, ist der Weg, auf dem ein Laptop beim nächsten Bürobesuch mit kaputtem Netz dasteht. Proxy-Variablen in einem Shell-Profil brechen Wochen später unabhängige Werkzeuge, und wer sie debuggt, wird die beiden Ereignisse nicht verbinden.

Schreiben Sie dann vier Zeilen: das Netz, den Zeitstempel, die gescheiterte Phase und den gesehenen Aussteller. Ein Pfad, der auf einem Campus funktioniert und auf dem nächsten scheitert, ist normal, und die nächste Person muss wissen, ob der Unterschied Proxy, Resolver oder Filter war. Wenn die Antwort ist, dass das Netz Fernzugriff verbietet, hören Sie dort auf und fragen Sie den Administrator nach dem unterstützten Weg, statt einen Workaround in eine Richtlinie zu tragen, die Sie nicht gelesen haben.