Lokalna mreža nedostupna dok je VPN povezan? Četiri provjere

Tunel se podiže, intranet se pojavljuje, a pisač prestaje odgovarati. Na LAN-u se ništa nije pokvarilo; klijent je promijenio put koji koristi za adrese koje više ne smatra lokalnima. Prođite četiri provjere ispod po redu i zaustavite se kad jedna pokaže konkretno neslaganje, jer isti simptom ima četiri česta uzroka i samo se jedan od njih rješava uređivanjem VPN-a.

Prvo, pogledajte tablicu ruta koju je klijent instalirao

Otvorite tablicu ruta klijenta dok je VPN povezan. Na Linuxu koristite ip route, na Windowsu route print ili Get-NetRoute, a na macOS-u netstat -rn. Tražite zadanu rutu kroz tunel i ono što se dogodilo s fizičkom zadanom rutom.

Klijent s punim tunelom često dodaje dvije poluzadane rute, 0.0.0.0/1 i 128.0.0.0/1, umjesto da zamijeni 0.0.0.0/0. Izvorna zadana ruta ostaje vidljiva ali gubi svako traženje, zato tablica može izgledati netaknuta dok se sav promet izvan podmreže pomiče. Ako VPN klijent nudi opciju podijeljenog tunela i politika to dopušta, to je najčišći popravak.

Ako tunel mora ostati zadani, prikvačite lokalnu podmrežu. Na Linuxu ruta imenuje fizičko sučelje i pristupnik; na Windowsu dodajte -p da bude trajna i pročitajte broj sučelja iz route print umjesto da ga pogađate:

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

Prikvačena ruta drži se samo dok adresa koju imenuje ostaje ista. Prijenosnik koji pri svakom spajanju dobije novi broj Wi-Fi adaptera ponovno će prekršiti pravilo, zato provjerite adresu sučelja prije nego zaključite da popravak nije uspio.

Drugo, potvrdite da je adresa bila lokalna od početka

Ako odredište leži unutar povezane podmreže, zadana ruta tunela nikada se ne primjenjuje i VPN nije uzrok. Pisač na 192.168.1.40 na klijentu s 192.168.1.0/24 koristi povezanu rutu; ako ta adresa ne radi, gledajte uređaj, preklopnik ili vatrozid na klijentu, a ne VPN.

Slučaj koji zavara ljude jest javna adresa za lokalni poslužitelj. Iz unutrašnjosti LAN-a dostizanje WAN adrese routera i povratak zahtijeva hairpin NAT, a mnogi routeri to jednostavno ne implementiraju za prosljeđivanje portova. Testirajte privatnu adresu pored javne. Ako privatna radi, a javna ne, VPN je samo otkrio NAT ograničenje koje je već postojalo.

Ime hosta to pogoršava. Ako se lokalno ime sada razrješava na javnu adresu, klijent će nastaviti isprobavati put koji se ne može vratiti. Za test koristite privatnu adresu, a zatim ispravite ime umjesto da dodate još jedno prosljeđivanje portova.

Treće, pogledajte ko sada odgovara na imena

Korporativni resolver poznaje intranet i obično ne zna ništa o imenu hosta NAS-a, Bonjour imenu pisača ili lokalnom aliasu routera. Kad VPN progura svoje DNS poslužitelje, ta imena prestaju se razrješavati iako su njihove adrese još dostupne. Upitajte ime izravno i usporedite odgovor s adresom za koju znate da je uređaj ima.

Na Linuxu resolvectl query nas.local pokazuje koji je resolver odgovorio. Na Windowsu nslookup nas.local imenuje poslužitelj, a ipconfig /all pokazuje redoslijed resolvera. Ako lokalnim sufiksom sada upravlja korporativni resolver, bilo preusmjerite taj sufiks natrag na lokalni resolver, bilo koristite IP adresu za uređaj.

Otkriće je zaseban sloj. mDNS i emitiranje ne prelaze rutirani tunel, pa uređaj može biti dostupan po adresi dok njegovo ime ostaje nevidljivo. Reflektor ili lokalni DNS zapis to rješava; ruta ne.

Četvrto, provjerite je li i drugi stroj na VPN-u

Kad stroj koji želite dosegnuti također vrti VPN klijent, vaša sesija može stići dok odgovor izlazi kroz drugi tunel. To stvara vezu koja se uspostavi i zatim zapne, ili pokušaj RDP-a i SSH-a koji na vašoj strani istekne bez greške. Provjerite tablicu ruta drugog hosta i njegov zadani put prije nego okrivite svoj klijent.

Provjerite i adresu na kojoj služba sluša. Slušatelj vezan samo za adresu tunela prihvaća veze iz VPN-a i odbija ih iz LAN-a, čak i kad je usmjeravanje savršeno. To je konfiguracija službe, ne mrežni put, i često je na upravljačkim sučeljima koja su zaključana na adresu VPN-a.

Održavajte upravljački put koji ne ovisi o tunelu: statična ruta koja imenuje vašu izvornu mrežu, drugo sučelje spojeno na LAN ili konzola koja potpuno zaobilazi tunel. Projektirati taj put nakon što sesija padne mnogo je teže nego dodati ga prije sljedećeg spajanja.

Primijenite popravak koji odgovara provjeri koja nije prošla

Ako je tablica ruta pokazala poluzadanu otmicu, odaberite podijeljeni tunel kad politika dopušta i prikvačenu lokalnu rutu kad ne dopušta. Ako se adresa pokazala javnom, prebacite test i ime na privatnu adresu. Ako je resolver promijenio ruke, ograničite se na lokalni sufiks ili koristite adresu. Ako je drugi host u tunelu, popravite njegov povratni put ili vezanje slušatelja.

Promijenite jednu stvar, pa ponovite istu provjeru. Ruta dodana za pogrešnu podmrežu, sufiks resolvera s tipfelerom i prikvačena ruta na sučelju koje dobiva nove brojeve svi izgledaju kao izvorni kvar. Ponavljanje je ono što dijeli popravak od slučajnosti.

Zapišite rutu, adresu i resolver koji su radili dok je VPN bio povezan. Sljedeće ponovno spajanje promijenit će barem jedno od njih, a bilješka pretvara sljedeći prekid u kratku usporedbu umjesto nove istrage.