Windows-VPN tager al din trafik? Fjern dens standardrute

Du opretter forbindelse til kontorets VPN, og hver side i browseren begynder at gå gennem det netværk: filserveren er hurtig, alt andet er langsomt, filtreret eller væk. Klienten opfører sig ikke forkert; profilen bad om en fuld tunnel. Den kontakt, der stopper det, er én afkrydsningsboks i en dialog, som det moderne Indstillinger-program ikke viser, og gatewayen har igen et ord at sige ved hver forbindelse. Denne gennemgang følger den rækkefølge, som Windows-grænsefladen faktisk præsenterer, og dækker derefter de kontroller, der stadig fejler, når rutetabellen ser korrekt ud.

Start i adapteregenskaberne, ikke i Indstillinger

Programmet Indstillinger viser profilen under Netværk og internet og derefter VPN, men det blotlægger kun generelle indstillinger. Beslutningen om standardgatewayen bor på adapteren. Åbn den klassiske adapterliste med Win+R og ncpa.cpl, højreklik på VPN-forbindelsen, vælg Egenskaber, vælg Internetprotokol version 4, vælg Egenskaber igen og derefter Avanceret. Fjern markeringen i Brug standardgateway på fjernnetværket, og bekræft dig ud af alle tre dialoger.

Opret forbindelse igen før test, fordi afkrydsningsboksen anvendes, når tunnelen etableres, og en eksisterende session beholder den tabel, den byggede. Hvis adapteren mangler, mens klienten er afbrudt, skal du oprette forbindelse én gang og åbne vinduet igen. En leverandørklient, der installerer en TAP- eller Wintun-adapter uden en IPv4-egenskabsside, har slet ikke denne dialog; for dem er den samme beslutning en split-tunnel-indstilling i klientens egne indstillinger, og adapterens afkrydsningsboks er det forkerte sted at lede.

Den samme ændring fra PowerShell

For en profil, der er oprettet i Windows VPN-lageret, kan indstillingen scriptes, hvilket er det, du vil have, hvis maskinen ofte genopbygges:

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

Det cmdlet rækker kun til profiler i det lager. En forbindelse, der er tilføjet af en tredjepartsklient, vises ikke, og kommandoen fejler med en navnefejl, der ligner en tastefejl. Læg også mærke til, hvad kontakten ikke gør: den forhindrer klienten i at installere en standardrute, men den fjerner ikke ruter, som gatewayen skubber ved forbindelsestidspunktet, så næste afsnit er stadig nødvendigt på mange netværk.

Når gatewayen skubber standardruten tilbage

Læs tabellen først. To standardposter med forskellige metrikker betyder, at profilændringen virkede, og at den skubbede rute alligevel erstattede den:

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

Slet den standardrute, der hører til tunnelen, og behold den fysiske. Brug interfaceindekset fra den tredje kommando, ikke adapteraliaset, fordi scripts, der sender et alias, brækker sammen, så snart visningsnavnet ændres:

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

Sletningen tager kontoret med sig, så føj de virksomhedsspecifikke præfikser tilbage gennem tunnelens gateway. Det er den linje, folk springer over, og det er grunden til, at «VPN'et holdt op med at virke» følger en vellykket split-tunnel-ændring:

route add 10.0.0.0 mask 255.0.0.0 10.8.0.1 metric 5 if 21

Intet af dette overlever en ny forbindelse, hvilket er ærlig adfærd og ikke en fejl: adapteren genopbygges, og klienten anvender igen det, som profilen og gatewayen blev enige om. Hvis standardruten kommer tilbage hver gang, er gatewayen konfigureret til at afvise split tunnelling og vil blive ved med at skubbe den eller droppe sessionen. Det er netværksoperatørens politik, og anmodningen hører der i stedet for i et lokalt script, der kæmper mod det én gang for hver forbindelse.

Kontrollér DNS, IPv6 og metrikkerne igen efter én ny forbindelse

At fjerne en IPv4-standardrute beviser intet om den anden familie eller om navneopløsning. En tunnel kan bære IPv6, mens IPv4-standarden bliver lokal, og en skubbet resolverliste kan holde interne navne kørende, mens de forespørgsler, der bruger den, kører ad en anden vej. Kontrollér alle tre, før du kalder det færdigt:

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

Hvis tilstanden vender tilbage ved hver forbindelse, skal du flytte kommandoerne til en handling for hver forbindelse i stedet for at redigere tabellen manuelt: en planlagt opgave, der udløses af forbindelseshændelsen, eller klientens egen split-tunnel-indstilling, hvor den har en. Hold interfaceindekset i en variabel, og slå det op på kørselstidspunktet, da det kan ændre sig, når adaptere tilføjes eller fjernes.

Afgør, hvad du gav afkald på

Lokal internettrafik bliver ikke længere inspiceret eller filtreret af kontoret, og alt, der kun udgives gennem tunnelen, har nu brug for sin egen rute. Nogle organisationer betragter split tunnelling som en politikoverskridelse, så bekræft det, før du ændrer en administreret enhed; en skubbet standard er nogle gange håndhævelsesmekanismen snarere end et uheld. Dokumentationen for Set-VpnConnection viser parameteren for split tunnelling og de profiltyper, den gælder for.

Verificér derefter i en fast rækkefølge: hvem ejer standardruten, almindelig surfing, én virksomhedsvært efter adresse, ét internt navn, og de samme fire efter én enkelt ny forbindelse. Hvis surfing virker, og virksomhedsværten fejler, mangler præfiksruten snarere end den standard, du fjernede, og det er meget billigere at rette end at genopbygge profilen.