Vietējais tīkls nav sasniedzams, kamēr VPN ir pieslēgts? Četras pārbaudes

Tunelis paceļas, intranets parādās, un printeris pārstāj atbildēt. LAN tīklā nekas nav sabojājies; klients ir mainījis, kuru ceļu tas izmanto adresēm, kuras vairs neuzskata par vietējām. Veiciet četras pārbaudes zemāk pēc kārtas un apstājieties, kad viena parāda konkrētu neatbilstību, jo vienam un tam pašam simptomam ir četri izplatīti cēloņi, un tikai viens no tiem tiek novērsts, rediģējot VPN.

Vispirms apskatiet maršrutu tabulu, ko klients ir instalējis

Atveriet klienta maršrutu tabulu, kamēr VPN ir pieslēgts. Linux izmantojiet ip route, Windows — route print vai Get-NetRoute, bet macOS — netstat -rn. Jūs meklējat noklusējuma maršrutu caur tuneli un to, kas notika ar fizisko noklusējuma maršrutu.

Pilna tuneļa klients bieži pievieno divus pusnoklusējuma maršrutus, 0.0.0.0/1 un 128.0.0.0/1, tā vietā, lai aizstātu 0.0.0.0/0. Sākotnējais noklusējums paliek redzams, bet zaudē katru meklēšanu, tāpēc tabula var izskatīties neskarta, kamēr viss trafiks ārpus apakštīkla pārvietojas. Ja VPN klients piedāvā sadalītā tuneļa iespēju un politika to atļauj, tas ir vistīrākais labojums.

Ja tunelim jāpaliek noklusējumam, tad piespraudiet vietējo apakštīklu. Linux maršruts nosauc fizisko saskarni un vārteju; Windows pievienojiet -p, lai tas būtu pastāvīgs, un saskarnes numuru lasiet no route print, nevis miniet:

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

Piesprausts maršruts darbojas tikai tik ilgi, kamēr tajā nosauktā adrese nemainās. Portatīvais dators, kas katrā savienojumā saņem jaunu Wi-Fi adaptera numuru, atkal pārkāps noteikumu, tāpēc pirms secināt, ka labojums neizdevās, pārbaudiet saskarnes adresi.

Otrkārt, apstipriniet, ka adrese jau sākotnēji bija vietēja

Ja galamērķis atrodas pieslēgtajā apakštīklā, tuneļa noklusējuma maršruts nekad netiek piemērots, un VPN nav cēlonis. Printeris ar adresi 192.168.1.40 klientā ar 192.168.1.0/24 izmanto pieslēgto maršrutu; ja šī adrese nedarbojas, skatiet ierīci, komutatoru vai klienta ugunsmūri, nevis VPN.

Gadījums, kas maldina cilvēkus, ir publiska adrese vietējam serverim. No LAN iekšpuses sasniegt maršrutētāja WAN adresi un atgriezties atpakaļ prasa hairpin NAT, un daudzi maršrutētāji to vienkārši neievieš portu pāradresācijai. Pārbaudiet privāto adresi blakus publiskajai. Ja privātā darbojas, bet publiskā ne, VPN tikai atklāja NAT ierobežojumu, kas jau bija.

Resursdatora vārds to padara vēl sliktāku. Ja vietējais vārds tagad tiek atrisināts uz publisko adresi, klients turpinās mēģināt ceļu, kas nevar atgriezties. Testam izmantojiet privāto adresi, pēc tam labojiet vārdu, nevis pievienojiet vēl vienu portu pāradresāciju.

Treškārt, apskatiet, kas tagad atbild uz vārdiem

Uzņēmuma atrisinātājs zina intranetu un parasti neko nezina par NAS resursdatora vārdu, printera Bonjour vārdu vai maršrutētāja vietējo aizstājvārdu. Kad VPN iespiež savus DNS serverus, šie vārdi pārstāj atrisināties, lai gan to adreses joprojām ir sasniedzamas. Vaicājiet vārdu tieši un salīdziniet atbildi ar adresi, kuru, jūs zināt, ierīcei ir.

Linux resolvectl query nas.local parāda, kurš atrisinātājs atbildēja. Windows nslookup nas.local nosauc serveri, un ipconfig /all parāda atrisinātāju secību. Ja vietējo sufiksu tagad apstrādā uzņēmuma atrisinātājs, vai nu novirziet šo sufiksu atpakaļ uz vietējo atrisinātāju, vai ierīcei izmantojiet IP adresi.

Atklāšana ir atsevišķs slānis. mDNS un apraide nešķērso maršrutētu tuneli, tāpēc ierīce var būt sasniedzama pēc adreses, kamēr tās vārds paliek neredzams. Atstarotājs vai vietējs DNS ieraksts to atrisina; maršruts ne.

Ceturtkārt, pārbaudiet, vai arī otra mašīna ir VPN

Kad mašīna, kurai vēlaties piekļūt, arī darbojas VPN klients, jūsu sesija var ierasties, kamēr tās atbilde iziet caur otru tuneli. Tā rodas savienojums, kas izveidojas un pēc tam iestrēgst, vai RDP un SSH mēģinājums, kas jūsu pusē bez kļūdas beidzas ar taimautu. Pirms vainot savu klientu, pārbaudiet otras mašīnas maršrutu tabulu un tās noklusējuma ceļu.

Pārbaudiet arī adresi, uz kuras pakalpojums klausās. Tikai pie tuneļa adreses piesaistīts klausītājs pieņem savienojumus no VPN un noraida tos no LAN, pat ja maršrutēšana ir nevainojama. Tā ir pakalpojuma konfigurācija, nevis tīkla ceļš, un tas ir izplatīti pārvaldības saskarnēs, kas tika aizslēgtas pie VPN adreses.

Saglabājiet pārvaldības ceļu, kas nav atkarīgs no tuneļa: statisks maršruts, kas nosauc jūsu avota tīklu, cita saskarne, kas pievienota LAN, vai konsole, kas pilnībā apiet tuneli. Projektēt šo ceļu pēc sesijas pārtraukuma ir daudz grūtāk nekā pievienot to pirms nākamā savienojuma.

Piemērojiet labojumu, kas atbilst neizdevušajai pārbaudei

Ja maršrutu tabula parādīja pusnoklusējuma pārņemšanu, izvēlieties sadalīto tuneli, kad politika atļauj, un piespraustu vietējo maršrutu, kad neļauj. Ja adrese izrādījās publiska, pārslēdziet testu un vārdu uz privāto adresi. Ja atrisinātājs ir mainījis rokas, ierobežojiet ar vietējo sufiksu vai izmantojiet adresi. Ja otra mašīna ir tunelī, izlabojiet tās atgriešanās ceļu vai klausītāja piesaisti.

Mainiet vienu lietu, pēc tam atkārtojiet to pašu pārbaudi. Maršruts, kas pievienots nepareizam apakštīklam, atrisinātāja sufikss ar drukas kļūdu un piesprausts maršruts saskarnē, kas saņem jaunus numurus, visi izskatās kā sākotnējā kļūme. Atkārtošana ir tas, kas atšķir labojumu no nejaušības.

Pierakstiet maršrutu, adresi un atrisinātāju, kas darbojās, kamēr VPN bija pieslēgts. Nākamā atkārtotā pieslēgšanās mainīs vismaz vienu no tiem, un pieraksts nākamo pārtraukumu pārvērtīs īsā salīdzinājumā, nevis jaunā izmeklēšanā.