Korleis kontrollere kva ein VPN på Windows faktisk ruter i PowerShell
Ei tilkopla VPN-flis beviser ikkje dekning. Les den lagra profilflagga, den aktive rutetabellen og NRPT-reglane i denne rekkjefølgja.
Eg kopla VPN-klienten til på ein Windows 11-berbar, flisa gjekk til Connected, ei intern fildeling opna, og eit offentleg nettstad lasta framleis direkte frå Wi-Fi-en på kontoret. Denne blandinga ser ut som ein øydelagd tunnel. Det er den normale utgangen frå ein profil som sender noko trafikk gjennom VPN-et og lèt resten bli på den fysiske adapteren. Tvangstunnelering endrar kva standardrute Windows føretrekkjer; ho slettar ikkje meir spesifikke ruter og lovar ikkje at trafikken stoppar når sambandet fell. Det følgjande er rekkjefølgja eg går gjennom når ein klient hevdar dekning: klienttilstand, lagra profil, brukte ruter, resolver og deretter reelle straumar.
Start hos klienten, og slutt å stole på han
Klienten er rett stad å byrje berre fordi han fortel kva profil som er aktiv. Opne eigenskapane for sambandet og noter det nøyaktige profilnamnet, om det vart oppretta for den gjeldande brukaren eller for alle på maskina, og kva adapter som dukkar opp i ncpa.cpl etter tilkopling. På testmaskina mi bar adapteren profilnamnet, noko som gjorde ruteutskrifta lett å lese. På andre maskiner viser han seg som ein WAN Miniport-oppføring, og namnet seier deg ingenting.
Det klienten ikkje kan fortelje deg, er dekning. Ei tilkopla flis skildrar tilstanden til tunnelen, ikkje ei forteikning over mål. Tredjepartsklientar held òg sin eigen konfigurasjon, så den innebygde Windows-profilen, og kvar eigenskap du kjem til å lese frå han, har kanskje ingenting å gjere med det den klienten installerte. Viss VPN-et kom via AnyConnect, OpenVPN GUI, WireGuard eller ein leverandøragent, gjeld PowerShell-kontrollane nedanfor stort sett ikkje, og du bør i staden lese den klienten sine eigne innstillingar for splitt-tunnel og ruting.
Les den lagra profilen, ikkje flisa
For ein innebygd Windows-profil (IKEv2, L2TP, SSTP eller ein som MDM skyv ut) er den lagra splitt-tunnel-avgjerda éin einskild eigenskap:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixLegg til -AllUserConnection når profilen vart oppretta for alle på eininga. Utan det les du lista til den gjeldande brukaren, som kan vere tom eller innehalde ein annan oppføring med liknande namn. Verdien False i SplitTunneling tyder at profilen vart lagra som ein full tunnel: Windows installerer ei standardrute gjennom VPN-adapteren. True tyder splitt-tunnel, og dekninga avheng då heilt av rutene og namneoppløysingsreglane som profilen skyv ut.
Behandle den verdien som konfigurasjon, ikkje som observasjon. Han registrerer kva profilen bad om ved tilkopling. Windows kan enda opp med avvikande brukte ruter på grunn av ei meir spesifikk rute på eit anna grensesnitt, ei policyinnstilling eller ein rest frå ei tidlegare tilkopling, så den boolske verdien avgjer aldri spørsmålet åleine.
Samanlikn den lagra verdien med den brukte rutetabellen
Etter tilkopling, list opp rutene på tunneladapteren i staden for å rulle gjennom heile 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. Han svarar på spørsmålet klienten aldri svarar på: for dette målet, kva grensesnitt og kva kjeldeadresse vil Windows faktisk bruke? Køyr han for ein intern vert, ein offentleg vert og alt du meiner er eit medvite unntak. Ein fulltunnelprofil bør vise tunnelgrensesnittet for den offentlege adressa. Ein splitt-tunnelprofil viser vanlegvis den fysiske adapteren der, medan interne prefiks framleis blir løyste til VPN-et.
To feller forklarar dei fleste rapportane om «han ruter feil veg». Det mest spesifikke prefikset vinn alltid, så ein /24 på den fysiske adapteren slår ei standardrute på VPN-et uansett kor låg metrikken til tunnelen er. Metrikken avgjer berre uavgjort mellom ruter for same prefiks. Og IPv4 og IPv6 blir avgjorde kvar for seg: ein profil som dekkjer 0.0.0.0/0 kan la IPv6 bli liggjande på den lokale lenkja, noko som får eit dual-stack-nettstad til å sjå 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 namneoppløysing separat med NRPT
Interne namn som feilar medan interne IP-adresser virkar, peikar på resolverpolicy, ikkje på ruting. Windows avgjer DNS per namnerom gjennom tabellen for namneoppløysingspolicy, som er uavhengig av rutetabellen:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexNår ei regel samsvarar med *.corp.example, går spørjingar for det namnerommet til DNS-tenarane til tunnelen sjølv om databanen til desse tenarane blir liggjande på den fysiske adapteren i splitt-tunnelmodus. Det er designet, og derfor seier ein nettlesartest som opnar eit offentleg nettstad ingenting om interne namn. Viss adapteren viser dei forventa tenarane, men oppslag framleis går andre stader, samanlikn rekkjefølgja på NRPT-reglane og sjekk om eit meir spesifikt namnerom samsvarar først.
Stadfest straumane, og avgjer deretter kva du faktisk bad om
Gå gjennom måla i fast rekkjefølgje slik at resultata er samanliknbare mellom maskiner: ei offentleg adresse, ei intern adresse, eit internt namn og eitt medvite unntak som ein lokal skrivar eller ein videosamtale. Noter grensesnittet og kjeldeadressa som Find-NetRoute returnerer for kvar. Etter kvar policyendring, kople til på nytt og gjenta dei same fire kontrollane; rutetabellen etter ny tilkopling er det einaste beviset på at den nye profilen tredde i kraft.
Skil deretter ruting frå handheving. Tvangstunnelering føretrekkjer tunnelen for dekt trafikk medan han er oppe. Det er ikkje ein kill switch. Viss kravet er at ingenting forlèt maskina når tunnelen fell, må det kome frå eit blokkerande design: ein brannmurprofil knytt til tilstanden til tunnelen, ein alltid-på-profil med trafikkfilter eller leverandørklienten si eiga lukk-ved-feil-innstilling. Tvangstunnelering må òg la den eigne adressa til VPN-tenaren vere tilgjengeleg utanfor tunnelen, og å blokkere henne i namnet «tvinge alt» er ein påliteleg måte å låse seg ute frå tilkoplinga du prøver å handheve.
Før du endrar noko, gå gjennom denne lista. Kvart element som feilar, snevrar inn kvar det eigentlege problemet ligg.
- Profilnamn og omfang stadfesta, med
-AllUserConnectionbrukt for profilar for heile maskina. SplitTunnelinglesen og behandla som konfigurasjon, ikkje som bevis på dekning.- Rutene til tunneladapteren lista separat for IPv4 og IPv6.
Find-NetRoutekøyrd for eitt offentleg, eitt internt og eitt unntaksmål.- NRPT-reglane kontrollerte før rutene fekk skulda for ein namnefeil.
- Blokkeringskravet lese på nytt: føretrekt ruting er ikkje det same som handheva blokkering.
Avgjerda om full eller splitt tunnel høyrer til den som eig profilen, og Microsoft sine rutenotat skildrar åtferda Windows implementerer når ein profil set henne. Microsoft: tvangs- og splitt-tunnelering er referansen eg held open medan eg les utskrifta.