Så kontrollerar du vad en VPN i Windows faktiskt routar i PowerShell
En ansluten VPN-bricka bevisar inte täckning. Läs den sparade profilflaggan, den aktiva rutttabellen och NRPT-reglerna i den här ordningen.
Jag anslöt VPN-klienten på en Windows 11-bärbar dator, brickan gick till Connected, en intern fildelning öppnades och en offentlig webbplats laddades fortfarande direkt från kontorets Wi-Fi. Den blandningen ser ut som en trasig tunnel. Det är den normala utdata från en profil som skickar en del trafik via VPN och lämnar resten på den fysiska adaptern. Tvingad tunnling ändrar vilken standardrutt Windows föredrar; den raderar inte mer specifika rutter och lovar inte att trafiken stoppas när anslutningen bryts. Följande är den ordning jag går igenom när en klient hävdar täckning: klienttillstånd, sparad profil, tillämpade rutter, resolver och sedan verkliga flöden.
Börja vid klienten och sluta sedan lita på den
Klienten är rätt plats att börja på bara för att den talar om vilken profil som är aktiv. Öppna anslutningens egenskaper och notera det exakta profilnamnet, om den skapades för den aktuella användaren eller för alla på datorn, och vilken adapter som visas i ncpa.cpl efter anslutning. På min testbärbara dator bar adaptern profilnamnet, vilket gjorde ruttutskriften lätt att läsa. På andra datorer visas den som en WAN Miniport-post och namnet säger dig ingenting.
Det klienten inte kan berätta är täckningen. En ansluten bricka beskriver tunnelns tillstånd, inte en förteckning över destinationer. Tredjepartsklienter håller också sin egen konfiguration, så den inbyggda Windows-profilen, och varje egenskap du läser ur den, kanske inte har något att göra med vad den klienten installerade. Om VPN kom via AnyConnect, OpenVPN GUI, WireGuard eller en leverantörsagent gäller PowerShell-kontrollerna nedan oftast inte, och du bör i stället läsa den klientens egna inställningar för delad tunnel och routning.
Läs den sparade profilen, inte brickan
För en inbyggd Windows-profil (IKEv2, L2TP, SSTP eller en som skjuts ut av MDM) är det sparade delad-tunnel-beslutet en enda egenskap:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixLägg till -AllUserConnection när profilen skapades för alla på enheten. Utan det läser du den aktuella användarens lista, som kan vara tom eller innehålla en annan post med liknande namn. Värdet False i SplitTunneling betyder att profilen sparades som en full tunnel: Windows installerar en standardrutt genom VPN-adaptern. True betyder delad tunnel, och täckningen beror då helt på de rutter och namnupplösningsregler som profilen skjuter ut.
Behandla det värdet som konfiguration, inte som observation. Det registrerar vad profilen bad om vid anslutning. Windows kan hamna med avvikande tillämpade rutter på grund av en mer specifik rutt på ett annat gränssnitt, en principinställning eller en rest från en tidigare anslutning, så det booleska värdet avgör aldrig frågan självt.
Jämför det sparade värdet med den tillämpade rutttabellen
Efter anslutning, lista rutterna på tunneladaptern i stället för att rulla igenom hela 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 är den användbara halvan. Den svarar på frågan som klienten aldrig svarar på: för den här destinationen, vilket gränssnitt och vilken källadress kommer Windows faktiskt att använda? Kör den för en intern värd, en offentlig värd och allt du anser är ett medvetet undantag. En fulltunnelprofil bör visa tunnelgränssnittet för den offentliga adressen. En delad-tunnelprofil visar vanligtvis den fysiska adaptern där, medan interna prefix fortfarande löses till VPN.
Två fällor förklarar de flesta rapporterna om att «den routar fel». Det mest specifika prefixet vinner alltid, så en /24 på den fysiska adaptern slår en standardrutt på VPN hur låg tunnelns metrik än är. Metriken avgör bara oavgjort mellan rutter för samma prefix. Och IPv4 och IPv6 avgörs var för sig: en profil som täcker 0.0.0.0/0 kan lämna IPv6 på den lokala länken, vilket får en dual-stack-webbplats att se halvt tunnlad ut. Kontrollera Get-NetRoute -AddressFamily IPv6 innan du drar slutsatsen att tunneln är okej.
| 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 |
Kontrollera namnupplösning separat med NRPT
Interna namn som misslyckas medan interna IP-adresser fungerar pekar på resolverprincip, inte på routning. Windows avgör DNS per namnområde genom tabellen för namnupplösningsprincip, som är oberoende av rutttabellen:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexNär en regel matchar *.corp.example går frågor för det namnområdet till tunnelns DNS-servrar även om datavägen till dessa servrar stannar på den fysiska adaptern i delad-tunnelläge. Det är designen, och därför säger ett webbläsartest som öppnar en offentlig webbplats ingenting om interna namn. Om adaptern listar de förväntade servrarna men sökningar ändå går någon annanstans, jämför ordningen på NRPT-reglerna och kontrollera om ett mer specifikt namnområde matchar först.
Verifiera flödena och avgör sedan vad du faktiskt bad om
Gå igenom destinationerna i fast ordning så att resultaten är jämförbara mellan datorer: en offentlig adress, en intern adress, ett internt namn och ett medvetet undantag som en lokal skrivare eller ett videosamtal. Notera gränssnittet och källadressen som Find-NetRoute returnerar för varje. Efter varje principändring, återanslut och upprepa samma fyra kontroller; rutttabellen efter återanslutningen är det enda beviset på att den nya profilen trädde i kraft.
Separera sedan routning från verkställighet. Tvingad tunnling föredrar tunneln för täckt trafik medan den är uppe. Det är ingen kill switch. Om kravet är att ingenting lämnar datorn när tunneln faller måste det komma från en blockerande design: en brandväggsprofil knuten till tunnelns tillstånd, en alltid-på-profil med trafikfilter eller leverantörsklientens egen stäng-vid-fel-inställning. Tvingad tunnling måste också lämna VPN-serverns egen adress nåbar utanför tunneln, och att blockera den i namn av «tvinga allt» är ett pålitligt sätt att låsa sig ute från anslutningen du försöker genomdriva.
Innan du ändrar något, gå igenom den här listan. Varje punkt som misslyckas ringar in var det verkliga problemet finns.
- Profilnamn och omfång bekräftade, med
-AllUserConnectionför profiler för hela datorn. SplitTunnelingläst och behandlat som konfiguration, inte som bevis på täckning.- Tunneladapterns rutter listade separat för IPv4 och IPv6.
Find-NetRoutekört för en offentlig, en intern och en undantagsdestination.- NRPT-regler kontrollerade innan rutterna fick skulden för ett namnfel.
- Blockeringskravet läst igen: föredragen routning är inte samma sak som genomdriven blockering.
Beslutet om full eller delad tunnel tillhör den som äger profilen, och Microsofts routningsanteckningar beskriver det beteende som Windows implementerar när en profil ställer in det. Microsoft: tvingad och delad tunnling är referensen jag håller öppen medan jag läser utdata.