Router en modo cliente VPN: por qué desaparecen los dispositivos LAN
Los dispositivos LAN desaparecen después de que un router entra en modo cliente VPN: prueba primero la función de inspección de la ruta de reenvío y luego el rango LAN que el firmware cambió bajo tus pies.
Creer que el modo cliente por sí solo mata el acceso a la LAN lleva a la gente al menú de configuración equivocado, y las causas reales suelen ser dos. El túnel no elimina el puente LAN ni impide que los clientes cableados e inalámbricos se alcancen entre sí. Lo que rompe el acceso local es una función de inspección en la ruta de reenvío del router o un rango de direcciones LAN que se movió cuando lo hizo el firmware. Ambos producen la misma queja, y ninguno se arregla reinstalando el perfil VPN.
El mito y qué cambia realmente el modo cliente
El modo cliente añade una interfaz de túnel y una ruta predeterminada que apunta por ella, y luego reenvía el tráfico LAN a ese túnel. El puente entre los puertos cableados y las radios inalámbricas queda intacto, igual que la conmutación local. Lo que cambia es la política: qué tráfico se reenvía, dónde se traduce y qué resolución reciben los clientes.
Esa distinción importa porque una LAN rota normalmente significa que una de esas tres políticas cambió, no que el router dejara de ser un conmutador. Un router que sigue respondiendo su propia página de administración es prueba de que la interfaz LAN está viva. Un router que no responde nada tiene otro problema, como una dirección LAN cambiada o un cliente en la subred equivocada.
Así que el primer movimiento útil es averiguar qué capa se rompió, no cambiar la capa que sospechas.
Prueba tres objetivos antes de tocar un ajuste
Desde un cliente cableado, prueba tres objetivos por separado y anota cada resultado: la dirección LAN del propio router, otro dispositivo en el mismo conmutador por IP y algo accesible solo a través del túnel. Hazlo en ese orden, porque cada resultado descarta una capa distinta. Usa direcciones en vez de nombres en la primera pasada, ya que un fallo de nombre mezcla DNS en una cuestión de conectividad.
El patrón de respuestas es el diagnóstico. Un router que responde mientras los dispositivos locales no lo hacen apunta a conmutación local o a una función de filtrado, no a enrutamiento. Los dispositivos locales que responden mientras el lado del túnel no lo hace apuntan a la ruta del túnel o al cortafuegos remoto. Todo responde por dirección mientras los nombres fallan es una cuestión de resolución, y ninguna edición de rutas lo 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 |
Mantén la tabla junto a los resultados de las pruebas. Convierte una queja vaga en una línea sobre la que puedes actuar.
La capa de seguridad dentro de la ruta de reenvío
Los routers de consumo incluyen cada vez más una función de inspección que vigila el tráfico reenviado, y se ejecuta en la misma ruta que transporta los paquetes de LAN al túnel. Cuando esa inspección no puede clasificar el tráfico del túnel, el reenvío puede atascarse mientras el túnel sigue activo y el router informa de una conexión sana. Nada en el registro VPN lo muestra, porque la VPN sí conectó.
El diagnóstico es un experimento controlado, no un cambio permanente. Anota el ajuste actual, desactiva la función durante una prueba, vuelve a levantar el túnel y prueba un solo host local por dirección. El reenvío que vuelve es la prueba que necesitabas, y entonces el compromiso se convierte en una decisión en lugar de una conjetura. Si nada cambia, vuelve a activarla de inmediato y pasa a la causa del direccionamiento.
Dejar desactivada una función de seguridad de pago para que el túnel siga funcionando es un compromiso que se hace deliberadamente y se anota. También vale la pena preguntar si el túnel pertenece a otro dispositivo, porque un router que debe inspeccionarlo todo y un router que debe reenviarlo todo son dos trabajos distintos.
La segunda causa: el rango LAN se movió
Las actualizaciones de firmware suelen devolver la dirección LAN al valor predeterminado del fabricante, y algunos routers tienen un interruptor de modo explícito que decide si la LAN conserva un rango privado o hereda uno del equipo superior. Un cliente que espera 192.168.8.x puede acabar en 10.64.0.x, y entonces una sesión SSH a un host caduca aunque el túnel está perfectamente sano.
ipconfig /all
ip addr show
ip route get 192.168.8.20Lee el prefijo y la puerta de enlace del arrendamiento antes de abrir la página del router. Los dos primeros comandos muestran lo que el cliente recibió realmente, y el tercero muestra qué interfaz usaría el cliente para una dirección local, que es como se revela una ruta sobrante o una subred obsoleta. Luego compáralo con la página LAN y el modo en que está el router.
Si el rango no puede volver, actualiza cada objeto que lo nombra: reservas DHCP, cualquier ruta estática hacia la subred antigua y cada regla de cortafuegos que lleve el prefijo anterior. Un rango que choca con la subred remota del túnel es la variante peor, porque los dispositivos locales siguen accesibles mientras los destinos remotos se desvían silenciosamente hacia la LAN.
Reconecta y vuelve a probar en orden de paquetes
Después de cualquiera de los dos cambios, reconecta el túnel y repite las pruebas en orden de paquetes: router, host local, host remoto, luego nombres, luego la aplicación. Probar la aplicación primero oculta qué capa sigue rota, y un reintento del navegador contra un nombre en caché puede parecer un fallo de enrutamiento.
Anota la versión del firmware, el prefijo LAN y el estado de la función de inspección junto al perfil VPN. Los tres son configuración que la próxima actualización puede sobrescribir, y dos líneas de notas ahorran la hora que acabas de pasar.