Lokalt nettverk utilgjengeleg medan VPN er tilkopla? Fire kontrollar

Tunnelen kjem opp, intranettet blir synleg, og skrivaren sluttar å svare. Ingenting på LAN-et har feila; klienten har endra kva veg han brukar for adresser han ikkje lenger handsamar som lokale. Gå gjennom dei fire kontrollane nedanfor i rekkjefølgje og stopp når ein av dei viser eit konkret avvik, fordi det same symptomet har fire vanlege årsaker, og berre éi av dei blir retta ved å endre VPN-en.

Fyrst, sjå på rutetabellen klienten installerte

Opne rutetabellen til klienten medan VPN-en er tilkopla. På Linux brukar du ip route, på Windows route print eller Get-NetRoute, og på macOS netstat -rn. Du leitar etter ei standardrute gjennom tunnelen og etter kva som skjedde med den fysiske standardruta.

Ein fulltunnelklient legg ofte til to halvstandardruter, 0.0.0.0/1 og 128.0.0.0/1, i staden for å erstatta 0.0.0.0/0. Den opphavlege standardruta blir verande synleg, men taper kvart oppslag, og difor kan tabellen sjå intakt ut medan all trafikk utanfor subnettet flyttar seg. Viss VPN-klienten tilbyr eit alternativ for delt tunnel og policyen tillèt det, er det den reinaste reparasjonen.

Viss tunnelen må bli verande standard, festar du det lokale subnettet i staden. På Linux namngir ruta det fysiske grensesnittet og gatewayen; på Windows legg du til -p for å gjera henne varig og les grensesnittnummeret frå route print i staden for å 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

Ei fest rute held berre så lenge adressa ho namngir er den same. Ein berbar PC som får nytt nummer på Wi-Fi-adapteren ved kvar tilkopling, bryt regelen igjen, så sjekk grensesnittadressa før du konkluderer med at reparasjonen mislukkast.

For det andre, stadfest at adressa var lokal i utgangspunktet

Viss målet ligg inne i det tilkopla subnettet, gjeld aldri standardruta til tunnelen, og VPN-en er ikkje årsaka. Ein skrivar på 192.168.1.40 på ein klient med 192.168.1.0/24 brukar den tilkopla ruta; viss den adressa feilar, sjå på eininga, svitsjen eller brannmuren på klienten i staden for VPN-en.

Tilfellet som lurar folk, er ei offentleg adresse for ein lokal tenar. Innanfrå LAN-et krev det å nå WAN-adressa til rutaren og koma tilbake hairpin-NAT, og mange rutarar implementerer det rett og slett ikkje for portvideresending. Test den private adressa ved sida av den offentlege. Viss den private verkar og den offentlege ikkje, har VPN-en berre avdekt ei NAT-avgrensing som allereie var der.

Eit vertsnamn gjer dette verre. Viss det lokale namnet no blir løyst til den offentlege adressa, vil klienten fortsetja å prøva vegen som ikkje kan koma tilbake. Bruk den private adressa til testen, og rett deretter namnet i staden for å leggja til endå ei portvideresending.

For det tredje, sjå kven som svarar på namn no

Ein bedriftsoppløysar kjenner intranettet og veit vanlegvis ingenting om eit NAS-vertsnamn, Bonjour-namnet til skrivaren eller det lokale aliaset til rutaren. Når VPN-en dyttar inn DNS-tenarane sine, sluttar desse namna å løysast sjølv om adressene deira framleis er tilgjengelege. Spør direkte på namnet og samanlikn svaret med adressa du veit eininga har.

På Linux viser resolvectl query nas.local kva oppløysar som svara. På Windows namngir nslookup nas.local tenaren, og ipconfig /all viser rekkjefølgja til oppløysarane. Viss det lokale suffikset no blir handsama av bedriftsoppløysaren, kan du anten rute suffikset tilbake til den lokale oppløysaren eller bruke IP-adressa for eininga.

Oppdaging er eit eige lag. mDNS og kringkasting kryssar ikkje ein ruta tunnel, så ei eining kan vera tilgjengeleg via adresse medan namnet blir usynleg. Ein reflektor eller ein lokal DNS-oppføring løyser det; ei rute gjer det ikkje.

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

Når maskinen du vil nå også køyrer ein VPN-klient, kan økta di koma fram medan svaret går ut gjennom den andre tunnelen. Det gir ei tilkopling som blir etablert og deretter stoppar, eller eit RDP- og SSH-forsøk som timar ut utan feil på di side. Sjekk rutetabellen og standardvegen til den andre verten før du gir klienten din skulda.

Sjekk også adressa tenesta lyttar på. Ein lyttar som berre er bunden til tunneladressa, godtar tilkoplingar frå VPN-en og avviser dei frå LAN-et, sjølv når rutinga er perfekt. Det er ein tenestekonfigurasjon, ikkje ein nettverksveg, og det er vanleg på administrasjonsgrensesnitt som blei låste til VPN-adressa.

Hald ein administrasjonsveg som ikkje er avhengig av tunnelen: ei statisk rute som namngir kjeldenettverket ditt, eit anna grensesnitt knytt til LAN-et, eller ein konsoll som går heilt utanom tunnelen. Å designe den vegen etter at økta fell, er mykje vanskelegare enn å leggja han til før neste tilkopling.

Bruk reparasjonen som passar til kontrollen som feila

Viss rutetabellen viste ei halvstandard-overtaking, vel delt tunnel når policyen tillèt det og ei fest lokal rute når han ikkje gjer det. Viss adressa viste seg å vera offentleg, byt testen og namnet til den private adressa. Viss oppløysaren bytte hender, avgrens til det lokale suffikset eller bruk adressa. Viss den andre verten er i tunnel, rett returvegen eller lyttarbindinga hans.

Endre éin ting, og gjenta deretter den same kontrollen. Ei rute lagd til for feil subnett, eit oppløysarsuffiks med skrivefeil og ei fest rute på eit grensesnitt som får nye nummer ser alle ut som den opphavlege feilen. Gjentakinga er det som skil ein reparasjon frå ein tilfeldigheit.

Skriv ned ruta, adressa og oppløysaren som virka medan VPN-en var tilkopla. Den neste gjenoppkoplinga vil endre minst éin av dei, og notatet gjer neste utfall til ein kort samanlikning i staden for ei ny undersøking.