Sådan kontrollerer du, hvad en VPN på Windows faktisk ruter i PowerShell
En tilsluttet VPN-flise beviser ikke dækning. Læs den gemte profilflag, den aktive rutetabel og NRPT-reglerne i denne rækkefølge.
Jeg tilsluttede VPN-klienten på en Windows 11-bærbar, flisen skiftede til Connected, en intern fildeling åbnede, og et offentligt websted indlæste stadig direkte fra kontorets Wi-Fi. Den blanding ligner en brudt tunnel. Det er det normale resultat af en profil, der sender noget trafik gennem VPN'et og lader resten blive på den fysiske adapter. Tvangstunnelering ændrer, hvilken standardrute Windows foretrækker; den sletter ikke mere specifikke ruter og lover ikke, at trafikken stopper, når forbindelsen falder. Det følgende er den rækkefølge, jeg arbejder igennem, når en klient påstår dækning: klienttilstand, gemt profil, anvendte ruter, resolver og derefter reelle flows.
Start ved klienten, og hold så op med at stole på den
Klienten er det rigtige sted at begynde, kun fordi den fortæller dig, hvilken profil der er aktiv. Åbn forbindelsens egenskaber, og noter det præcise profilnavn, om den blev oprettet til den aktuelle bruger eller til alle på maskinen, og hvilken adapter der vises i ncpa.cpl efter tilslutning. På min testbærbare bar adapteren profilnavnet, hvilket gjorde ruteoutputtet let at læse. På andre maskiner vises den som en WAN Miniport-post, og navnet fortæller dig intet.
Det, klienten ikke kan fortælle dig, er dækning. En tilsluttet flise beskriver tunnelens tilstand, ikke en fortegnelse over destinationer. Tredjepartsklienter holder også deres egen konfiguration, så den native Windows-profil og enhver egenskab, du er ved at læse fra den, har måske intet at gøre med det, den klient installerede. Hvis VPN'et kom via AnyConnect, OpenVPN GUI, WireGuard eller en leverandøragent, gælder PowerShell-kontrollerne nedenfor for det meste ikke, og du bør i stedet læse den klients egne indstillinger for split-tunnel og routing.
Læs den gemte profil, ikke flisen
For en native Windows-profil (IKEv2, L2TP, SSTP eller en, der skubbes af MDM) er den gemte split-tunnel-beslutning én enkelt egenskab:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixTilføj -AllUserConnection, når profilen blev oprettet til alle på enheden. Uden det læser du den aktuelle brugers liste, som kan være tom eller indeholde en anden post med et lignende navn. Værdien False i SplitTunneling betyder, at profilen blev gemt som en fuld tunnel: Windows installerer en standardrute gennem VPN-adapteren. True betyder split-tunnel, og dækningen afhænger så helt af de ruter og navneopløsningsregler, som profilen skubber.
Behandl den værdi som konfiguration, ikke som observation. Den registrerer, hvad profilen bad om ved tilslutning. Windows kan ende med anvendte ruter, der afviger, på grund af en anden interfaces mere specifikke rute, en politikindstilling eller en restpost fra en tidligere forbindelse, så boolean'en afgør aldrig spørgsmålet alene.
Sammenlign den gemte værdi med den anvendte rutetabel
Efter tilslutning, list ruterne på tunneladapteren i stedet for at rulle hele tabellen igennem:
$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 1Find-NetRoute er den nyttige halvdel. Den besvarer det spørgsmål, klienten aldrig besvarer: for denne destination, hvilken interface og hvilken kildeadresse vil Windows faktisk bruge? Kør den for en intern vært, en offentlig vært og alt, du mener er en bevidst undtagelse. En fuldtunnelprofil bør vise tunnelinterfacet for den offentlige adresse. En split-tunnelprofil viser normalt den fysiske adapter der, mens interne præfikser stadig opløses til VPN'et.
To fælder forklarer de fleste rapporter om „den ruter den forkerte vej“. Det mest specifikke præfiks vinder altid, så en /24 på den fysiske adapter slår en standardrute på VPN'et, uanset hvor lav tunnelens metrik er. Metrik bryder kun uafgjort mellem ruter for samme præfiks. Og IPv4 og IPv6 afgøres hver for sig: en profil, der dækker 0.0.0.0/0, kan lade IPv6 blive på det lokale link, hvilket får et dual-stack-websted til at se halvt tunneleret ud. Kontrollér Get-NetRoute -AddressFamily IPv6, før du konkluderer, at tunnelen er i orden.
| What you see | Most likely cause | Check next |
|---|---|---|
| Public traffic leaves the physical adapter while SplitTunneling reads False | A more specific route on that adapter wins over the tunnel default | Find-NetRoute for the exact destination, then look for a /24 or host route on the physical interface |
| Internal name fails, internal IP works | No NRPT rule for that namespace, or a broader rule matches first | Get-DnsClientNrptPolicy and the namespace order |
| A dual-stack site opens directly while IPv4 uses the tunnel | The profile covers only the IPv4 default route | The IPv6 route table on both interfaces |
| Routes look right but one app still goes direct | The app uses its own proxy, or the client keeps a per-app list | The app's proxy settings and the client's application list |
Kontrollér navneopløsning separat med NRPT
Interne navne, der fejler, mens interne IP-adresser virker, peger på resolverpolitik, ikke routing. Windows afgør DNS pr. navneområde gennem tabellen for navneopløsningspolitik, som er uafhængig af rutetabellen:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexNår en regel matcher *.corp.example, går forespørgsler for det navneområde til tunnelens DNS-servere, selv om datastien til disse servere bliver på den fysiske adapter i split-tunnel-tilstand. Det er designet, og det er derfor, en browsertest, der åbner et offentligt websted, intet fortæller om interne navne. Hvis adapteren viser de forventede servere, men opslag stadig går andre steder hen, sammenlign NRPT-reglernes rækkefølge, og kontrollér, om et mere specifikt navneområde matches først.
Verificér flows, og beslut så, hvad du faktisk bad om
Gå gennem destinationer i en fast rækkefølge, så resultaterne kan sammenlignes på tværs af maskiner: en offentlig adresse, en intern adresse, et internt navn og én bevidst undtagelse som en lokal printer eller et videoopkald. Noter den interface og kildeadresse, som Find-NetRoute returnerer for hver. Efter enhver politikændring, genopret forbindelsen og gentag de samme fire kontroller; rutetabellen efter genoprettelsen er det eneste bevis på, at den nye profil trådte i kraft.
Adskil derefter routing fra håndhævelse. Tvangstunnelering foretrækker tunnelen for dækket trafik, mens den er oppe. Det er ikke en kill switch. Hvis kravet er, at intet forlader maskinen, når tunnelen falder, skal det komme fra et blokerende design: en firewallprofil knyttet til tunneltilstanden, en altid-til-profil med trafikfiltre eller leverandørklientens egen luk-på-fejl-indstilling. Tvangstunnelering skal også efterlade VPN-serverens egen adresse tilgængelig uden for tunnelen, og at blokere den i navnet „at tvinge alt“ er en pålidelig måde at låse sig ude af den forbindelse, du prøver at håndhæve.
Før du ændrer noget, gå denne liste igennem. Hvert punkt, der fejler, indsnævrer, hvor det egentlige problem ligger.
- Profilnavn og omfang bekræftet, med
-AllUserConnectionbrugt til profiler for hele maskinen. SplitTunnelinglæst og behandlet som konfiguration frem for bevis på dækning.- Tunneladapterens ruter listet separat for IPv4 og IPv6.
Find-NetRoutekørt for én offentlig, én intern og én undtagelsesdestination.- NRPT-regler kontrolleret, før ruterne fik skylden for en navnefejl.
- Blokeringskravet genlæst: foretrukken routing er ikke det samme som håndhævet blokering.
Beslutningen om fuld tunnel eller split-tunnel tilhører den, der ejer profilen, og Microsofts routingnoter beskriver den adfærd, Windows implementerer, når en profil sætter den. Microsoft: tvangs- og split-tunnelering er den reference, jeg har åben, mens jeg læser outputtet.