Wéi ee kontrolléiert, wat eng VPN op Windows a PowerShell wierklech routet

Ech hunn de VPN-Client op engem Windows 11-Laptop verbonnen, d'Kachel ass op Connected gaangen, eng intern Dateifreigab huet sech opgemaach, an eng ëffentlech Säit huet sech nach ëmmer direkt vum Büro-Wi-Fi gelueden. Dës Mëschung gesäit aus wéi en futti Tunnel. Et ass awer den normale Resultat vun engem Profil, deen en Deel vum Traffic duerch d'VPN schéckt an de Rescht um physeschen Adapter léisst. Erzwongene Tunnel ännert, wéi eng Standardroute Windows preferéiert; en läscht keng méi spezifesch Route fort an et versprécht net, datt den Traffic stoppt, wann d'Verbindung fällt. Duerno kënnt d'Reihenfolge, déi ech duerchgoen, wann e Client Ofdeckung behaapt: Client-Zoustand, gespäicherte Profil, ugewannte Routen, Resolver, duerno richteg Flëss.

Fänkt beim Client un, a stoppt dann him ze vertrauen

De Client ass just dofir de richtege Startpunkt, well en Iech seet, wéi ee Profil aktiv ass. Maacht d'Verbindungseigenschaften op an notéiert de genauen Profilnumm, ob en fir de momentane Benotzer oder fir jiddereen op der Maschinn ugeluecht gouf, a wéi een Adapter no der Verbindung an ncpa.cpl erschéngt. Op mengem Testlaptop huet den Adapter de Profilnumm gedroen, wat d'Routenausgab liicht ze liese gemaach huet. Op anere Maschinne erschéngt en als WAN Miniport-Andro an den Numm seet Iech näischt.

Wat de Client Iech net ka soen, ass d'Ofdeckung. Eng verbonne Kachel beschreift den Zoustand vum Tunnel, net eng Inventaire vun Destinatiounen. Drëttpartei-Cliente halen och hir eege Konfiguratioun, dofir kann de native Windows-Profil, an all Eegenschaft, déi Dir doraus liest, näischt mam deem ze dinn hunn, wat dee Client installéiert huet. Wann d'VPN iwwer AnyConnect, OpenVPN GUI, WireGuard oder en Händler-Agent komm ass, gëllen d'PowerShell-Prüfunge hei drënner meeschtens net an Dir sollt amplaz d'eege Split-Tunnel- an Routing-Astellunge vun deem Client liesen.

Liest de gespäicherte Profil, net d'Kachel

Fir en native Windows-Profil (IKEv2, L2TP, SSTP oder een deen MDM dréckt) ass déi gespäichert Split-Tunnel-Entscheedung eng eenzeg Eegenschaft:

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

Füügt -AllUserConnection derbäi, wann de Profil fir jiddereen um Gerät ugeluecht gouf. Ouni dat liest Dir d'Lëscht vum momentane Benotzer, déi eidel ka sinn oder en aneren Andro mat engem ähnlechen Numm ka enthalen. De Wäert False an SplitTunneling bedeit, datt de Profil als vollen Tunnel gespäichert gouf: Windows installéiert eng Standardroute duerch den VPN-Adapter. True bedeit Split-Tunnel, an d'Ofdeckung hänkt dann komplett vun de Routen an Nummopléisungsregele of, déi dee Profil dréckt.

Behandelt dee Wäert als Konfiguratioun, net als Observatioun. En hält fest, wat de Profil bei der Verbindung ugefrot huet. Windows ka mat aneren ugewannte Routen ophalen, wéinst enger méi spezifescher Route vun engem aneren Interface, enger Richtlinn-Astellung oder engem Rescht vun enger fréierer Verbindung, dofir entscheet de Boolean d'Fro ni eleng.

Vergläicht de gespäicherte Wäert mat der ugewannte Routentabell

Nom Verbannen, listet d'Routen um Tunneladapter op, amplaz déi ganz Tabell duerch ze scrollen:

$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 ass déi nëtzlech Halschent. Et beäntwert d'Fro, déi de Client ni beäntwert: fir dës Destinatioun, wéi en Interface a wéi eng Quelladress wäert Windows tatsächlech benotzen? Fuert et fir e internen Host, en ëffentlechen Host an alles aus, wat Dir als bewosst Ausnam betruecht. E Volltunnel-Profil sollt den Tunnelinterface fir déi ëffentlech Adress weisen. E Split-Tunnel-Profil weist do meeschtens de physeschen Adapter, während intern Prefixen nach ëmmer op d'VPN opgeléist ginn.

