Por qué un servidor detrás de un cliente VPN responde por el túnel

Las conexiones entrantes a un host que también ejecuta un cliente VPN fallan de una forma muy concreta: el handshake llega, el demonio responde y el cliente no recibe nada de vuelta. Nada bloquea el puerto. La respuesta salió por el túnel, porque el túnel posee la ruta predeterminada y el núcleo enruta las respuestas por destino, no por el recuerdo de dónde vino la petición. El demonio está bien y el puerto está abierto.

La respuesta se enruta, no se recuerda

Un cliente VPN que instala una ruta predeterminada añade una entrada que supera a la puerta de enlace LAN, ya sea por métrica o dividiendo el espacio en dos mitades más específicas. Los paquetes salientes ahora eligen la interfaz del túnel. El núcleo nunca pregunta de dónde llegó originalmente el paquete que se está respondiendo. Esa única omisión explica todos los síntomas que siguen.

La dirección de ida se enruta por destino, y la de vuelta también. La respuesta se dirige a un cliente público, que el túnel llevará gustoso. El extremo remoto recibe un paquete cuyo origen no posee, lo descarta, y el cliente original espera hasta que se agota el tiempo.

El filtrado estricto de ruta inversa puede descartar el paquete entrante antes de que el demonio lo lea. Comprueba ese contador primero, porque un descarte por filtro y un error de enrutamiento se ven idénticos desde fuera.

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

El primer comando muestra qué ruta predeterminada gana ahora. El segundo informa si el filtrado estricto se aplica globalmente o por interfaz, y el tercero muestra cualquier regla de la cadena de reenvío que pueda estar implicada.

Tres formas de conservar el camino de vuelta

Excluir el destino del servicio del túnel es la opción más estrecha. Una ruta de host apuntada a la puerta de enlace LAN, más un demonio vinculado a la dirección física en lugar de a todas las direcciones, mantiene ese único flujo fuera del túnel. El cambio es local y fácil de revertir.

El enrutamiento por políticas es la respuesta general. Una regla basada en la dirección de origen o en una marca de firewall elige una tabla cuya ruta predeterminada apunta a la puerta de enlace WAN, mientras las conexiones propias del host siguen usando el túnel. Mantén la prioridad explícita para que la regla no quede eclipsada más adelante.

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

Los dos primeros comandos construyen el camino alternativo para las respuestas con origen en la dirección pública. El tercero pregunta al núcleo qué camino tomaría exactamente ese origen y destino, y así confirmas que la regla tiene algún efecto.

La traducción de origen es la tercera opción y la única que sobrevive a un router que ya hace NAT delante del servicio. La respuesta tiene que volver a ese router, y el enmascaramiento hacia la interfaz WAN lo consigue mientras oculta al cliente de los registros del servicio. Sustituir la ruta predeterminada a mano tras conectarse es un diagnóstico, porque el cliente reescribe la tabla en la próxima reconexión.

Cuando la máquina también enruta para una LAN

El mismo fallo aparece un salto más allá cuando el host enruta para los dispositivos que tiene detrás. Una conexión entrante se reenvía a un dispositivo interno cuya única ruta de vuelta es el túnel, y la respuesta llega al cliente externo desde la dirección del proveedor. El dispositivo interno funciona correctamente todo el tiempo.

El seguimiento de conexiones ve entonces una respuesta de un flujo que nunca registró y la descarta. La traducción de destino entrega la conexión entrante al dispositivo, y la traducción de origen hace que la respuesta parezca originarse en el propio router.

Una ruta de política que mantiene el puerto reenviado en la WAN mientras el tráfico propio del router usa el túnel es el equivalente más limpio. Sin traducción de origen la respuesta se dirige al cliente externo, y el dispositivo interno no tiene ninguna ruta para esa dirección.

Tres sondeos que separan las causas

Ejecuta tres sondeos: una conexión hacia la máquina desde internet, una conexión desde ella a un host público y una consulta de nombre. Cuando los dos primeros discrepan, el camino de vuelta es el culpable. Cuando los nombres fallan en ambos sentidos, el resolutor es otro fallo que solo comparte el túnel.

Arregla primero la cuestión de enrutamiento, luego mira los nombres. Mezclar ambos es como se culpa a un servidor que funciona de un resolutor roto.

Anota qué interfaz nombra la excepción y mantén la configuración bajo control de versiones. Una regla escrita contra una interfaz que se renombra tras una actualización pasa hoy y falla tras el próximo reinicio.