Slik kontrollerer du hva en VPN på Windows faktisk ruter i PowerShell
En tilkoblet VPN-flis beviser ikke dekning. Les den lagrede profilflagget, den aktive rutetabellen og NRPT-reglene i denne rekkefølgen.
Jeg koblet VPN-klienten til på en Windows 11-bærbar, flisen gikk til Connected, en intern fildeling åpnet, og et offentlig nettsted lastet fortsatt direkte fra kontorets Wi-Fi. Denne blandingen ser ut som en ødelagt tunnel. Det er den normale utgangen fra en profil som sender noe trafikk gjennom VPN-et og lar resten bli på den fysiske adapteren. Tvangstunnelering endrer hvilken standardrute Windows foretrekker; den sletter ikke mer spesifikke ruter og lover ikke at trafikken stopper når forbindelsen faller. Det følgende er rekkefølgen jeg går gjennom når en klient hevder dekning: klienttilstand, lagret profil, brukte ruter, resolver og deretter reelle strømmer.
Start ved klienten, og slutt å stole på den
Klienten er riktig sted å begynne bare fordi den forteller deg hvilken profil som er aktiv. Åpne egenskapene for tilkoblingen og noter det nøyaktige profilnavnet, om den ble opprettet for den gjeldende brukeren eller for alle på maskinen, og hvilken adapter som vises i ncpa.cpl etter tilkobling. På testmaskinen min bar adapteren profilnavnet, noe som gjorde ruteutskriften lett å lese. På andre maskiner vises den som en WAN Miniport-oppføring, og navnet sier deg ingenting.
Det klienten ikke kan fortelle deg, er dekning. En tilkoblet flis beskriver tunnelens tilstand, ikke en fortegnelse over mål. Tredjepartsklienter holder også sin egen konfigurasjon, så den innebygde Windows-profilen, og hver egenskap du kommer til å lese fra den, har kanskje ingenting å gjøre med det den klienten installerte. Hvis VPN-et kom via AnyConnect, OpenVPN GUI, WireGuard eller en leverandøragent, gjelder PowerShell-kontrollene nedenfor stort sett ikke, og du bør i stedet lese den klientens egne innstillinger for splitt-tunnel og ruting.
Les den lagrede profilen, ikke flisen
For en innebygd Windows-profil (IKEv2, L2TP, SSTP eller en som skyves ut av MDM) er den lagrede splitt-tunnel-beslutningen én enkelt egenskap:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixLegg til -AllUserConnection når profilen ble opprettet for alle på enheten. Uten det leser du listen til den gjeldende brukeren, som kan være tom eller inneholde en annen oppføring med lignende navn. Verdien False i SplitTunneling betyr at profilen ble lagret som en full tunnel: Windows installerer en standardrute gjennom VPN-adapteren. True betyr splitt-tunnel, og dekningen avhenger da helt av rutene og navneoppløsningsreglene som profilen skyver ut.
Behandle den verdien som konfigurasjon, ikke som observasjon. Den registrerer hva profilen ba om ved tilkobling. Windows kan ende opp med avvikende brukte ruter på grunn av en mer spesifikk rute på et annet grensesnitt, en policyinnstilling eller en rest fra en tidligere tilkobling, så den boolske verdien avgjør aldri spørsmålet alene.
Sammenlign den lagrede verdien med den brukte rutetabellen
Etter tilkobling, list opp rutene på tunneladapteren i stedet for å rulle gjennom hele tabellen:
$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 halvdelen. Den svarer på spørsmålet klienten aldri svarer på: for dette målet, hvilket grensesnitt og hvilken kildeadresse vil Windows faktisk bruke? Kjør den for en intern vert, en offentlig vert og alt du mener er et bevisst unntak. En fulltunnelprofil bør vise tunnelgrensesnittet for den offentlige adressen. En splitt-tunnelprofil viser vanligvis den fysiske adapteren der, mens interne prefikser fortsatt løses til VPN-et.
To feller forklarer de fleste rapportene om «den ruter feil vei». Det mest spesifikke prefikset vinner alltid, så en /24 på den fysiske adapteren slår en standardrute på VPN-et uansett hvor lav metrikken til tunnelen er. Metrikken avgjør bare uavgjort mellom ruter for samme prefiks. Og IPv4 og IPv6 avgjøres hver for seg: en profil som dekker 0.0.0.0/0 kan la IPv6 bli liggende på den lokale linken, noe som får et dual-stack-nettsted til å se halvt tunnelert ut. Sjekk Get-NetRoute -AddressFamily IPv6 før du konkluderer med 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 |
Sjekk navneoppløsning separat med NRPT
Interne navn som feiler mens interne IP-adresser virker, peker på resolverpolicy, ikke på ruting. Windows avgjør DNS per navnerom gjennom tabellen for navneoppløsningspolicy, som er uavhengig av rutetabellen:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexNår en regel samsvarer med *.corp.example, går spørringer for det navnerommet til tunnelens DNS-servere selv om databanen til disse serverne blir liggende på den fysiske adapteren i splitt-tunnelmodus. Det er designet, og derfor sier en nettlesertest som åpner et offentlig nettsted ingenting om interne navn. Hvis adapteren viser de forventede serverne, men oppslag fortsatt går andre steder, sammenlign rekkefølgen på NRPT-reglene og sjekk om et mer spesifikt navnerom samsvarer først.
Verifiser strømmene, og avgjør deretter hva du faktisk ba om
Gå gjennom målene i fast rekkefølge slik at resultatene er sammenlignbare mellom maskiner: en offentlig adresse, en intern adresse, et internt navn og ett bevisst unntak som en lokal skriver eller en videosamtale. Noter grensesnittet og kildeadressen som Find-NetRoute returnerer for hver. Etter enhver policyendring, koble til på nytt og gjenta de samme fire kontrollene; rutetabellen etter ny tilkobling er det eneste beviset på at den nye profilen trådte i kraft.
Skille deretter ruting fra håndheving. Tvangstunnelering foretrekker tunnelen for dekket trafikk mens den er oppe. Det er ikke en kill switch. Hvis kravet er at ingenting forlater maskinen når tunnelen faller, må det komme fra et blokkerende design: en brannmurprofil knyttet til tunnelens tilstand, en alltid-på-profil med trafikkfiltre eller leverandørklientens egen lukk-ved-feil-innstilling. Tvangstunnelering må også la VPN-serverens egen adresse være tilgjengelig utenfor tunnelen, og å blokkere den i navnet «tvinge alt» er en pålitelig måte å låse seg ute fra tilkoblingen du prøver å håndheve.
Før du endrer noe, gå gjennom denne listen. Hvert element som feiler, snevrer inn hvor det egentlige problemet ligger.
- Profilnavn og omfang bekreftet, med
-AllUserConnectionbrukt for profiler for hele maskinen. SplitTunnelinglest og behandlet som konfigurasjon, ikke som bevis på dekning.- Tunneladapterets ruter listet separat for IPv4 og IPv6.
Find-NetRoutekjørt for ett offentlig, ett internt og ett unntaksmål.- NRPT-regler kontrollert før rutene ble beskyldt for en navnefeil.
- Blokkeringskravet lest på nytt: foretrukket ruting er ikke det samme som håndhevet blokkering.
Beslutningen om full eller splitt tunnel tilhører den som eier profilen, og Microsofts rutenotater beskriver atferden Windows implementerer når en profil setter den. Microsoft: tvangs- og splitt-tunnelering er referansen jeg holder åpen mens jeg leser utskriften.