Windows-VPN tar all din trafik? Ta bort dess standardväg

Avmarkera Använd standardgateway i fjärrnätverket, ta bort den påtvingade standardvägen, lägg tillbaka kontorets prefix och kontrollera sedan DNS och IPv6 igen.

Du ansluter till kontorets VPN och varje sida i webbläsaren börjar gå genom det nätverket: filservern är snabb, allt annat är långsamt, filtrerat eller borta. Klienten beter sig inte fel; profilen bad om en full tunnel. Strömbrytaren som stoppar det är en kryssruta i en dialog som det moderna Inställningar-programmet inte visar, och gatewayen får igen ett ord med i laget vid varje anslutning. Den här genomgången följer den ordning Windows-gränssnittet faktiskt presenterar och täcker sedan de kontroller som fortfarande misslyckas när routingtabellen ser korrekt ut.

Börja i adapteregenskaperna, inte i Inställningar

Inställningar-programmet listar profilen under Nätverk och Internet och sedan VPN, men visar bara allmänna alternativ. Beslutet om standardgatewayen bor på adaptern. Öppna den klassiska adapterlistan med Win+R och ncpa.cpl, högerklicka på VPN-anslutningen, välj Egenskaper, välj Internetprotokoll version 4, välj Egenskaper igen och sedan Avancerat. Avmarkera Använd standardgateway i fjärrnätverket och bekräfta vägen ut ur alla tre dialogerna.

Anslut igen innan du testar, eftersom kryssrutan tillämpas när tunneln upprättas och en befintlig session behåller tabellen den byggde. Om adaptern saknas medan klienten är frånkopplad, anslut en gång och öppna fönstret igen. En leverantörsklient som installerar en TAP- eller Wintun-adapter utan IPv4-egenskapssida har inte den här dialogrutan alls; för dem är samma beslut ett alternativ för delad tunnel i klientens egna inställningar, och kryssrutan på adaptern är fel ställe att leta på.

Samma ändring från PowerShell

För en profil som skapats i Windows VPN-arkivet går inställningen att skripta, vilket är vad du vill om maskinen ofta byggs om:

Set-VpnConnection -Name "Office" -SplitTunneling $true
Get-VpnConnection -Name "Office" | Select-Object Name,SplitTunneling

Den cmdleten når bara profiler i det arkivet. En anslutning som lagts till av en tredjepartsklient visas inte, och kommandot misslyckas med ett namnfell som läses som ett skrivfel. Notera också vad brytaren inte gör: den hindrar klienten från att installera en standardväg, men den tar inte bort vägar som gatewayen skjuter in vid anslutning, så nästa avsnitt behövs fortfarande i många nätverk.

När gatewayen skjuter tillbaka standardvägen

Läs tabellen först. Två standardposter med olika metriker betyder att profiländringen fungerade och att den påskjutna vägen ändå ersatte den:

route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-NetAdapter | Select-Object Name,ifIndex

Ta bort standardvägen som hör till tunneln och behåll den fysiska. Använd gränssnittsindexet från det tredje kommandot, inte adapteraliaset, eftersom skript som skickar ett alias går sönder så snart visningsnamnet ändras:

Remove-NetRoute -DestinationPrefix 0.0.0.0/0 -InterfaceIndex 21 -Confirm:$false
route delete 0.0.0.0 10.8.0.1

Borttagningen tar kontoret med sig, så lägg tillbaka företagets prefix genom tunnelns gateway. Detta är raden folk hoppar över, och det är därför «VPN:et slutade fungera» följer på en lyckad ändring av delad tunnel:

route add 10.0.0.0 mask 255.0.0.0 10.8.0.1 metric 5 if 21

Inget av detta överlever en ny anslutning, vilket är ärligt beteende och inte en bugg: adaptern byggs upp igen och klienten tillämpar på nytt det som profilen och gatewayen kom överens om. Om standardvägen kommer tillbaka varje gång är gatewayen konfigurerad att vägra delad tunnel och kommer att fortsätta skjuta in den, eller koppla ner sessionen. Det är nätverksoperatörens policy, och begäran hör hemma där och inte i ett lokalt skript som kämpar emot det en gång per anslutning.

Kontrollera DNS, IPv6 och metrikerna igen efter en ny anslutning

Att ta bort en IPv4-standardväg bevisar ingenting om den andra familjen eller om namnmatchning. En tunnel kan bära IPv6 medan IPv4-standarden stannar lokalt, och en påskjuten resolverlista kan hålla interna namn igång medan frågorna som använder den tar en annan väg. Kontrollera alla tre innan du kallar det klart:

Get-NetRoute -DestinationPrefix ::/0
Get-DnsClientServerAddress -InterfaceAlias "Office"
Get-DnsClientNrptPolicy

Om tillståndet återgår vid varje anslutning, flytta kommandona till en åtgärd per anslutning i stället för att redigera tabellen för hand: en schemalagd uppgift som utlöses av anslutningshändelsen, eller klientens egen inställning för delad tunnel där den finns. Håll gränssnittsindexet i en variabel och slå upp det vid körning, eftersom det kan ändras när adaptrar läggs till eller tas bort.

Bestäm vad du gav upp

Lokal internettrafik inspekteras eller filtreras inte längre av kontoret, och allt som bara publiceras genom tunneln behöver nu sin egen väg. Vissa organisationer ser delad tunnel som ett policybrott, så bekräfta det innan du ändrar en hanterad enhet; en påskjuten standardväg är ibland tvingandet och inte en olycka. Dokumentationen för Set-VpnConnection listar parametern för delad tunnel och de profiltyper den gäller.

Verifiera sedan i fast ordning: vem som äger standardvägen, vanlig surfning, en företagsvärd via adress, ett internt namn, och samma fyra efter en enda ny anslutning. Om surfning fungerar och företagsvärden misslyckas saknas prefixvägen och inte standardvägen du tog bort, och det är mycket billigare att åtgärda än att bygga om profilen.

Relaterade artiklar