El VPN bloquea la LAN local en Windows: ¿ruta o política del cliente?

Una impresora, un NAS o una máquina de desarrollo en su propio escritorio dejan de responder en el momento en que se conecta el VPN del trabajo. A veces un comando de ruta lo arregla en segundos; a veces la misma ruta es correcta y los paquetes desaparecen igualmente, lo que significa que está ante un problema distinto con un síntoma parecido. La decisión se reduce a tres preguntas, y hacerlas en el orden equivocado es la razón por la que la gente pasa una noche entera borrando y volviendo a añadir rutas.

Tres preguntas antes de cualquier comando

Primera: ¿hay una entrada para el prefijo local y apunta al adaptador físico? Segunda: ¿recibe el cliente un permiso o una denegación de red local de la puerta de enlace al conectarse? Tercera: ¿solo necesita acceso de salida a la LAN, o algo en internet también debe llegar a un servicio que se ejecuta en su máquina?

La primera pregunta separa un fallo de enrutamiento de un fallo de filtrado. La segunda dice si se permite que una corrección de ruta funcione. La tercera cambia la reparación: una ruta arregla el tráfico de salida, mientras que un servicio de entrada inalcanzable suele ser un problema de enlace del oyente y de camino de vuelta que una ruta empeora.

Pregunta primera: ruta, filtro o nombre

Lea la tabla antes de añadir nada. El índice de interfaz importa, porque cada comando de ruta de abajo está anclado a él:

route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetric

Una subred conectada directamente suele conservar una ruta en el enlace incluso con el túnel activo, así que puede existir una entrada y el tráfico puede fallar igualmente. Esa combinación es la firma de un filtro que se ejecuta después del enrutamiento, y es el caso en que una segunda ruta más específica no cambia absolutamente nada.

Pruebe por dirección y por nombre por separado. Si ping 192.168.1.50 responde y net view 192.168.1.50 no, la tabla de enrutamiento nunca fue el problema: el túnel cambió el resolutor y el nombre local ya no se resuelve. Añadir una ruta para eso es trabajo perdido.

Pregunta segunda: ¿permite la puerta de enlace el acceso a la LAN local?

Un cliente comercial instala más que rutas. Recibe una política al conectarse, y esa política puede incluir un permiso explícito de red local. En despliegues de Cisco IPsec la política de grupo lleva el ajuste de túnel dividido y un indicador aparte de acceso a la LAN local; la casilla del cliente es una solicitud que la puerta de enlace puede rechazar. En AnyConnect el perfil controla las listas de inclusión y exclusión del túnel dividido y el mismo permiso. En Windows RRAS los equivalentes son la opción de puerta de enlace predeterminada en el perfil más las rutas estáticas que asigna el servidor.

Cuando el indicador está desactivado, el comportamiento documentado es que el cliente bloquea el tráfico a la subred conectada directamente aunque exista una ruta válida y más específica. Es también por eso que las rutas que el cliente no posee pueden desaparecer segundos después de añadirlas: el cliente reconstruye el estado que se le dijo que construyera, no lucha contra usted.

El registro del cliente anota la decisión al conectarse, y leerlo es más rápido que cualquier experimento en la máquina. Si el registro dice que el acceso local está bloqueado, deténgase: ninguna corrección de línea de comandos sobrevive a eso, y los únicos caminos que quedan son un cambio de política, llegar al recurso por el túnel, o encerrar el cliente en una máquina virtual y dejar el anfitrión en la red local.

Pregunta tercera: ¿qué dirección necesita?

El tráfico de salida hacia un dispositivo cercano es una cuestión de enrutamiento. Apunte el prefijo de la LAN a la puerta de enlace local con una métrica lo bastante baja como para batir la ruta predeterminada del túnel:

route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -p

La segunda forma fija un solo dispositivo, que es lo que quiere cuando una dirección es todo el requisito. El equivalente netsh registra la misma decisión por nombre de interfaz en lugar de por índice:

netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistent

Los comandos de ruta fallan con El parámetro no es correcto cuando la dirección y la máscara no concuerdan, por ejemplo una dirección de host con una máscara /24. Use la dirección de red para una ruta de subred y una máscara de host para un solo host.

La entrada es distinta. Un servidor VNC o SSH en la misma máquina se vuelve inalcanzable cuando las respuestas a una conexión entrante salen por la puerta de enlace del VPN y nunca regresan. Compruebe en qué escucha el servicio antes de tocar las rutas:

netstat -ano | findstr :5900

Un oyente ligado a una dirección concreta no responderá en la otra interfaz. Ligarlo a todas las interfaces es una decisión deliberada, tomada junto con una regla de cortafuegos limitada a la red en la que confía. Solo después de eso la reparación de la ruta restaura el camino de vuelta.

Aplique el cambio más pequeño que encaje

El otro movimiento habitual es desmarcar «Usar puerta de enlace predeterminada en la red remota» en las propiedades avanzadas de IPv4. Mantiene el tráfico de internet local, pero hace dos cosas a la vez: el VPN deja de ser el camino predeterminado y el cliente deja de recibir rutas para la red remota, incluido el multicast. Desmárquelo y la LAN remota desaparece a menos que el servidor empuje los prefijos remotos concretos que cada cliente necesita.

Esa asimetría decide el orden del trabajo. Si el lado remoto debe seguir siendo plenamente alcanzable, empuje las subredes remotas desde el servidor y deje en paz la predeterminada local. Si no puede cambiar el servidor, añada una ruta persistente al prefijo remoto a través de la dirección que asignó el túnel, y compruebe con route print que el prefijo apunta a la interfaz del VPN mientras la predeterminada sigue apuntando a la puerta de enlace física.

Luego confirme que la reparación sobrevive a una reconexión, porque las rutas no persistentes mueren con el adaptador y un script que se ejecute después de cada conexión es el lugar honesto para ellas. Pruebe un dispositivo local y un recurso remoto en la misma sesión, desconecte, reconecte y pruebe otra vez. Si el dispositivo local sigue fallando mientras la ruta parece correcta, vuelva a la pregunta segunda: el cliente está filtrando, y la respuesta es un cambio de política y no una segunda ruta competidora.