Router în modul client VPN: de ce dispar dispozitivele LAN

Convingerea că modul client în sine ucide accesul LAN duce oamenii în meniul greșit de setări, iar cauzele reale sunt de obicei două. Tunelul nu elimină puntea LAN și nu împiedică clienții cablați și wireless să se atingă reciproc. Ceea ce rupe accesul local este fie o funcție de inspecție din calea de forwardare a routerului, fie un interval de adrese LAN care s-a mutat când firmware-ul a făcut-o. Ambele produc aceeași reclamație, iar niciuna nu se rezolvă prin reinstalarea profilului VPN.

Mitul și ce schimbă de fapt modul client

Modul client adaugă o interfață de tunel și o rută implicită care trece prin ea, apoi trimite traficul LAN în acel tunel. Puntea dintre porturile cablate și radiourile wireless rămâne intactă, la fel și comutarea locală. Ce se schimbă este politica: ce trafic este forwardat, unde este tradus și ce resolver primesc clienții.

Acea distincție contează pentru că un LAN stricat înseamnă de obicei că una dintre cele trei politici s-a schimbat, nu că routerul a încetat să fie un switch. Un router care încă răspunde la propria pagină de administrare este dovada că interfața LAN este vie. Un router care nu răspunde la nimic are altă problemă, cum ar fi o adresă LAN schimbată sau un client în subrețeaua greșită.

Deci primul pas util este să aflați ce strat s-a stricat, nu să schimbați stratul pe care îl suspicionați.

Testați trei ținte înainte de a atinge o setare

Dintr-un client cablat, testați trei ținte separat și notați fiecare rezultat: adresa LAN a routerului însuși, un alt dispozitiv din același switch după IP și ceva accesibil doar prin tunel. Faceți-le în această ordine, pentru că fiecare rezultat exclude un alt strat. Folosiți adrese în loc de nume la prima rundă, deoarece o eroare de nume amestecă DNS într-o întrebare de conectivitate.

Modelul răspunsurilor este diagnosticul. Un router care răspunde în timp ce dispozitivele locale nu o fac indică comutare locală sau o funcție de filtrare, nu rutare. Dispozitivele locale care răspund în timp ce partea de tunel nu o face indică ruta tunelului sau firewall-ul îndepărtat. Dacă totul răspunde după adresă, dar numele eșuează, este o întrebare de resolver, iar nicio editare de rute nu va rezolva asta.

Țineți tabelul lângă rezultatele testelor. Transformă o reclamație vagă într-o singură linie pe care puteți acționa.

Stratul de securitate din interiorul căii de forwardare

Routerele de consum includ tot mai des o funcție de inspecție care supraveghează traficul forwardat, iar aceasta rulează în aceeași cale care transportă pachetele din LAN în tunel. Când acea inspecție nu poate clasifica traficul tunelului, forwardarea se poate bloca în timp ce tunelul rămâne activ și routerul raportează o conexiune sănătoasă. Nimic din jurnalul VPN nu arată asta, pentru că VPN-ul chiar s-a conectat.

Diagnosticul este un experiment controlat, nu o schimbare permanentă. Notați setarea curentă, opriți funcția pe durata unui test, ridicați din nou tunelul și testați un singur host local după adresă. Forwardarea care revine este dovada de care aveați nevoie, iar compromisul devine atunci o decizie în loc de o presupunere. Dacă nimic nu se schimbă, reactivați-o imediat și treceți la cauza adresării.

A lăsa o funcție de securitate plătită dezactivată ca să funcționeze un tunel este un compromis care trebuie făcut deliberat și notat. Merită să întrebați și dacă tunelul ar trebui să fie pe alt dispozitiv, pentru că un router care trebuie să inspecteze tot și un router care trebuie să forwardeze tot sunt două munci diferite.

A doua cauză: intervalul LAN s-a mutat

Actualizările de firmware readuc frecvent adresa LAN la valoarea implicită a producătorului, iar unele routere au un comutator de mod explicit care decide dacă LAN-ul păstrează un interval privat sau moștenește unul de la echipamentul de deasupra. Un client care așteaptă 192.168.8.x poate ajunge pe 10.64.0.x, iar atunci o sesiune SSH către un host expiră deși tunelul este perfect sănătos.

ipconfig /all
ip addr show
ip route get 192.168.8.20

Citiți prefixul și gateway-ul din lease înainte de a deschide pagina routerului. Primele două comenzi arată ce a primit efectiv clientul, iar a treia arată ce interfață ar folosi clientul pentru o adresă locală, și așa se dezvăluie o rută rămasă sau o subrețea învechită. Apoi comparați cu pagina LAN și cu modul în care se află routerul.

Dacă intervalul nu poate reveni, actualizați fiecare obiect care îl numește: rezervări DHCP, orice rută statică în subrețeaua veche și fiecare regulă de firewall care poartă prefixul anterior. Un interval care se ciocnește cu subrețeaua îndepărtată a tunelului este varianta mai rea, pentru că dispozitivele locale rămân accesibile în timp ce destinațiile îndepărtate sunt direcționate silențios greșit în LAN.

Reconectați și retestați în ordinea pachetelor

După oricare dintre cele două schimbări, reconectați tunelul și repetați testele în ordinea pachetelor: router, host local, host îndepărtat, apoi nume, apoi aplicația. Testarea aplicației mai întâi ascunde ce strat este încă stricat, iar o reîncercare a browserului pe un nume din cache poate părea o defecțiune de rutare.

Notați versiunea firmware-ului, prefixul LAN și starea funcției de inspecție lângă profilul VPN. Toate trei sunt configurație pe care următoarea actualizare o poate suprascrie, iar două rânduri de note economisesc ora pe care tocmai ați petrecut-o.