Lokalt nettverk utilgjengelig mens VPN er tilkoblet? Fire kontroller

Tunnelen kommer opp, intranettet vises, og skriveren slutter å svare. Ingenting på LAN-et har feilet; klienten har endret hvilken vei den bruker for adresser den ikke lenger behandler som lokale. Gå gjennom de fire kontrollene nedenfor i rekkefølge og stopp når en av dem viser et konkret avvik, fordi det samme symptomet har fire vanlige årsaker, og bare én av dem rettes ved å endre VPN-en.

Først, se på rutetabellen klienten installerte

Åpne klientens rutetabell mens VPN-en er tilkoblet. På Linux bruker du ip route, på Windows route print eller Get-NetRoute, og på macOS netstat -rn. Du leter etter en standardrute gjennom tunnelen og etter hva som skjedde med den fysiske standardruten.

En fulltunellklient legger ofte til to halvstandardruter, 0.0.0.0/1 og 128.0.0.0/1, i stedet for å erstatte 0.0.0.0/0. Den opprinnelige standardruten blir synlig, men taper hvert oppslag, og derfor kan tabellen se intakt ut mens all trafikk utenfor subnettet flyttes. Hvis VPN-klienten tilbyr et alternativ for delt tunnel og policyen tillater det, er det den reneste reparasjonen.

Hvis tunnelen må forbli standard, fester du det lokale subnettet i stedet. På Linux navngir ruten det fysiske grensesnittet og gatewayen; på Windows legger du til -p for å gjøre den varig og leser grensesnittnummeret fra route print i stedet for å gjette 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 festet rute holder bare så lenge adressen den navngir er den samme. En bærbar PC som får nytt nummer på Wi-Fi-adapteren ved hver tilkobling, bryter regelen igjen, så sjekk grensesnittadressen før du konkluderer med at reparasjonen mislyktes.

For det andre, bekreft at adressen var lokal i utgangspunktet

Hvis målet ligger inne i det tilkoblede subnettet, gjelder aldri tunnelens standardrute, og VPN-en er ikke årsaken. En skriver på 192.168.1.40 på en klient med 192.168.1.0/24 bruker den tilkoblede ruten; hvis den adressen feiler, se på enheten, svitsjen eller brannmuren på klienten i stedet for VPN-en.

Tilfellet som lurer folk, er en offentlig adresse for en lokal server. Innefra LAN-et krever det å nå ruterenes WAN-adresse og komme tilbake hairpin-NAT, og mange rutere implementerer det rett og slett ikke for portvideresending. Test den private adressen ved siden av den offentlige. Hvis den private virker og den offentlige ikke, har VPN-en bare avdekket en NAT-begrensning som allerede var der.

Et vertsnavn gjør dette verre. Hvis det lokale navnet nå løses til den offentlige adressen, vil klienten fortsette å prøve veien som ikke kan komme tilbake. Bruk den private adressen til testen, og rett deretter navnet i stedet for å legge til nok en portvideresending.

For det tredje, se hvem som svarer på navn nå

En bedriftsoppløser kjenner intranettet og vet vanligvis ingenting om et NAS-vertsnavn, skriverens Bonjour-navn eller ruterenes lokale alias. Når VPN-en dytter inn DNS-serverne sine, slutter disse navnene å løses selv om adressene deres fortsatt er tilgjengelige. Spør direkte på navnet og sammenlign svaret med adressen du vet enheten har.

På Linux viser resolvectl query nas.local hvilken oppløser som svarte. På Windows navngir nslookup nas.local serveren, og ipconfig /all viser rekkefølgen til oppløserne. Hvis det lokale suffikset nå håndteres av bedriftsoppløseren, kan du enten rute suffikset tilbake til den lokale oppløseren eller bruke IP-adressen for enheten.

Oppdagelse er et eget lag. mDNS og kringkasting krysser ikke en rutet tunnel, så en enhet kan være tilgjengelig via adresse mens navnet blir usynlig. En reflektor eller en lokal DNS-oppføring løser det; en rute gjør det ikke.

For det fjerde, sjekk om den andre maskinen også er på en VPN

Når maskinen du vil nå også kjører en VPN-klient, kan økten din komme fram mens svaret går ut gjennom den andre tunnelen. Det gir en tilkobling som etableres og deretter stopper, eller et RDP- og SSH-forsøk som timer ut uten feil på din side. Sjekk rutetabellen og standardveien til den andre verten før du gir klienten din skylden.

Sjekk også adressen tjenesten lytter på. En lytter som bare er bundet til tunneladressen, godtar tilkoblinger fra VPN-en og avviser dem fra LAN-et, selv når rutingen er perfekt. Det er en tjenestekonfigurasjon, ikke en nettverksvei, og det er vanlig på administrasjonsgrensesnitt som ble låst til VPN-adressen.

Hold en administrasjonsvei som ikke avhenger av tunnelen: en statisk rute som navngir kilenettverket ditt, et annet grensesnitt knyttet til LAN-et, eller en konsoll som omgår tunnelen helt. Å designe den veien etter at økten faller, er mye vanskeligere enn å legge den til før neste tilkobling.

Bruk reparasjonen som passer til kontrollen som feilet

Hvis rutetabellen viste en halvstandard-innfanging, velg delt tunnel når policyen tillater det og en festet lokal rute når den ikke gjør det. Hvis adressen viste seg å være offentlig, bytt testen og navnet til den private adressen. Hvis oppløseren byttet hender, begrens til det lokale suffikset eller bruk adressen. Hvis den andre verten er i tunnel, rett returveien eller lytterbindingen dens.

Endre én ting, og gjenta deretter den samme kontrollen. En rute lagt til for feil subnett, et oppløsersuffiks med skrivefeil og en festet rute på et grensesnitt som får nye numre ser alle ut som den opprinnelige feilen. Gjentakelsen er det som skiller en reparasjon fra en tilfeldighet.

Skriv ned ruten, adressen og oppløseren som virket mens VPN-en var tilkoblet. Den neste gjenoppkoblingen vil endre minst én av dem, og notatet gjør neste utfall til en kort sammenligning i stedet for en ny undersøkelse.