Vietinis tinklas nepasiekiamas, kai VPN prijungtas? Keturi patikrinimai

Tunelis pakyla, intranetas pasirodo, o spausdintuvas nustoja atsakinėti. LAN tinkle niekas nesugedo; klientas pakeitė, kokį kelią naudoja adresams, kurių nebelaiko vietiniais. Atlikite keturis patikrinimus iš eilės ir sustokite, kai vienas parodo konkrečią neatitiktį, nes tas pats simptomas turi keturias dažnas priežastis, ir tik viena jų išsprendžiama keičiant VPN.

Pirmiausia pažiūrėkite maršrutų lentelę, kurią įdiegė klientas

Atidarykite kliento maršrutų lentelę, kol VPN prijungtas. Linux naudokite ip route, Windows – route print arba Get-NetRoute, o macOS – netstat -rn. Ieškote numatytojo maršruto per tunelį ir to, kas nutiko fiziniam numatytajam maršrutui.

Viso tunelio klientas dažnai prideda du pusiau numatytuosius maršrutus, 0.0.0.0/1 ir 128.0.0.0/1, užuot pakeitęs 0.0.0.0/0. Pradinis numatytasis lieka matomas, bet pralaimi kiekvieną paiešką, todėl lentelė gali atrodyti nepakitusi, nors visas srautas už potinklio juda. Jei VPN klientas siūlo skaidyto tunelio parinktį ir politika leidžia, tai švariausias taisymas.

Jei tunelis turi likti numatytasis, prisekite vietinį potinklį. Linux maršrutas nurodo fizinį sąsają ir šliuzą; Windows pridėkite -p, kad jis būtų nuolatinis, o sąsajos numerį skaitykite iš route print, o ne spėliokite:

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

Prisegtas maršrutas galioja tik tol, kol jame nurodytas adresas nesikeičia. Nešiojamasis kompiuteris, kuris kiekvieną kartą prisijungdamas gauna naują Wi-Fi adapterio numerį, vėl sulaužys taisyklę, todėl prieš nuspręsdami, kad taisymas nepavyko, patikrinkite sąsajos adresą.

Antra, patvirtinkite, kad adresas iš pradžių buvo vietinis

Jei paskirties vieta yra prijungtame potinklyje, tunelio numatytasis maršrutas niekada netaikomas ir VPN nėra priežastis. Spausdintuvas adresu 192.168.1.40 kliente su 192.168.1.0/24 naudoja prijungtą maršrutą; jei šis adresas neveikia, žiūrėkite įrenginį, komutatorių ar kliento užkardą, o ne VPN.

Atvejis, kuris klaidina žmones, yra viešas vietinio serverio adresas. Iš LAN vidaus pasiekti maršrutizatoriaus WAN adresą ir grįžti atgal reikia hairpin NAT, o daugelis maršrutizatorių jo paprasčiausiai neįgyvendina portų peradresavimui. Išbandykite privatų adresą šalia viešo. Jei privatus veikia, o viešas ne, VPN tik atskleidė NAT apribojimą, kuris jau buvo.

Priklausomasis vardas tai dar labiau pablogina. Jei vietinis vardas dabar išsprendžiamas į viešą adresą, klientas toliau bandys kelią, kuris negali grįžti. Testui naudokite privatų adresą, o tada taisykite vardą, o ne pridėkite dar vieną portų peradresavimą.

Trečia, pažiūrėkite, kas dabar atsako į vardus

Įmonės resolveris žino intranetą ir paprastai nieko nežino apie NAS priklausomąjį vardą, spausdintuvo Bonjour vardą ar maršrutizatoriaus vietinį aliasą. Kai VPN įstumia savo DNS serverius, tie vardai nustoja sprendžiami, nors jų adresai vis dar pasiekiami. Užklauskite vardą tiesiogiai ir palyginkite atsakymą su adresu, kurį, žinote, turi įrenginys.

Linux resolvectl query nas.local parodo, kuris resolveris atsakė. Windows nslookup nas.local nurodo serverį, o ipconfig /all rodo resolverių eilę. Jei vietinį galūnį dabar tvarko įmonės resolveris, nukreipkite tą galūnį atgal į vietinį resolverį arba naudokite įrenginiui IP adresą.

Aptikimas yra atskiras sluoksnis. mDNS ir transliavimas neperžengia maršrutizuoto tunelio, todėl įrenginys gali būti pasiekiamas adresu, o jo vardas likti nematomas. Reflektorius arba vietinis DNS įrašas tai išsprendžia; maršrutas – ne.

Ketvirta, patikrinkite, ar kita mašina taip pat yra VPN

Kai mašina, kurią norite pasiekti, taip pat paleidusi VPN klientą, jūsų sesija gali atvykti, o atsakymas išeiti per kitą tunelį. Taip susidaro ryšys, kuris užsimezga ir tada sustoja, arba RDP ir SSH bandymas, kuris jūsų pusėje baigiasi laiko limito klaida be jokios klaidos. Prieš kaltindami savo klientą patikrinkite kito kompiuterio maršrutų lentelę ir jo numatytąjį kelią.

Taip pat patikrinkite adresą, kuriuo tarnyba klausosi. Tik prie tunelio adreso pririštas klausytojas priima ryšius iš VPN ir atmeta juos iš LAN, net kai maršrutizavimas tobulas. Tai tarnybos konfigūracija, o ne tinklo kelias, ir tai įprasta valdymo sąsajose, kurios buvo užrakintos prie VPN adreso.

Išlaikykite valdymo kelią, kuris nepriklauso nuo tunelio: statinis maršrutas, nurodantis jūsų šaltinio tinklą, kita prie LAN prijungta sąsaja arba pultas, visiškai apeinantis tunelį. Suprojektuoti tą kelią po sesijos nutrūkimo yra daug sunkiau nei pridėti jį prieš kitą prisijungimą.

Taikykite taisymą, atitinkantį nepavykusį patikrinimą

Jei maršrutų lentelė parodė pusiau numatytojo užgrobimą, rinkitės skaidytą tunelį, kai politika leidžia, ir prisegtą vietinį maršrutą, kai neleidžia. Jei adresas pasirodė viešas, perjunkite testą ir vardą į privatų adresą. Jei resolveris pakeitė rankas, apribokite vietiniu galūniu arba naudokite adresą. Jei kitas kompiuteris yra tunelyje, sutaisykite jo grįžimo kelią arba klausytojo priskyrimą.

Pakeiskite vieną dalyką, tada pakartokite tą patį patikrinimą. Maršrutas, pridėtas netinkamam potinkliui, resolverio galūnė su rašybos klaida ir prisegtas maršrutas sąsajoje, kuri gauna naujus numerius, visi atrodo kaip pradinis gedimas. Pakartojimas yra tai, kas atskiria taisymą nuo atsitiktinumo.

Užsirašykite maršrutą, adresą ir resolverį, kurie veikė, kol VPN buvo prijungtas. Kitas prisijungimas pakeis bent vieną iš jų, o užrašas pavers kitą sutrikimą trumpu palyginimu, o ne nauju tyrimu.