Rețeaua locală inaccesibilă cu VPN-ul conectat? Patru verificări

Tunelul urcă, intranetul apare, iar imprimanta nu mai răspunde. Nimic din LAN nu s-a defectat; clientul a schimbat calea pe care o folosește pentru adresele pe care nu le mai consideră locale. Parcurge cele patru verificări de mai jos în ordine și oprește-te când una arată o nepotrivire concretă, pentru că același simptom are patru cauze obișnuite și doar una dintre ele se rezolvă modificând VPN-ul.

Mai întâi, uită-te la tabelul de rute instalat de client

Deschide tabelul de rute al clientului cât timp VPN-ul este conectat. Pe Linux folosește ip route, pe Windows route print sau Get-NetRoute, iar pe macOS netstat -rn. Cauți o rută implicită prin tunel și ce s-a întâmplat cu ruta implicită fizică.

Un client cu tunel complet adaugă adesea două rute semi-implicite, 0.0.0.0/1 și 128.0.0.0/1, în loc să înlocuiască 0.0.0.0/0. Ruta implicită originală rămâne vizibilă dar pierde fiecare căutare, motiv pentru care tabelul poate părea intact în timp ce tot traficul din afara subrețelei se mută. Dacă clientul VPN oferă o opțiune de tunel divizat și politica permite, aceea este cea mai curată reparație.

Dacă tunelul trebuie să rămână implicit, fixează în schimb subrețeaua locală. Pe Linux ruta numește interfața fizică și gateway-ul; pe Windows adaugă -p ca să fie permanentă și citește numărul interfeței din route print în loc să îl ghicești:

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

O rută fixată rezistă doar cât timp adresa pe care o numește rămâne aceeași. Un laptop care primește un număr nou pentru adaptorul Wi-Fi la fiecare conectare va încălca din nou regula, așa că verifică adresa interfeței înainte de a concluziona că reparația a eșuat.

În al doilea rând, confirmă că adresa era locală de la început

Dacă destinația se află în subrețeaua conectată, ruta implicită a tunelului nu se aplică niciodată și VPN-ul nu este cauza. O imprimantă la 192.168.1.40 pe un client cu 192.168.1.0/24 folosește ruta conectată; dacă adresa aceea eșuează, uită-te la dispozitiv, la switch sau la firewall-ul clientului, nu la VPN.

Cazul care îi păcălește pe oameni este o adresă publică pentru un server local. Din interiorul LAN-ului, atingerea adresei WAN a routerului și întoarcerea cer hairpin NAT, iar multe routere pur și simplu nu îl implementează pentru redirecționarea porturilor. Testează adresa privată lângă cea publică. Dacă adresa privată funcționează și cea publică nu, VPN-ul a expus doar o limitare NAT care exista deja.

Un nume de gazdă înrăutățește situația. Dacă numele local se rezolvă acum la adresa publică, clientul va continua să încerce calea care nu poate reveni. Folosește adresa privată pentru test, apoi corectează numele în loc să adaugi încă o redirecționare de port.

În al treilea rând, vezi cine răspunde acum la nume

Un resolver de întreprindere cunoaște intranetul și de obicei nu știe nimic despre numele de gazdă al unui NAS, numele Bonjour al imprimantei sau aliasul local al routerului. Când VPN-ul își împinge serverele DNS, acele nume nu se mai rezolvă deși adresele lor rămân accesibile. Interoghează numele direct și compară răspunsul cu adresa despre care știi că o are dispozitivul.

Pe Linux, resolvectl query nas.local arată care resolver a răspuns. Pe Windows, nslookup nas.local numește serverul, iar ipconfig /all arată ordinea resolverelor. Dacă sufixul local este acum gestionat de resolverul de întreprindere, fie redirecționează sufixul înapoi la resolverul local, fie folosește adresa IP pentru dispozitiv.

Descoperirea este un strat separat. mDNS și broadcast nu traversează un tunel rutat, așa că un dispozitiv poate fi accesibil după adresă în timp ce numele rămâne invizibil. Un reflector sau o intrare DNS locală rezolvă asta; o rută nu.

În al patrulea rând, verifică dacă și cealaltă mașină este într-un VPN

Când mașina pe care vrei să o atingi rulează și ea un client VPN, sesiunea ta poate ajunge în timp ce răspunsul iese prin celălalt tunel. Rezultă o conexiune care se stabilește și apoi se blochează, sau o încercare RDP și SSH care expiră fără eroare de partea ta. Verifică tabelul de rute al celuilalt gazdă și calea lui implicită înainte de a da vina pe clientul tău.

Verifică și adresa pe care ascultă serviciul. Un listener legat doar de adresa tunelului acceptă conexiuni din VPN și le refuză pe cele din LAN, chiar și când rutarea este perfectă. Aceasta este o configurație a serviciului, nu o cale de rețea, și este obișnuită pe interfețele de administrare închise pe adresa VPN.

Păstrează o cale de administrare care nu depinde de tunel: o rută statică ce numește rețeaua ta sursă, o altă interfață conectată la LAN sau o consolă care ocolește complet tunelul. Să proiectezi acea cale după ce sesiunea cade este mult mai greu decât să o adaugi înainte de următoarea conectare.

Aplică reparația care corespunde verificării eșuate

Dacă tabelul de rute a arătat o captură semi-implicită, alege tunelul divizat când politica permite și o rută locală fixată când nu permite. Dacă adresa s-a dovedit publică, mută testul și numele pe adresa privată. Dacă resolverul a schimbat mâini, limitează-te la sufixul local sau folosește adresa. Dacă cealaltă gazdă este în tunel, repară-i calea de întoarcere sau legarea listenerului.

Schimbă un singur lucru, apoi repetă aceeași verificare. O rută adăugată pentru subrețeaua greșită, un sufix de resolver cu o greșeală de tastare și o rută fixată pe o interfață care primește numere noi arată toate ca defectul original. Repetarea este ce desparte o reparație de o coincidență.

Notează ruta, adresa și resolverul care au funcționat cât timp VPN-ul era conectat. Următoarea reconectare va schimba cel puțin una dintre ele, iar nota transformă următoarea pană într-o comparație scurtă în loc de o anchetă nouă.