Windows-VPN tar all trafikken din? Fjern standardruten

Du kobler til kontorets VPN, og hver side i nettleseren begynner å gå gjennom det nettverket: filserveren er rask, alt annet er tregt, filtrert eller borte. Klienten oppfører seg ikke feil; profilen ba om en full tunnel. Bryteren som stopper det, er én avkrysningsboks i en dialog som det moderne Innstillinger-programmet ikke viser, og gatewayen får igjen et ord å si ved hver tilkobling. Denne gjennomgangen følger rekkefølgen Windows-grensesnittet faktisk presenterer, og dekker deretter kontrollene som fortsatt feiler når rutetabellen ser riktig ut.

Start i adatteregenskapene, ikke i Innstillinger

Innstillinger-programmet lister profilen under Nettverk og Internett, deretter VPN, men viser bare generelle alternativer. Beslutningen om standardgatewayen bor på adapteren. Åpne den klassiske adapterlisten med Win+R og ncpa.cpl, høyreklikk VPN-tilkoblingen, velg Egenskaper, velg Internett-protokoll versjon 4, velg Egenskaper igjen og deretter Avansert. Fjern merket for Bruk standardgateway på fjernnettverket og bekreft veien ut av alle tre dialogene.

Koble til på nytt før du tester, fordi avkrysningsboksen brukes når tunnelen opprettes, og en eksisterende økt beholder tabellen den bygde. Hvis adapteren mangler mens klienten er frakoblet, koble til én gang og åpne vinduet på nytt. En leverandørklient som installerer en TAP- eller Wintun-adapter uten en IPv4-egenskapsside, har ikke denne dialogen i det hele tatt; for dem er samme beslutning et splitt-tunnel-alternativ i klientens egne innstillinger, og avkrysningsboksen på adapteren er feil sted å lete.

Samme endring fra PowerShell

For en profil som er opprettet i Windows VPN-lageret, kan innstillingen skriptes, som er det du vil ha hvis maskinen ofte bygges på nytt:

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

Den cmdleten når bare profiler i det lageret. En tilkobling som er lagt til av en tredjepartsklient, vises ikke, og kommandoen feiler med en navnefeil som leser som en skrivefeil. Legg også merke til hva bryteren ikke gjør: den hindrer klienten i å installere en standardrute, men den fjerner ikke ruter som gatewayen skyver ut ved tilkobling, så neste avsnitt er fortsatt nødvendig på mange nettverk.

Når gatewayen skyver standardruten tilbake

Les tabellen først. To standardoppføringer med ulike metrikker betyr at profilendringen virket, og at ruten som ble skjøvet ut, likevel erstattet den:

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

Slett standardruten som tilhører tunnelen, og behold den fysiske. Bruk grensesnittindeksen fra den tredje kommandoen, ikke adapteraliaset, fordi skript som sender et alias, knekker så snart visningsnavnet endres:

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

Slettingen tar kontoret med seg, så legg tilbake bedriftsprefiksene gjennom tunnelens gateway. Dette er linjen folk hopper over, og det er grunnen til at «VPN-en sluttet å virke» følger en vellykket splitt-tunnel-endring:

route add 10.0.0.0 mask 255.0.0.0 10.8.0.1 metric 5 if 21

Ingenting av dette overlever en ny tilkobling, noe som er ærlig oppførsel og ikke en feil: adapteren bygges på nytt, og klienten bruker igjen det profilen og gatewayen ble enige om. Hvis standardruten kommer tilbake hver gang, er gatewayen konfigurert til å avvise splitt-tunnel og vil fortsette å skyve den ut, eller koble ned økten. Det er nettverksoperatørens policy, og forespørselen hører hjemme der og ikke i et lokalt skript som kjemper mot det én gang per tilkobling.

Kontroller DNS, IPv6 og metrikkene på nytt etter én ny tilkobling

Å fjerne en IPv4-standardrute beviser ingenting om den andre familien eller om navneoppslag. En tunnel kan bære IPv6 mens IPv4-standarden blir liggende lokalt, og en utskutt resolverliste kan holde interne navn i gang mens spørringene som bruker den, går en annen vei. Kontroller alle tre før du kaller det ferdig:

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

Hvis tilstanden går tilbake ved hver tilkobling, flytt kommandoene til en handling per tilkobling i stedet for å redigere tabellen manuelt: en planlagt oppgave som utløses av tilkoblingshendelsen, eller klientens egen splitt-tunnel-innstilling der den finnes. Hold grensesnittindeksen i en variabel og slå den opp ved kjøring, siden den kan endres når adaptere legges til eller fjernes.

Bestem hva du ga opp

Lokal internettrafikk blir ikke lenger inspisert eller filtrert av kontoret, og alt som bare publiseres gjennom tunnelen, trenger nå sin egen rute. Noen organisasjoner ser på splitt-tunnel som et policybrudd, så bekreft det før du endrer en administrert enhet; en utskutt standardrute er noen ganger håndhevingsmekanismen og ikke et uhell. Dokumentasjonen for Set-VpnConnection lister splitt-tunnel-parameteren og profiltypene den gjelder for.

Verifiser deretter i fast rekkefølge: hvem som eier standardruten, vanlig nettsurfing, én bedriftsvert etter adresse, ett internt navn, og de samme fire etter én enkelt ny tilkobling. Hvis surfing virker og bedriftsverten feiler, mangler prefiksruten og ikke standardruten du fjernet, og det er mye billigere å rette enn å bygge profilen på nytt.