Router en modo cliente VPN: por que desaparecen os dispositivos LAN
Os dispositivos LAN desaparecen despois de que un router entre en modo cliente VPN: proba primeiro a función de inspección da ruta de reenvío e despois o rango LAN que o firmware cambiou baixo os teus pés.
Crer que o modo cliente por si só mata o acceso á LAN leva a xente ao menú de configuración equivocado, e as causas reais adoitan ser dúas. O túnel non elimina a ponte LAN nin impide que os clientes con cable e sen fíos se alcancen entre si. O que rompe o acceso local é unha función de inspección na ruta de reenvío do router ou un rango de enderezos LAN que se moveu cando o fixo o firmware. Ambos producen a mesma queixa, e ningún se arranxa reinstalando o perfil VPN.
O mito e o que cambia realmente o modo cliente
O modo cliente engade unha interface de túnel e unha ruta predeterminada que apunta por ela, e despois reenvía o tráfico LAN a ese túnel. A ponte entre os portos con cable e as radios sen fíos queda intacta, igual que a conmutación local. O que cambia é a política: que tráfico se reenvía, onde se traduce e que resolución reciben os clientes.
Esa distinción importa porque unha LAN rota normalmente significa que cambiou unha desas tres políticas, non que o router deixase de ser un conmutador. Un router que segue respondendo a súa propia páxina de administración é proba de que a interface LAN está viva. Un router que non responde nada ten outro problema, como un enderezo LAN cambiado ou un cliente na subrede equivocada.
Así que o primeiro movemento útil é descubrir que capa se rompeu, non cambiar a capa que sospeitas.
Proba tres obxectivos antes de tocar un axuste
Desde un cliente con cable, proba tres obxectivos por separado e anota cada resultado: o enderezo LAN do propio router, outro dispositivo no mesmo conmutador por IP e algo accesible só a través do túnel. Fai o nesa orde, porque cada resultado descarta unha capa distinta. Usa enderezos en vez de nomes na primeira pasada, xa que un fallo de nome mestura DNS nunha cuestión de conectividade.
O patrón de respostas é o diagnóstico. Un router que responde mentres os dispositivos locais non o fan apunta a conmutación local ou a unha función de filtrado, non a encamiñamento. Os dispositivos locais que responden mentres o lado do túnel non o fai apuntan á ruta do túnel ou á devasa remota. Todo responde por enderezo mentres os nomes fallan é unha cuestión de resolución, e ningunha edición de rutas o arranxará.
| 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 |
Mantén a táboa xunto aos resultados das probas. Converte unha queixa vaga nunha liña sobre a que podes actuar.
A capa de seguridade dentro da ruta de reenvío
Os routers de consumo inclúen cada vez máis unha función de inspección que vixía o tráfico reenviado, e execútase na mesma ruta que transporta os paquetes de LAN ao túnel. Cando esa inspección non pode clasificar o tráfico do túnel, o reenvío pode atascarse mentres o túnel segue activo e o router informa dunha conexión sa. Nada no rexistro VPN o mostra, porque a VPN si conectou.
O diagnóstico é un experimento controlado, non un cambio permanente. Anota o axuste actual, desactiva a función durante unha proba, volve levantar o túnel e proba un só host local por enderezo. O reenvío que volve é a proba que necesitabas, e entón o compromiso convértese nunha decisión en lugar dunha conxectura. Se nada cambia, volve activala de inmediato e pasa á causa do enderezo.
Deixar desactivada unha función de seguridade de pago para que o túnel siga funcionando é un compromiso que se fai deliberadamente e se anota. Tamén paga a pena preguntar se o túnel pertence a outro dispositivo, porque un router que debe inspeccionalo todo e un router que debe reenvialo todo son dous traballos distintos.
A segunda causa: o rango LAN moveuse
As actualizacións de firmware adoitan devolver o enderezo LAN ao valor predeterminado do fabricante, e algúns routers teñen un interruptor de modo explícito que decide se a LAN conserva un rango privado ou herda un do equipo superior. Un cliente que espera 192.168.8.x pode acabar en 10.64.0.x, e entón unha sesión SSH a un host caduca aínda que o túnel está perfectamente sa.
ipconfig /all
ip addr show
ip route get 192.168.8.20Le o prefixo e a porta de enlace do arrendamento antes de abrir a páxina do router. Os dous primeiros comandos mostran o que o cliente recibiu realmente, e o terceiro mostra que interface usaría o cliente para un enderezo local, que é como se revela unha ruta sobrante ou unha subrede obsoleta. Despois compárao coa páxina LAN e o modo en que está o router.
Se o rango non pode volver, actualiza cada obxecto que o nomea: reservas DHCP, calquera ruta estática cara á subrede antiga e cada regra de devasa que leve o prefixo anterior. Un rango que choca coa subrede remota do túnel é a variante peor, porque os dispositivos locais seguen accesibles mentres os destinos remotos se desvían silenciosamente cara á LAN.
Reconecta e volve probar en orde de paquetes
Despois de calquera dos dous cambios, reconecta o túnel e repite as probas en orde de paquetes: router, host local, host remoto, despois nomes, despois a aplicación. Probar a aplicación primeiro oculta que capa segue rota, e un reintento do navegador contra un nome en caché pode parecer un fallo de encamiñamento.
Anota a versión do firmware, o prefixo LAN e o estado da función de inspección xunto ao perfil VPN. Os tres son configuración que a próxima actualización pode sobrescribir, e dúas liñas de notas aforran a hora que acabas de pasar.