Zwou Falen erklären déi meescht Berichter «et routet an déi falsch Richtung». De spezifeschste Prefix gewënnt ëmmer, dofir schléit en /24 um physeschen Adapter eng Standardroute op der VPN, egal wéi niddereg d'Metrik vum Tunnel ass. D'Metrik entscheet nëmmen Gläichstänn tëscht Routen fir dee selwechte Prefix. An IPv4 an IPv6 gi getrennt entscheet: e Profil, deen 0.0.0.0/0 deckt, kann IPv6 um lokale Link loossen, wat eng Dual-Stack-Säit hallef getunnelt ausgesi léisst. Iwwerpréift Get-NetRoute -AddressFamily IPv6, ier Dir schléisst, datt den Tunnel an der Rei ass.

Iwwerpréift d'Nummoplséisung getrennt mat der NRPT

Intern Nimm, déi feelen, während intern IP-Adressen funktionéieren, deiten op d'Resolver-Richtlinn hin, net op d'Routing. Windows entscheet DNS pro Nummraum iwwer d'Tabell vun der Nummopléisungsrichtlinn, déi onofhängeg vun der Routentabell ass:

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

Wann eng Regel op *.corp.example passt, ginn d'Ufroen fir deen Nummraum un d'DNS-Server vum Tunnel, och wann de Datewee zu deene Server am Split-Tunnel-Modus um physeschen Adapter bleift. Dat ass den Design, an dofir seet en Browsertest, deen eng ëffentlech Säit opmécht, Iech näischt iwwer intern Nimm. Wann den Adapter déi erwaart Server oplëscht, d'Sich awer nach ëmmer soss an d'Luucht geet, vergläicht d'Reihenfolge vun den NRPT-Regele a kontrolléiert, ob en méi spezifeschen Nummraum als éischten passt.

Iwwerpréift d'Flëss, an entscheet dann, wat Dir tatsächlech ugefrot hutt

Gitt d'Destinatiounen an enger fester Reihenfolge duerch, sou datt d'Resultater iwwer Maschinne vergläichbar sinn: eng ëffentlech Adress, eng intern Adress, en internen Numm an eng bewosst Ausnam wéi en lokalen Drécker oder en Videoopruff. Notéiert den Interface an d'Quelladress, déi Find-NetRoute fir all eenzel zréckgëtt. Nom Änneren vun enger Richtlinn, verbënnt Iech erëm a widderhuelt déiselwecht véier Prüfungen; d'Routentabell nom Neiverbannen ass deen eenzege Beweis, datt den neie Profil a Kraaft getrueden ass.

Trennt duerno Routing vun Duerchsetzung. Erzwongenen Tunnel bevorzugt den Tunnel fir ofgedeckten Traffic, soulaang en uewen ass. Et ass kee Kill Switch. Wann d'Ufuerderung ass, datt näischt d'Maschinn verléisst, wann den Tunnel fällt, muss dat aus engem blockéierenden Design kommen: e Firewall-Profil, dat un den Tunnelzoustand gebonnen ass, en ëmmer-aktiv Profil mat Traffic-Filter oder déi eege Fehler-Zoumaach-Optioun vum Händler-Client. Erzwongenen Tunnel muss och d'Adress vum VPN-Server selwer baussent dem Tunnel erreechbar loossen, an se am Numm vun «alles erzwingen» ze blockéieren ass eng zouverlässeg Manéier, sech aus der Verbindung auszespaeren, déi Dir versicht duerchzesetzen.

Ier Dir eppes ännert, gitt dës Lëscht duerch. All Punkt, deen feelt, enkelt an, wou de richtege Problem läit.

• Profilnumm a -ëmfang bestätegt, mat -AllUserConnection fir Profiler op Maschinnen-Niveau.
• SplitTunneling gelies a als Konfiguratioun behandelt, net als Beweis fir Ofdeckung.
• Tunneladapter-Routen getrennt fir IPv4 an IPv6 opgelëscht.
• Find-NetRoute fir eng ëffentlech, eng intern an eng Ausnam-Destinatioun ausgefouert.
• NRPT-Regele gepréift, ier d'Routen fir en Nummfehler beschëllegt goufen.
• D'Blockéierungsufuerderung nach eng Kéier gelies: preferéiert Routing ass net datselwecht wéi duerchgesat Blockéierung.

D'Entscheedung fir vollen oder gedeelten Tunnel gehéiert deen, deen de Profil besëtzt, a Microsoft seng Routing-Notizen beschreiwen d'Verhalen, dat Windows ëmsetzt, wann e Profil et setzt. Microsoft: erzwongenen a gedeelten Tunnel ass d'Referenz, déi ech opgehalen hunn, während ech d'Ausgab liesen.