Hvorfor Windows-VPN-en din dreper den lokale skriveren, og hvordan du stopper det
En fulltunnelklient eier standardruten, så skriveren og NAS-en slutter å svare. Fjern den ruten, og legg deretter tilbake arbeidsprefiksene du trenger.
Koble til VPN-en, og skriveren forsvinner, NAS-delingen slutter å åpne seg, og en Eksternt skrivebord-økt til maskinen ved siden av deg går ut på tid. Ingenting gikk i stykker. Klienten la til en standardrute og eier nå hver destinasjon laptopen kan navngi, også de tre meter unna. Det er hele mekanismen, og å kalle det en VPN-feil er det som gjør en ettlinjesretting til en støttesak.
Les rutetabellen først
Før du endrer noe, ta IPv4-tabellen med route print -4 og ta vare på utdataene. Koble til, ta på nytt, og sammenlign linjene 0.0.0.0: den aktive standardruten navngir et grensesnitt, og hvis det grensesnittet er tunnelen, sendes lokal utskrift og surfing til kontoret først.
Grensesnittnummeret i den andre kolonnen er det en permanent rute må referere til senere, så noter det mens tunnelen er oppe. Det er også verdien som endres når adapteren gjenskapes, og derfor kan ruter festet til den stille overleve nytten sin.
Fjern standardruten, på tre måter
På en innebygd Windows-profil er kontrollen en avmerkingsboks. Åpne egenskapene for tilkoblingen, IPv4, deretter Avansert, og fjern Use default gateway on remote network; den nyere Innstillinger-appen skjuler den samme dialogen ett lag dypere. Fra en forhøyet ledetekst er den samme endringen én cmdlet:
Set-VpnConnection -Name "Corp" -SplitTunneling $true
En OpenVPN-profil fungerer annerledes, og derfor forvirrer oppførselen folk som forventer en avmerkingsboks. Dens redirect-gateway def1-direktiv erstatter ikke standardruten i det hele tatt; det installerer to halvområderuter, 0.0.0.0/1 og 128.0.0.0/1, som sammen vinner over standardruten uten å slette den. Fordi den opprinnelige standarden overlever, sender et prefiks rettet mot net_gateway bare det prefikset tilbake til den lokale ruteren. Den detaljen forklarer hvorfor rettingen for en def1-profil er en prefiksrute og ikke en avmerkingsboks ingen finner.
Legg bare tilbake det som hører til arbeidet
Når standardruten er borte, bærer tunnelen ingenting, så arbeidsprefiksene må navngis eksplisitt. Cmdleten som binder et prefiks til tilkoblingen, er tryggere enn en permanent rute, fordi den bare installeres mens den tilkoblingen er oppe og ikke avhenger av et grensesnittnummer:
Add-VpnConnectionRoute -ConnectionName "Corp" -DestinationPrefix 172.20.0.0/16
Den eldre fremgangsmåten fungerer fortsatt og står fortsatt på hver sjekkliste: route -p add 172.20.0.0 mask 255.255.0.0 172.20.0.1 if 14, med tunnelens egen grensesnittindeks og gateway-adresse. Den overlever omstarter, som er poenget og også faren, siden indeksen ved neste oppstart kan tilhøre noe annet.
Metrikkene avgjør resten. Hvis både den fysiske og tunnel-adapteren krever en rute for samme prefiks, vinner den laveste metrikken, og å heve tunnelens metrikk er en legitim klientstyring og ikke et hack.
Når serveren bestemmer for deg
En klient som ignorerer avmerkingsboksen din, følger vanligvis en policy. Cisco-profiler har en Allow Local LAN Access-innstilling, og en headend kan dytte en tunnel-all-policy som overstyrer det klienten måtte foretrekke; i en obligatorisk tunnel er det ingen lokal bryter å snu. Les klientloggen for dyttede ruter og policylinjer i stedet for å sjekke den samme dialogen på nytt.
Se deretter på navneoppløsning, som er en egen bryter fra ruting. En splittet tunnel kan fortsatt motta en intern resolver og et søkeprefiks, så en lokal enhet er nåbar på adresse og ufinnbar på navn til DNS-siden også er rettet.
Overlapp er et annet problem
Hvis hjemme-LAN-et og kontor-LAN-et deler et prefiks som 192.168.0.0/24, kan ingen rute skille dem. Hver pakke for det området har ett oppslagssvar, og rettingen er å nummerere om én side eller nå kontoret gjennom en oversatt adresse fra poolen. Å legge til mer spesifikke ruter flytter bare hvilken halvdel av nettverket som knuses.
Avslutt med én verifisering i stedet for fem: koble til, og kjør deretter tracert mot en intern og en offentlig vert. Det første hoppet bør være forskjellig, og hvis det ikke er det, er splitten ikke på plass uansett hva klienten rapporterer. Koble deretter til på nytt én gang og gjenta, fordi dyttede ruter kommer tilbake med hver økt.