Varför din Windows-VPN dödar den lokala skrivaren och hur du stoppar det

Anslut VPN:en och skrivaren försvinner, NAS-delningen slutar öppnas, och en Fjärrskrivbord-session till maskinen bredvid dig tar slut på tid. Inget gick sönder. Klienten lade till en standardrutt och äger nu varje destination som laptopen kan namnge, även de tre meter bort. Det är hela mekanismen, och att kalla det ett VPN-fel är det som gör en ettradig rättelse till ett supportärende.

Läs rutttabellen först

Innan du ändrar något, fånga IPv4-tabellen med route print -4 och spara utdata. Anslut, fånga igen och jämför raderna 0.0.0.0: den aktiva standardrutten namnger ett gränssnitt, och om det gränssnittet är tunneln skickas lokal utskrift och surfning till kontoret först.

Gränssnittsnumret i den andra kolumnen är det som en permanent rutt måste referera till senare, så anteckna det medan tunneln är uppe. Det är också värdet som ändras när adaptern återskapas, och därför kan rutter som fästs vid det tyst överleva sin nytta.

Ta bort standardrutten, på tre sätt

På en inbyggd Windows-profil är kontrollen en kryssruta. Öppna anslutningens egenskaper, IPv4, sedan Avancerat, och rensa Use default gateway on remote network; den nyare appen Inställningar gömmer samma dialog en nivå djupare. Från en förhöjd kommandotolk är samma ändring en enda cmdlet:

Set-VpnConnection -Name "Corp" -SplitTunneling $true

En OpenVPN-profil fungerar annorlunda, och därför förvirrar dess beteende folk som förväntar sig en kryssruta. Dess redirect-gateway def1-direktiv ersätter inte standardrutten alls; det installerar två halvintervallsrutter, 0.0.0.0/1 och 128.0.0.0/1, som tillsammans vinner över standardrutten utan att radera den. Eftersom den ursprungliga standarden överlever skickar ett prefix riktat mot net_gateway bara tillbaka det prefixet till den lokala routern. Den detaljen förklarar varför rättelsen för en def1-profil är en prefixrutt och inte en kryssruta som ingen hittar.

Lägg bara tillbaka det som hör till arbetet

Utan standardrutten bär tunneln ingenting, så arbetspräfixen måste namnges uttryckligen. Cmdleten som binder ett prefix till anslutningen är säkrare än en permanent rutt, eftersom den bara installeras medan den anslutningen är uppe och inte beror på ett gränssnittsnummer:

Add-VpnConnectionRoute -ConnectionName "Corp" -DestinationPrefix 172.20.0.0/16

Det äldre tillvägagångssättet fungerar fortfarande och står fortfarande i varje checklista: route -p add 172.20.0.0 mask 255.255.0.0 172.20.0.1 if 14, med tunnelns eget gränssnittsindex och gateway-adress. Den överlever omstarter, vilket är poängen och också faran, eftersom indexet vid nästa start kan tillhöra något annat.

Resten avgörs av mätvärdena. Om både den fysiska och tunneladaptern gör anspråk på en rutt för samma prefix vinner det lägre mätvärdet, och att höja tunnelns mätvärde är en legitim klientstyrd kontroll och inte ett hack.

När servern bestämmer åt dig

En klient som ignorerar din kryssruta lyder oftast en policy. Cisco-profiler bär en inställning Allow Local LAN Access, och en headend kan skjuta ut en tunnel-all-policy som åsidosätter vad klienten än föredrar; i en obligatorisk tunnel finns ingen lokal brytare att vända. Läs klientloggen efter utskjutna rutter och policylinjer i stället för att kontrollera samma dialog igen.

Titta sedan på namnmatchning, som är en separat brytare från routning. En delad tunnel kan fortfarande få en intern resolver och ett sökprefix, så en lokal enhet är nåbar på adress och oåtkomlig på namn tills DNS-sidan också är lagad.

Överlapp är ett annat problem

Om hemma-LAN:et och kontors-LAN:et delar ett prefix som 192.168.0.0/24, kan ingen rutt skilja dem åt. Varje paket för det intervallet har ett enda uppslagssvar, och rättelsen är att numrera om en sida eller nå kontoret via en översatt adress från poolen. Att lägga till mer specifika rutter flyttar bara vilken halva av nätverket som går sönder.

Avsluta med en verifiering i stället för fem: anslut och kör sedan tracert mot en intern och en offentlig värd. Det första hoppet bör skilja sig, och om det inte gör det är delningen inte på plats oavsett vad klienten rapporterar. Anslut sedan igen en gång och upprepa, för utskjutna rutter kommer tillbaka med varje session.