Rrjeti lokal i paarritshëm ndërsa VPN-i është i lidhur? Katër kontrolle

Tuneli ngrihet, intraneti shfaqet, dhe printeri ndalon së përgjigjuri. Në LAN nuk është prishur asgjë; klienti ka ndryshuar rrugën që përdor për adresat që nuk i trajton më si lokale. Kryeni katër kontrollet më poshtë me radhë dhe ndaloni kur njëra të tregojë një mospërputhje konkrete, sepse e njëjta simptomë ka katër shkaqe të zakonshme dhe vetëm njëri prej tyre rregullohet duke ndryshuar VPN-in.

Së pari, shikoni tabelën e rrugëve që instaloi klienti

Hapni tabelën e rrugëve të klientit ndërsa VPN-i është i lidhur. Në Linux përdorni ip route, në Windows route print ose Get-NetRoute, dhe në macOS netstat -rn. Po kërkoni një rrugë të parazgjedhur përmes tunelit dhe çfarë ndodhi me rrugën e parazgjedhur fizike.

Një klient me tunel të plotë shpesh shton dy rrugë gjysmë të parazgjedhura, 0.0.0.0/1 dhe 128.0.0.0/1, në vend që të zëvendësojë 0.0.0.0/0. Rruga e parazgjedhur origjinale mbetet e dukshme por humbet çdo kërkim, prandaj tabela mund të duket e paprekur ndërkohë që i gjithë trafiku jashtë nënrrjetit zhvendoset. Nëse klienti i VPN-it ofron një opsion tuneli të ndarë dhe politika e lejon, ai është rregullimi më i pastër.

Nëse tuneli duhet të mbetet i parazgjedhuri, fiksoni në vend të kësaj nënrrjetin lokal. Në Linux rruga emërton ndërfaqen fizike dhe portën; në Windows shtoni -p për ta bërë të përhershme dhe lexoni numrin e ndërfaqes nga route print në vend që ta hamendësoni:

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

Një rrugë e fiksuar qëndron vetëm sa kohë që adresa që emërton mbetet e njëjtë. Një laptop që merr numër të ri për përshtatësin Wi-Fi në çdo lidhje do ta thyejë përsëri rregullin, prandaj kontrolloni adresën e ndërfaqes përpara se të përfundoni se rregullimi dështoi.

Së dyti, konfirmoni se adresa ishte lokale që në fillim

Nëse destinacioni ndodhet brenda nënrrjetit të lidhur, rruga e parazgjedhur e tunelit nuk zbatohet kurrë dhe VPN-i nuk është shkaku. Një printer në 192.168.1.40 në një klient me 192.168.1.0/24 përdor rrugën e lidhur; nëse ajo adresë dështon, shikoni pajisjen, switch-in ose murin e zjarrit të klientit dhe jo VPN-in.

Rasti që i mashtron njerëzit është një adresë publike për një server lokal. Nga brenda LAN-it, arritja e adresës WAN të ruterit dhe kthimi kërkon hairpin NAT, dhe shumë ruterë thjesht nuk e zbatojnë atë për përcjelljen e porteve. Testoni adresën private pranë asaj publike. Nëse adresa private funksionon dhe ajo publike jo, VPN-i vetëm zbuloi një kufizim NAT që ekzistonte më parë.

Një emër hosti e përkeqëson këtë. Nëse emri lokal tani zgjidhet në adresën publike, klienti do të vazhdojë të provojë rrugën që nuk mund të kthehet. Përdorni adresën private për testin, më pas rregulloni emrin në vend që të shtoni një tjetër përcjellje portesh.

Së treti, shikoni kush u përgjigjet emrave tani

Një zgjidhës korporativ e njeh intranetin dhe zakonisht nuk di asgjë për emrin e hostit të NAS-it, emrin Bonjour të printerit ose aliasin lokal të ruterit. Kur VPN-i shtyn serverat e tij DNS, ato emra ndalojnë së zgjidhuri edhe pse adresat e tyre janë ende të arritshme. Pyetni emrin drejtpërdrejt dhe krahasoni përgjigjen me adresën që dini se e ka pajisja.

Në Linux, resolvectl query nas.local tregon cili zgjidhës u përgjigj. Në Windows, nslookup nas.local emërton serverin, dhe ipconfig /all tregon rendin e zgjidhësve. Nëse prapashtesa lokale tani trajtohet nga zgjidhësi korporativ, ose drejtojeni atë prapashtesë përsëri te zgjidhësi lokal ose përdorni adresën IP për pajisjen.

Zbulimi është një shtresë më vete. mDNS dhe transmetimi nuk kalojnë një tunel të rrugëtuar, prandaj një pajisje mund të jetë e arritshme me adresë ndërkohë që emri i saj mbetet i padukshëm. Një reflektor ose një zë DNS lokal e zgjidh atë; një rrugë jo.

Së katërti, kontrolloni nëse edhe makina tjetër është në VPN

Kur makina që dëshironi të arrini gjithashtu ekzekuton një klient VPN, sesioni juaj mund të arrijë ndërkohë që përgjigja del përmes tunelit tjetër. Kjo prodhon një lidhje që vendoset dhe më pas ngec, ose një përpjekje RDP dhe SSH që skadon pa gabim nga ana juaj. Kontrolloni tabelën e rrugëve dhe rrugën e parazgjedhur të hostit tjetër përpara se të fajësoni klientin tuaj.

Kontrolloni edhe adresën në të cilën dëgjon shërbimi. Një dëgjues i lidhur vetëm me adresën e tunelit pranon lidhjet nga VPN-i dhe i refuzon ato nga LAN-i, edhe kur rrugëtimi është i përsosur. Kjo është konfigurim i shërbimit, jo rrugë rrjeti, dhe është i zakonshëm në ndërfaqet e menaxhimit që u mbyllën në adresën e VPN-it.

Mbani një rrugë menaxhimi që nuk varet nga tuneli: një rrugë statike që emërton rrjetin tuaj burim, një ndërfaqe tjetër e lidhur me LAN-in, ose një konsolë që e anashkalon plotësisht tunelin. Të projektove atë rrugë pasi sesioni bie është shumë më e vështirë sesa ta shtosh përpara lidhjes së ardhshme.

Zbatoni rregullimin që i përgjigjet kontrollit të dështuar

Nëse tabela e rrugëve tregoi një kapje gjysmë të parazgjedhur, zgjidhni tunel të ndarë kur politika e lejon dhe një rrugë lokale të fiksuar kur nuk e lejon. Nëse adresa doli publike, kaloni testin dhe emrin në adresën private. Nëse zgjidhësi ndryshoi duar, kufizohuni në prapashtesën lokale ose përdorni adresën. Nëse hosti tjetër është në tunel, rregulloni rrugën e tij të kthimit ose lidhjen e dëgjuesit.

Ndryshoni një gjë, më pas përsëritni të njëjtin kontroll. Një rrugë e shtuar për nënrrjetin e gabuar, një prapashtesë zgjidhësi me gabim shtypi dhe një rrugë e fiksuar në një ndërfaqe që merr numra të rinj duken të gjitha si defekti origjinal. Përsëritja është ajo që ndan rregullimin nga rastësia.

Shkruani rrugën, adresën dhe zgjidhësin që funksionuan ndërsa VPN-i ishte i lidhur. Rilidhja tjetër do të ndryshojë të paktën njërën prej tyre, dhe shënimi e kthen ndërprerjen tjetër në një krahasim të shkurtër në vend të një hetimi të ri.