So prüfen Sie, was ein VPN unter Windows in PowerShell tatsächlich weiterleitet

Ich verband den VPN-Client auf einem Windows-11-Laptop, die Kachel wechselte auf Verbunden, eine interne Dateifreigabe öffnete sich, und eine öffentliche Website lud weiterhin direkt über das Büro-WLAN. Diese Mischung sieht nach einem kaputten Tunnel aus. Sie ist die normale Ausgabe eines Profils, das einen Teil des Verkehrs über das VPN schickt und den Rest auf dem physischen Adapter lässt. Erzwungenes Tunneling ändert, welche Standardroute Windows bevorzugt; es löscht keine spezifischeren Routen und verspricht nicht, dass der Verkehr stoppt, wenn die Verbindung abbricht. Was folgt, ist die Reihenfolge, die ich durchgehe, wenn ein Client Abdeckung behauptet: Client-Zustand, gespeichertes Profil, angewandte Routen, Resolver, dann echte Flows.

Beim Client anfangen und ihm dann nicht mehr trauen

Der Client ist nur deshalb der richtige Ausgangspunkt, weil er Ihnen sagt, welches Profil aktiv ist. Öffnen Sie die Verbindungseigenschaften und notieren Sie den genauen Profilnamen, ob es für den aktuellen Benutzer oder für alle auf dem Rechner erstellt wurde und welcher Adapter nach dem Verbinden in ncpa.cpl erscheint. Auf meinem Testlaptop trug der Adapter den Profilnamen, was die Routenausgabe leicht lesbar machte. Auf anderen Rechnern erscheint er als WAN-Miniport-Eintrag, und der Name sagt Ihnen nichts.

Was der Client Ihnen nicht sagen kann, ist die Abdeckung. Eine verbundene Kachel beschreibt den Zustand des Tunnels, kein Verzeichnis der Ziele. Auch Drittanbieter-Clients führen ihre eigene Konfiguration, daher kann das native Windows-Profil und jede Eigenschaft, die Sie daraus lesen werden, nichts mit dem zu tun haben, was dieser Client installiert hat. Wenn das VPN über AnyConnect, OpenVPN GUI, WireGuard oder einen Hersteller-Agenten kam, gelten die folgenden PowerShell-Prüfungen meist nicht, und Sie sollten stattdessen die eigenen Split-Tunnel- und Routing-Einstellungen dieses Clients lesen.

Lesen Sie das gespeicherte Profil, nicht die Kachel

Bei einem nativen Windows-Profil (IKEv2, L2TP, SSTP oder einem per MDM verteilten) ist die gespeicherte Split-Tunnel-Entscheidung eine einzige Eigenschaft:

Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffix

Fügen Sie -AllUserConnection hinzu, wenn das Profil für alle auf dem Gerät erstellt wurde. Ohne dies lesen Sie die Liste des aktuellen Benutzers, die leer sein oder einen anderen Eintrag mit ähnlichem Namen enthalten kann. Der Wert False in SplitTunneling bedeutet, dass das Profil als voller Tunnel gespeichert wurde: Windows installiert eine Standardroute über den VPN-Adapter. True bedeutet Split-Tunnel, und die Abdeckung hängt dann vollständig von den Routen und Namensauflösungsregeln ab, die das Profil verteilt.

Behandeln Sie diesen Wert als Konfiguration, nicht als Beobachtung. Er hält fest, was das Profil beim Verbinden angefordert hat. Windows kann am Ende abweichende angewandte Routen haben, wegen einer spezifischeren Route einer anderen Schnittstelle, einer Richtlinieneinstellung oder eines Rests einer früheren Verbindung, sodass der Boolean die Frage nie allein entscheidet.

Vergleichen Sie den gespeicherten Wert mit der angewandten Routing-Tabelle

Listen Sie nach dem Verbinden die Routen auf dem Tunneladapter auf, statt die ganze Tabelle zu durchlaufen:

$vpn = Get-NetAdapter | Where-Object InterfaceDescription -match 'VPN|WAN Miniport'
Get-NetRoute -InterfaceIndex $vpn.ifIndex | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.20.4.15 | Select-Object -First 1

Find-NetRoute ist die nützliche Hälfte. Es beantwortet die Frage, die der Client nie beantwortet: Welche Schnittstelle und welche Quelladresse wird Windows für dieses Ziel tatsächlich verwenden? Führen Sie es für einen internen Host, einen öffentlichen Host und alles aus, was Sie für eine bewusste Ausnahme halten. Ein Volltunnelprofil sollte für die öffentliche Adresse die Tunnelschnittstelle zeigen. Ein Split-Tunnel-Profil zeigt dort meist den physischen Adapter, während interne Präfixe weiterhin über das VPN aufgelöst werden.

