VPN verbunden, aber die IP-Adresse hat sich nicht geändert: warum

Sie verbinden sich, der Client meldet „verbunden“, und der Adresstest zeigt weiterhin dieselbe Nummer wie zuvor. Mit der Anzeige ist nichts falsch; etwas zwischen Profil und Anwendung hielt diese Anfrage außerhalb des Tunnels. Entscheiden Sie, welchen von drei Fällen Sie vor sich haben, bevor Sie irgendeine Konfiguration anfassen: einen Test, der nie die öffentliche Adresse gemessen hat, einen Tunnel, der nur einen Teil des Verkehrs abdeckt, oder einen zweiten Pfad, der die Routing-Entscheidung gewinnt. Jeder Fall hat eine Prüfung, die unter einer Minute dauert.

Bestätigen Sie, was der Test tatsächlich gemessen hat

Die im Wi-Fi- oder Ethernet-Dialog angezeigte Adresse ist die Schnittstellenadresse in Ihrem eigenen Segment, nicht die Adresse, die eine Website sieht; sie kann also gleich bleiben, während der Tunnel einwandfrei arbeitet. Der Standort ist wieder ein eigenes Signal: Eine gespeicherte Kontoregion oder eine erlaubte Geolokalisierungsmessung bewegt sich nicht, wenn Sie den Ausgang wechseln, und eine Anmeldung, die Sie bereits erkennt, ebenso wenig.

Nutzen Sie ein Echo der öffentlichen Adresse und fragen Sie jede Familie getrennt, denn ein Testergebnis mit Dual-Stack verbirgt den interessanten Fall:

curl -4 -s https://ifconfig.me
curl -6 -s https://ifconfig.me

Führen Sie beide vor und nach dem Verbinden aus. Ändert sich die IPv4-Antwort auf die Ausgangsadresse und die IPv6-Antwort nicht, haben Sie keinen defekten Tunnel; eine Familie fährt außerhalb davon. Bleiben beide Antworten gleich, hat die Anfrage den Tunnel überhaupt nicht erreicht, und der Rest hier gilt.

Das Profil deckt möglicherweise nur einen Teil des Verkehrs ab

Ein Split-Tunnel-Profil ist die übliche Antwort, und es ist kein Fehler. OpenVPN schickt alles nur dann durch den Tunnel, wenn redirect-gateway in den übergebenen Optionen steht; ohne sie erhält der Client eine Handvoll konkreter Routen, und Ihre Standardroute bleibt auf der physischen Verbindung. Unter Windows erscheint derselbe Schalter als „Standardgateway im Remote-Netzwerk verwenden“ in den IPv4-Eigenschaften des Adapters, und ihn zu deaktivieren ist eine bewusste Wahl, die jede Neuverbindung übersteht.

Der Bereich pro Anwendung ist die zweite Ebene. Die VPN-Einstellung pro App in Android entscheidet, welche Apps einbezogen sind, daher beweist der VPN-Schlüssel in der Statusleiste nicht, dass der Browser darin liegt. Eine Browsererweiterung, die ihren eigenen Verkehr proxyt, erzeugt das Spiegelbild: Der Browser zeigt die Ausgangsadresse, während ein Mailclient oder Spiel auf derselben Maschine weiterhin Ihre zeigt. Vergleichen Sie dieselbe Anfrage in zwei Anwendungen. Ändert sich die eine und die andere nicht, betrachten Sie den Bereich, nicht einen fehlerhaften Tunnel.

Eine Adressfamilie kann weiterhin direkt gehen

Die meisten VPN-Profile wurden für IPv4 geschrieben, und viele sind es noch. In einem Dual-Stack-Netz nimmt der Tunnel 10.8.0.x für IPv4, während die physische Verbindung eine globale IPv6-Adresse und eine Standardroute behält, sodass eine IPv6-fähige Site direkt erreicht wird und die gemeldete Adresse die Ihres Anbieters ist. Das ist ein Leck bei funktionierendem IPv4-Tunnel, und es ist für einen Test unsichtbar, der nur IPv4 spricht.

ip -4 route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

Lesen Sie in jeder Antwort die Schnittstelle. Nennt die IPv6-Abfrage Ihr Ethernet- oder Wi-Fi-Gerät, während die IPv4-Abfrage den Tunnel nennt, fehlt die Richtlinie für diese Familie, statt defekt zu sein. IPv6 geräteweit abzuschalten lässt das Symptom verschwinden und verbirgt die Entscheidung; reparieren Sie lieber die Abdeckung des Profils oder deaktivieren Sie die Familie nur auf dieser einen Verbindung, und notieren Sie, welche der beiden Möglichkeiten Sie gewählt haben.

Ein zweiter Pfad kann die Abfrage gewinnen

Ein konkurrierender Proxy, ein zweiter VPN-Client, ein virtueller Adapter aus einem Container oder Remote-Desktop-Werkzeug oder eine zusätzliche Route für genau das Präfix, das Sie testen, können alle Vorrang bekommen. Eine spezifische Route schlägt immer eine Standardroute, daher schickt eine übrig gebliebene /24 für die Site, die Sie messen, die auf Ihr LAN-Gateway zeigt, diesen Verkehr weiterhin außerhalb des Tunnels, so gesund der Tunnel auch ist.

Erstellen Sie eine Bestandsaufnahme, bevor Sie etwas ändern, mit Nur-Lese-Befehlen:

route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
nmcli connection show --active

Suchen Sie nach mehr als einer Standardroute mit plausibler Metrik und nach einer spezifischen Route, die das Ziel abdeckt. Prüfen Sie im Browser außerdem, ob eine Proxy-Erweiterung oder die System-Proxy-Einstellung die Verbindung besitzt; eine Erweiterung kann ihr eigenes Upstream nennen und den Ausgang des Betriebssystems unberührt lassen, was im Browser eine andere Adresse erzeugt als in einem Terminal auf derselben Maschine.

Messen Sie mit einer frischen Anfrage erneut

Verbinden Sie neu und wiederholen Sie dann die Messung aus derselben Anwendung, mit der Sie beim ersten Mal getestet haben, denn eine zwischengespeicherte Seite oder eine wiederverwendete Verbindung meldet den alten Zustand. Beobachten Sie während des Verbindens das Protokoll oder die Ereignisansicht des Clients: Ein Fehler beim Anwenden von Routen nach der Authentifizierung ist stärkerer Beweis als jede Anzeige, und er nennt meist die Route oder den Adapter, der fehlgeschlagen ist.

Halten Sie zwei Ergebnisse auseinander. Ändert sich die Adresse, aber eine Site lehnt Sie weiterhin ab, funktioniert der Tunnel, und die Site weist eine Rechenzentrumsadresse zurück; das ist ein anderes Problem mit einer anderen Antwort. Ändert sich die Adresse nie, arbeiten Sie die vier Fragen der Reihe nach ab: Welche Adresse hat der Test ausgegeben, welche Familie war es, welche Anwendung hat die Anfrage gestellt, und welcher Route folgte diese Anfrage. Die Microsoft-Dokumentation zu VPN-Routingentscheidungen erklärt, wie ein Windows-Client zwischen Tunnel und physischem Adapter wählt, wenn beide eine Route haben.