Router LAN más cliente VPN: dos dispositivos, dos tablas de rutas

Dos dispositivos reenvían el paquete y cada uno mantiene su propia tabla. El router LAN sabe que el prefijo remoto pertenece al cliente VPN, y el cliente VPN sabe cómo llegar a ese prefijo a través de su túnel. Configura solo la primera tabla y el paquete llega a una máquina que no tiene ninguna ruta coincidente, así que vuelve a salir por la predeterminada. Ese es todo el fallo, y desde el lado de la LAN parece un bucle de enrutamiento porque casi lo es.

Dibuja los dos saltos antes de tocar una ruta

Toma un diseño ilustrativo: hosts de la LAN en 192.168.50.0/24, el router ordinario en 192.168.50.1, un cliente dedicado en 192.168.50.15 y una LAN remota en 10.60.0.0/24 accesible solo a través del túnel que mantiene ese cliente. Ninguno de los dos rangos privados se solapa con el otro, y el túnel tiene su propio plan de direcciones.

Ambos rangos privados importan porque deciden qué dispositivo puede responder. El lado remoto verá llegar el paquete desde la dirección de túnel del cliente, y su respuesta tiene que encontrar un camino de vuelta a 192.168.50.0/24. Si solo se configura la dirección de salida, la petición puede funcionar mientras la respuesta desaparece.

Paso 1: apunta el router al cliente, no al túnel

En el router LAN, añade una ruta de destino cuyo siguiente salto sea la dirección LAN del cliente:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Ese registro dice «entrégalo a la máquina que puede hacer túnel». No dice nada sobre cómo se construye el túnel, y no sustituye a la ruta propia del cliente. En un router gestionado el equivalente vive en la página de rutas estáticas del dispositivo; en un router Linux pertenece a la configuración de la interfaz que posee la LAN, no a un shell que vas a cerrar.

Comprueba la respuesta del segundo comando. Si informa el cliente como gateway y la interfaz LAN como device, el primer salto es correcto y el trabajo restante está en la otra máquina.

Paso 2: dale al cliente una ruta propia del lado del túnel

El cliente ahora recibe un paquete para 10.60.0.0/24 y consulta su propia tabla. Si su configuración de túnel instaló una ruta para ese prefijo, el paquete continúa cifrado. Si no lo hizo, el paquete coincide con la predeterminada ordinaria y vuelve a 192.168.50.1, que lo envía otra vez al cliente.

Mira antes de añadir nada:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Una ruta de prefijo ausente en todas las tablas es el hallazgo que buscas. Añádela a través de la configuración propia del túnel, para que la próxima reconexión la reinstale; una ip route add manual desaparece con la sesión y hace que el fallo vuelva en el momento menos oportuno. El siguiente salto es la interfaz de túnel o la dirección que la VPN asigna como su par, según el cliente, y la dirección del par debería venir del perfil actual y no de una nota antigua.

El bucle, cuando ocurre, no es infinito en la práctica: el TTL baja en cada pasada y el paquete muere con un mensaje de tiempo excedido. Por eso un traceroute repetido puede sugerir un ciclo mientras un cliente que simplemente no reenvía descarta el mismo paquete en silencio.

Paso 3: permite el reenvío y elige la ruta de vuelta

Recibir y reenviar son permisos distintos. net.ipv4.ip_forward=1 en el cliente permite el tránsito a nivel de núcleo, y una regla de cortafuegos todavía tiene que permitirlo entre la interfaz LAN y el túnel. Una regla que permite el acceso a la página de gestión del propio cliente no permitirá el tránsito hacia la LAN remota, y la distinción es fácil de pasar por alto cuando el mismo host responde a pings localmente.

El lado remoto tiene el problema espejo. Debe saber que 192.168.50.0/24 es accesible a través de este cliente autenticado. Con OpenVPN eso normalmente significa una ruta por cliente empujada por la configuración del servidor, o un archivo específico del cliente en el servidor que declara la LAN detrás del cliente. Sin eso, la LAN remota o descarta la respuesta o la envía a su propia puerta de enlace predeterminada, que es internet.

La traducción de origen es la alternativa cuando el prefijo de la LAN no se puede anunciar. Una regla de masquerade con alcance en el cliente reescribe el origen a la dirección del túnel, y las respuestas vuelven entonces de forma natural. También oculta qué host de la LAN hizo la petición, y por sí sola no permite al lado remoto iniciar conexiones hacia dentro. Elige ese compromiso a propósito en lugar de añadir un masquerade global y descubrir el efecto secundario más tarde.

Paso 4: haz persistentes ambas decisiones y luego prueba la ruta real

Cada ruta tiene un dueño, y el dueño es la configuración que se regenera al arrancar o al reconectar. En el router puede ser una entrada de ruta estática; en el cliente puede ser el perfil VPN, NetworkManager o systemd-networkd. Verifica reconectando el túnel y reiniciando el cliente, y luego lee la tabla de nuevo en lugar de confiar en la edición.

Mantén intacta la ruta predeterminada que transporta la conexión exterior del túnel. Sustituirla para «simplificar» la configuración rompe la ruta cifrada antes de que ningún tráfico interior pueda usarla, y el síntoma es un túnel que nunca se restablece después del cambio.

Prueba desde un host LAN corriente, no desde el cliente, porque una petición originada en el cliente nunca ejercita el primer salto del router. Obtén un servicio que exista solo en la LAN remota y confirma el cuerpo de la respuesta, y luego mira los contadores o los registros del cliente para ver el tránsito. Un traceroute interior que muestra saltos privados demuestra el reenvío, no el cifrado: la ruta exterior es una observación aparte, y solo los contadores de la interfaz del túnel muestran qué salió por él.