Zwei Fallen erklären die meisten Meldungen „es routet falsch“. Das spezifischste Präfix gewinnt immer, daher schlägt ein /24 auf dem physischen Adapter eine Standardroute über das VPN, egal wie niedrig die Metrik des Tunnels ist. Die Metrik entscheidet nur Gleichstände zwischen Routen für dasselbe Präfix. Und IPv4 und IPv6 werden getrennt entschieden: Ein Profil, das 0.0.0.0/0 abdeckt, kann IPv6 auf dem lokalen Link lassen, wodurch eine Dual-Stack-Seite halb getunnelt wirkt. Prüfen Sie Get-NetRoute -AddressFamily IPv6, bevor Sie schließen, dass der Tunnel in Ordnung ist.

Prüfen Sie die Namensauflösung separat mit der NRPT

Interne Namen, die fehlschlagen, während interne IP-Adressen funktionieren, deuten auf die Resolver-Richtlinie hin, nicht auf das Routing. Windows entscheidet DNS pro Namespace über die Tabelle der Namensauflösungsrichtlinie, die von der Routing-Tabelle unabhängig ist:

Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndex

Wenn eine Regel auf *.corp.example passt, gehen Abfragen für diesen Namespace an die DNS-Server des Tunnels, selbst wenn der Datenpfad zu diesen Servern im Split-Tunnel-Modus auf dem physischen Adapter bleibt. Das ist das Design, und deshalb sagt ein Browsertest, der eine öffentliche Seite öffnet, nichts über interne Namen. Wenn der Adapter die erwarteten Server auflistet, Abfragen aber trotzdem woanders hingehen, vergleichen Sie die Reihenfolge der NRPT-Regeln und prüfen Sie, ob ein spezifischerer Namespace zuerst passt.

Prüfen Sie die Flows und entscheiden Sie dann, was Sie eigentlich verlangt haben

Gehen Sie Ziele in fester Reihenfolge durch, damit Ergebnisse über Rechner hinweg vergleichbar sind: eine öffentliche Adresse, eine interne Adresse, ein interner Name und eine bewusste Ausnahme wie ein lokaler Drucker oder ein Videoanruf. Notieren Sie die Schnittstelle und Quelladresse, die Find-NetRoute jeweils zurückgibt. Nach jeder Richtlinienänderung verbinden Sie neu und wiederholen dieselben vier Prüfungen; die Routing-Tabelle nach dem Neuverbinden ist der einzige Beleg, dass das neue Profil wirksam wurde.

Trennen Sie dann Routing von Durchsetzung. Erzwungenes Tunneling bevorzugt den Tunnel für abgedeckten Verkehr, solange er steht. Es ist kein Kill Switch. Wenn die Anforderung ist, dass nichts den Rechner verlässt, wenn der Tunnel fällt, muss das aus einem blockierenden Design kommen: ein an den Tunnelzustand gebundenes Firewall-Profil, ein Always-On-Profil mit Verkehrsfiltern oder die eigene Fail-Closed-Option des Herstellerclients. Erzwungenes Tunneling muss außerdem die eigene Adresse des VPN-Servers außerhalb des Tunnels erreichbar lassen, und sie im Namen von „alles erzwingen“ zu blockieren ist ein zuverlässiger Weg, sich aus der Verbindung auszusperren, die Sie durchsetzen wollen.

Bevor Sie etwas ändern, gehen Sie diese Liste durch. Jeder Punkt, der fehlschlägt, grenzt ein, wo das eigentliche Problem liegt.

• Profilname und -umfang bestätigt, mit -AllUserConnection für rechnerweite Profile.
• SplitTunneling gelesen und als Konfiguration statt als Beleg für Abdeckung behandelt.
• Tunneladapter-Routen getrennt für IPv4 und IPv6 aufgelistet.
• Find-NetRoute für ein öffentliches, ein internes und ein Ausnahmereziel ausgeführt.
• NRPT-Regeln geprüft, bevor Routen für einen Namensfehler beschuldigt wurden.
• Blockierungsanforderung erneut gelesen: bevorzugtes Routing ist nicht dasselbe wie durchgesetzte Blockierung.

Die Entscheidung für vollen oder geteilten Tunnel gehört demjenigen, der das Profil besitzt, und Microsofts Routing-Hinweise beschreiben das Verhalten, das Windows umsetzt, wenn ein Profil es setzt. Microsoft: erzwungenes und geteiltes Tunneling ist die Referenz, die ich beim Lesen der Ausgabe offen halte.