Encaminador en mode client VPN: per què desapareixen els dispositius LAN
Els dispositius LAN desapareixen després que un encaminador entri en mode client VPN: proveu primer la funció d'inspecció del camí d'reenviament i després el rang LAN que el firmware ha canviat sota els vostres peus.
Creure que el mode client mateix mata l'accés a la LAN porta la gent al menú de configuració equivocat, i les causes reals solen ser dues. El túnel no elimina el pont LAN ni impedeix que els clients cablejats i sense fils arribin els uns als altres. El que trenca l'accés local és una funció d'inspecció al camí d'reenviament de l'encaminador o un rang d'adreces LAN que es va moure quan ho va fer el firmware. Tots dos produeixen la mateixa queixa, i cap no es resol reinstal·lant el perfil VPN.
El mite i què canvia realment el mode client
El mode client afegeix una interfície de túnel i una ruta per defecte que hi passa, i després reenvia el trànsit LAN cap a aquest túnel. El pont entre els ports cablejats i les ràdios sense fils queda intacte, igual que la commutació local. El que canvia és la política: quin trànsit es reenvia, on es tradueix i quin resolutor reben els clients.
Aquesta distinció importa perquè una LAN trencada normalment significa que una d'aquestes tres polítiques ha canviat, no que l'encaminador hagi deixat de ser un commutador. Un encaminador que encara respon la seva pròpia pàgina d'administració és prova que la interfície LAN és viva. Un encaminador que no respon res té un altre problema, com una adreça LAN canviada o un client a la subxarxa equivocada.
Així, el primer moviment útil és trobar quina capa s'ha trencat, no canviar la capa que sospiteu.
Proveu tres objectius abans de tocar cap configuració
Des d'un client cablejat, proveu tres objectius per separat i anoteu cada resultat: l'adreça LAN pròpia de l'encaminador, un altre dispositiu al mateix commutador per IP i una cosa només accessible pel túnel. Feu-ho en aquest ordre, perquè cada resultat descarta una capa diferent. Feu servir adreces en lloc de noms a la primera passada, ja que un error de nom barreja DNS amb una qüestió de connectivitat.
El patró de respostes és el diagnòstic. Un encaminador que respon mentre els dispositius locals no ho fan apunta a commutació local o a una funció de filtratge, no a encaminament. Els dispositius locals que responen mentre el costat del túnel no ho fa apunten a la ruta del túnel o al tallafoc remot. Tot responent per adreça mentre els noms fallen és una qüestió de resolutor, i cap edició de rutes ho arreglarà.
| What answers | What it points at |
|---|---|
| Router only | LAN-side filtering or a broken bridge |
| Router and local hosts, not remote | Tunnel route, NAT or remote firewall |
| Addresses yes, names no | DNS handed to clients by the router |
| Nothing at all | Client subnet or router LAN address changed |
Tingueu la taula al costat dels resultats de les proves. Converteix una queixa vaga en una línia sobre la qual podeu actuar.
La capa de seguretat dins del camí d'reenviament
Els encaminadors de consum cada cop inclouen una funció d'inspecció que observa el trànsit reenviat, i s'executa al mateix camí que transporta els paquets de LAN cap al túnel. Quan aquesta inspecció no pot classificar el trànsit del túnel, el reenviament es pot encallar mentre el túnel segueix actiu i l'encaminador informa d'una connexió sana. Res al registre VPN ho mostra, perquè la VPN sí que es va connectar.
El diagnòstic és un experiment controlat, no un canvi permanent. Anoteu la configuració actual, desactiveu la funció durant una prova, torneu a aixecar el túnel i proveu un sol amfitrió local per adreça. El reenviament que torna és la prova que necessitàveu, i llavors el compromís esdevé una decisió en lloc d'una conjectura. Si no canvia res, torneu-la a activar de seguida i passeu a la causa d'adreçament.
Deixar desactivada una funció de seguretat de pagament perquè el túnel segueixi funcionant és un compromís que cal fer deliberadament i anotar. També val la pena preguntar si el túnel pertany a un altre dispositiu, perquè un encaminador que ha d'inspeccionar-ho tot i un que ha de reenviar-ho tot són dues feines diferents.
La segona causa: el rang LAN s'ha mogut
Les actualitzacions de firmware sovint restableixen l'adreça LAN al valor per defecte del fabricant, i alguns encaminadors tenen un commutador de mode explícit que decideix si la LAN conserva un rang privat o n'hereta un de l'equip superior. Un client que espera 192.168.8.x pot acabar a 10.64.0.x, i llavors una sessió SSH a un amfitrió caduca tot i que el túnel és perfectament sa.
ipconfig /all
ip addr show
ip route get 192.168.8.20Llegiu el prefix i la porta d'enllaç de l'arrendament abans d'obrir la pàgina de l'encaminador. Les dues primeres ordres mostren què ha rebut realment el client, i la tercera mostra quina interfície faria servir per a una adreça local, que és com es revela una ruta sobrera o una subxarxa obsoleta. Després compareu-ho amb la pàgina LAN i el mode en què es troba l'encaminador.
Si el rang no pot tornar, actualitzeu cada objecte que el nomena: reserves DHCP, qualsevol ruta estàtica cap a la subxarxa antiga i cada regla de tallafoc que porti el prefix anterior. Un rang que xoca amb la subxarxa remota del túnel és la variant pitjor, perquè els dispositius locals segueixen accessibles mentre les destinacions remotes es desvien silenciosament cap a la LAN.
Torneu a connectar i repetiu les proves en ordre de paquets
Després de qualsevol dels dos canvis, torneu a connectar el túnel i repetiu les proves en ordre de paquets: encaminador, amfitrió local, amfitrió remot, després noms, després l'aplicació. Provar l'aplicació primer amaga quina capa encara està trencada, i un reintent del navegador contra un nom en memòria cau pot semblar una fallada d'encaminament.
Anoteu la versió del firmware, el prefix LAN i l'estat de la funció d'inspecció al costat del perfil VPN. Tots tres són configuració que la propera actualització pot sobreescriure, i dues línies de notes estalvien l'hora que acabeu de passar.