¿Red local inaccesible con la VPN conectada? Cuatro comprobaciones

El túnel se levanta, la intranet aparece y la impresora deja de responder. Nada de la red local ha fallado; el cliente ha cambiado la ruta que usa para las direcciones que ya no considera locales. Recorre las cuatro comprobaciones siguientes en orden y detente cuando una produzca una discrepancia concreta, porque el mismo síntoma tiene cuatro causas habituales y solo una se arregla editando la VPN.

Primero, mira la tabla de rutas que instaló el cliente

Abre la tabla de rutas del cliente mientras la VPN está conectada. En Linux usa ip route, en Windows route print o Get-NetRoute, y en macOS netstat -rn. Buscas una ruta predeterminada a través del túnel y qué ha pasado con la ruta predeterminada física.

Un cliente de túnel completo suele añadir dos rutas medias predeterminadas, 0.0.0.0/1 y 128.0.0.0/1, en lugar de sustituir 0.0.0.0/0. La ruta predeterminada original sigue visible pero pierde todas las consultas, y por eso la tabla puede parecer intacta mientras todo el tráfico fuera de la subred se mueve. Si el cliente VPN ofrece una opción de túnel dividido y la política lo permite, esa es la reparación más limpia.

Si el túnel debe seguir siendo la ruta predeterminada, fija la subred local. En Linux la ruta nombra la interfaz física y la puerta de enlace; en Windows añade -p para hacerla persistente y lee el número de interfaz de route print en lugar de adivinarlo:

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

Una ruta fijada solo aguanta mientras la dirección que nombra siga igual. Un portátil que renumera su adaptador Wi-Fi en cada conexión volverá a romper la regla, así que comprueba la dirección de la interfaz antes de decidir que la reparación ha fallado.

Segundo, confirma que la dirección era local desde el principio

Si el destino está dentro de la subred conectada, la ruta predeterminada del túnel nunca se aplica y la VPN no es la causa. Una impresora en 192.168.1.40 en un cliente con 192.168.1.0/24 usa la ruta conectada; si esa dirección falla, mira el dispositivo, el conmutador o el cortafuegos del cliente en lugar de la VPN.

El caso que engaña a la gente es una dirección pública para un servidor local. Desde dentro de la red local, llegar a la dirección WAN del router y volver requiere NAT de horquilla, y muchos routers simplemente no lo implementan para redirecciones de puerto. Prueba la dirección privada junto a la pública. Si la privada funciona y la pública no, la VPN solo ha dejado al descubierto una limitación de NAT que ya estaba ahí.

Un nombre de host lo empeora. Si el nombre local ahora resuelve a la dirección pública, el cliente seguirá intentando la ruta que no puede volver. Usa la dirección privada para la prueba y luego arregla el nombre en lugar de añadir otra redirección de puerto.

Tercero, mira quién responde a los nombres ahora

Un resolutor corporativo conoce la intranet y normalmente nada sobre un nombre de host NAS, el nombre Bonjour de una impresora o el alias local de un router. Cuando la VPN empuja sus servidores DNS, esos nombres dejan de resolverse aunque sus direcciones sigan siendo accesibles. Consulta el nombre directamente y compara la respuesta con la dirección que sabes que tiene el dispositivo.

En Linux, resolvectl query nas.local muestra qué resolutor respondió. En Windows, nslookup nas.local nombra el servidor y ipconfig /all muestra el orden de los resolutores. Si el sufijo local ahora lo gestiona el resolutor corporativo, o redirige ese sufijo al resolutor local o usa la dirección IP del dispositivo.

El descubrimiento es una capa aparte. mDNS y la difusión no cruzan un túnel enrutado, así que un dispositivo puede ser accesible por dirección mientras su nombre sigue invisible. Un reflector o una entrada DNS local lo resuelve; una ruta no.

Cuarto, comprueba si la otra máquina también está en una VPN

Cuando la máquina a la que quieres llegar también ejecuta un cliente VPN, tu sesión puede llegar mientras su respuesta sale por el otro túnel. Eso produce una conexión que se establece y luego se atasca, o un intento de RDP y SSH que expira sin ningún error por tu parte. Revisa la tabla de rutas del otro host y su ruta predeterminada antes de culpar a tu cliente.

Comprueba también la dirección en la que escucha el servicio. Un escucha ligado solo a la dirección del túnel acepta conexiones de la VPN y las rechaza de la red local, incluso cuando el enrutamiento es perfecto. Eso es configuración del servicio, no una ruta de red, y es habitual en interfaces de gestión que se cerraron a la dirección de la VPN.

Mantén una ruta de gestión que no dependa del túnel: una ruta estática que nombre tu red de origen, otra interfaz conectada a la red local o una consola que evite el túnel por completo. Diseñar esa ruta después de que caiga la sesión es mucho más difícil que añadirla antes de la siguiente conexión.

Aplica la reparación que corresponde a la comprobación que falló

Si la tabla de rutas mostró una captura de media predeterminada, elige túnel dividido cuando la política lo permita y una ruta local fijada cuando no. Si la dirección resultó ser pública, cambia la prueba y el nombre a la dirección privada. Si el resolutor cambió de manos, limita el sufijo local o usa la dirección. Si el otro host está en un túnel, arregla su ruta de vuelta o la vinculación de su escucha.

Cambia una cosa y luego repite la misma comprobación. Una ruta añadida para la subred equivocada, un sufijo de resolutor con una errata y una ruta fijada en una interfaz que se renumera parecen todos el fallo original. La repetición es lo que separa una reparación de una casualidad.

Anota la ruta, la dirección y el resolutor que funcionaban con la VPN conectada. La próxima reconexión cambiará al menos uno de ellos, y la nota convierte la próxima avería en una comparación corta en lugar de una investigación nueva.