Lokala nätverket oåtkomligt medan VPN är anslutet? Fyra kontroller

Tunneln kommer upp, intranätet syns och skrivaren slutar svara. Inget på LAN:et har gått sönder; klienten har ändrat vilken väg den använder för adresser som den inte längre behandlar som lokala. Gå igenom de fyra kontrollerna nedan i ordning och stanna när en av dem visar en konkret avvikelse, eftersom samma symptom har fyra vanliga orsaker och bara en av dem åtgärdas genom att ändra VPN:en.

Först, titta på routingtabellen som klienten installerade

Öppna klientens routingtabell medan VPN:en är ansluten. På Linux använder du ip route, på Windows route print eller Get-NetRoute, och på macOS netstat -rn. Du letar efter en standardväg genom tunneln och efter vad som hände med den fysiska standardvägen.

En fulltunnelklient lägger ofta till två halvstandardvägar, 0.0.0.0/1 och 128.0.0.0/1, i stället för att ersätta 0.0.0.0/0. Den ursprungliga standardvägen syns fortfarande men förlorar varje uppslagning, vilket är varför tabellen kan se intakt ut medan all trafik utanför subnätet flyttar. Om VPN-klienten erbjuder ett alternativ för delad tunnel och policyn tillåter det, är det den renaste reparationen.

Om tunneln måste förbli standardväg, fäst i stället det lokala subnätet. På Linux namnger vägen det fysiska gränssnittet och gatewayen; på Windows lägger du till -p för att göra den beständig och läser gränssnittsnumret från route print i stället för att gissa det:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

En fäst väg håller bara så länge adressen den namnger är densamma. En bärbar dator som får ett nytt nummer på Wi-Fi-adaptern vid varje anslutning bryter regeln igen, så kontrollera gränssnittsadressen innan du drar slutsatsen att reparationen misslyckades.

För det andra, bekräfta att adressen var lokal från början

Om målet ligger inom det anslutna subnätet gäller aldrig tunnelns standardväg och VPN:en är inte orsaken. En skrivare på 192.168.1.40 på en klient med 192.168.1.0/24 använder den anslutna vägen; om den adressen misslyckas, titta på enheten, switchen eller brandväggen på klienten i stället för på VPN:en.

Fallet som lurar folk är en publik adress för en lokal server. Inifrån LAN:et kräver det att nå routerns WAN-adress och komma tillbaka hairpin-NAT, och många routrar implementerar helt enkelt inte det för portvidarebefordran. Testa den privata adressen bredvid den publika. Om den privata fungerar och den publika inte, har VPN:en bara blottat en NAT-begränsning som redan fanns.

Ett värdnamn gör det värre. Om det lokala namnet nu löses till den publika adressen kommer klienten att fortsätta försöka med vägen som inte kan komma tillbaka. Använd den privata adressen för testet och rätta sedan namnet i stället för att lägga till ytterligare en portvidarebefordran.

För det tredje, se vem som svarar på namn nu

En företagsresolver känner till intranätet och vet vanligtvis ingenting om ett NAS-värdnamn, skrivarens Bonjour-namn eller routerns lokala alias. När VPN:en trycker in sina DNS-servrar slutar dessa namn att lösas även om deras adresser fortfarande är nåbara. Fråga namn direkt och jämför svaret med den adress du vet att enheten har.

På Linux visar resolvectl query nas.local vilken resolver som svarade. På Windows namnger nslookup nas.local servern och ipconfig /all visar resolvrarnas ordning. Om det lokala suffixet nu hanteras av företagsresolvern, antingen dirigera suffixet tillbaka till den lokala resolvern eller använd IP-adressen för enheten.

Upptäckt är ett eget lager. mDNS och broadcast korsar inte en routad tunnel, så en enhet kan vara nåbar via adress medan namnet förblir osynligt. En reflektor eller en lokal DNS-post löser det; en väg gör det inte.

För det fjärde, kontrollera om den andra maskinen också är på en VPN

När maskinen du vill nå också kör en VPN-klient kan din session komma fram medan svaret går ut genom den andra tunneln. Det ger en anslutning som etableras och sedan hakar upp sig, eller ett RDP- och SSH-försök som tar timeout utan fel på din sida. Kontrollera den andra värden routingtabell och dess standardväg innan du skyller på din klient.

Kontrollera också adressen som tjänsten lyssnar på. En lyssnare som bara är bunden till tunneladressen accepterar anslutningar från VPN:en och nekar dem från LAN:et, även när routningen är perfekt. Det är en tjänstekonfiguration, inte en nätverksväg, och det är vanligt på administrationsgränssnitt som låstes till VPN-adressen.

Behåll en administrationsväg som inte beror på tunneln: en statisk väg som namnger ditt källnät, ett annat gränssnitt anslutet till LAN:et, eller en konsol som helt kringgår tunneln. Att designa den vägen efter att sessionen faller är mycket svårare än att lägga till den före nästa anslutning.

Tillämpa den reparation som matchar kontrollen som misslyckades

Om routingtabellen visade en halvstandard-övertagning, välj delad tunnel när policyn tillåter och en fäst lokal väg när den inte gör det. Om adressen visade sig vara publik, byt testet och namnet till den privata adressen. Om resolvern bytte händer, begränsa till det lokala suffixet eller använd adressen. Om den andra värden är i tunnel, rätta dess returväg eller lyssnarens bindning.

Ändra en sak och upprepa sedan samma kontroll. En väg som lagts till för fel subnät, ett resolversuffix med stavfel och en fäst väg på ett gränssnitt som får nya nummer ser alla ut som det ursprungliga felet. Upprepningen är det som skiljer en reparation från ett sammanträffande.

Skriv ner vägen, adressen och resolvern som fungerade medan VPN:en var ansluten. Nästa återanslutning ändrar minst en av dem, och anteckningen gör nästa avbrott till en kort jämförelse i stället för en ny undersökning.