Cliente VPN en un servidor LAN: por qué las respuestas salen por el camino equivocado

Los síntomas siguen una misma forma: un host funciona, luego se conecta a una VPN como cliente y ahora los clientes LAN lo alcanzan mientras sus respuestas desaparecen. Una captura en el host muestra que las respuestas salen por el dispositivo del túnel en lugar de la interfaz LAN. Nada del túnel está roto, y el arreglo es una ruta, no una reconexión. Recorra las cuatro comprobaciones siguientes en orden y deténgase en la primera que falle.

Una respuesta es un paquete nuevo, no una reversión

Ayuda descartar la idea de que una respuesta vuelve por el camino que tomó una petición. El enrutamiento se decide por paquete, por dirección, en el host emisor. Una petición que llegó de 10.64.0.23 dentro del túnel no crea ningún camino de retorno; cuando el host responde, esa respuesta se compara con la tabla como un paquete nuevo y sale por la ruta que gane.

Por eso un cliente de túnel completo en una máquina que también sirve una LAN produce un fallo tan confuso. El cliente instala una ruta predeterminada, o las dos medias rutas predeterminadas que prefieren algunos clientes, y la respuesta a un cliente LAN ahora coincide con el túnel. Va al proveedor, que no tiene motivo para reenviarla, y el cliente LAN ve un tiempo de espera pese a que el host está activo y responde en local. La captura lo hace obvio, y la tabla de enrutamiento lo explica.

Mantenga dos subredes en la cabeza mientras lee el resto. Una es el grupo de direcciones VPN del que vienen los clientes remotos, en este ejemplo 10.64.0.0/24. La otra es la LAN que debe seguir funcionando, 172.16.24.0/24 con su router en 172.16.24.1. El fallo es que el tráfico entre ellas lo decide la ruta predeterminada.

Demuéstrelo con la captura y la consulta

Antes de cambiar nada, confirme qué dispositivo usará la respuesta. Una consulta es más rápida que una captura y responde exactamente la pregunta que responderá el núcleo cuando se construya el paquete.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Lea la respuesta en dos partes. Si nombra dev tun0, el host encapsulará la respuesta y la entregará al proveedor, y el cliente LAN nunca la verá. Si nombra dev eth0 pero el cliente sigue agotando el tiempo, la ruta ya es correcta y el paquete se descarta más tarde, que es otro problema con otro arreglo.

La captura en el mismo paso resuelve la duda que un ping no puede. Un eco de respuesta que llega al cliente LAN demuestra que algún camino funciona, no qué interfaz lo llevó, así que haga la captura en el propio host y observe por dónde salen las tramas. Una impresora en la misma subred sigue respondiendo, porque su ruta directa es más específica que la ruta predeterminada del túnel. Un puerto reenviado falla igual que cualquier otro flujo, porque la tabla elige la interfaz y la conexión no.

Instale la ruta más específica que supere al túnel

Decide la longitud del prefijo, no la métrica, así que una ruta para el grupo de clientes a través del router LAN gana a cualquier ruta predeterminada que instale el cliente VPN. No hace falta cirugía de métricas, y la ruta predeterminada puede quedarse exactamente donde el cliente la puso.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Use replace en lugar de add, porque un cliente que se reconecte habrá instalado su propia entrada y un segundo add falla con un error de ruta existente que se lee como un problema de permisos. En un host Windows el equivalente es route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, donde -p mantiene la entrada entre reinicios, ya que el cliente puede reconstruir la tabla cuando el túnel vuelve a subir. En un host Windows actual el equivalente admitido es New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, con el comando route más antiguo conservado como forma heredada.

Un detalle decide si esto es correcto o solo verosímil: el siguiente salto tiene que ser el router que realmente posee el camino de vuelta a los clientes. Apuntar la ruta a una dirección a la que se llega justamente por el túnel crea un bucle que se manifiesta como pérdida intermitente en lugar de un fallo limpio. Confirme que el siguiente salto está en la subred LAN antes de confirmar la línea.

Mantenga la respuesta tras una reconexión

Una ruta añadida a mano sobrevive como mucho hasta la siguiente reconexión. Si el grupo de clientes es dinámico, fíjelo en la configuración del servidor para que el prefijo que enrutó siga siendo el prefijo que reciben los clientes; de lo contrario la entrada apunta a un rango vacío y el síntoma vuelve semanas después sin causa evidente. Escribir la ruta en el propio script up del cliente es la otra opción fiable, porque se ejecuta después de que el cliente haya reescrito la tabla.

Un cortafuegos con estado todavía puede vencer una ruta correcta. Si la captura ahora muestra que la respuesta sale por eth0 y el cliente sigue agotando el tiempo, compruebe si el host descarta el paquete antes de enviarlo. El filtrado estricto de ruta inversa y net.ipv4.conf.all.rp_filter puesto a 1 descartan paquetes cuyo origen no se enrutaría de vuelta por la interfaz por la que llegaron, que es exactamente el caso asimétrico que acaba de crear y luego corregir, y el estado de conntrack cuenta la misma historia para los puertos reenviados.

La última comprobación es la que la gente se salta: repita la consulta después de que el túnel haya bajado y vuelto a subir. Cuatro valores deben coincidir con lo que anotó: el destino, el siguiente salto, el dispositivo y el origen elegido. Si alguno se movió, el cliente reescribió la tabla y el arreglo pertenece a sus hooks y no al historial de una shell.