El servidor web desaparece cuando se conecta el cliente VPN

Un servicio que desaparece en el momento en que se conecta un cliente VPN normalmente no está bloqueado, sino que responde por la interfaz equivocada. La petición llega a la tarjeta de red física, el demonio escribe una respuesta y la tabla de enrutamiento entrega esa respuesta al túnel, ya que el túnel ha asumido la ruta predeterminada. El cliente remoto nunca ve una respuesta a una conexión que abrió, así que espera y luego informa de un tiempo de espera agotado. Ninguna regla de cortafuegos interviene en esa secuencia.

El síntoma: peticiones adentro, respuestas por la puerta equivocada

La pista es una conexión entrante que falla mientras todo lo demás en el equipo funciona. Otra pista es un equipo accesible desde la LAN pero no desde internet, o uno que funciona hasta que el túnel se reconecta y entonces se detiene. En cada caso la dirección de ida se comportaba bien y la de vuelta no, lo que apunta a una asimetría de enrutamiento y no a una política.

Confírmelo observando adónde va la respuesta, no observando cómo llega la petición.

Capture a la vez en la interfaz física y en el dispositivo del túnel. Si la petición aparece en la interfaz física y la respuesta en el túnel, el diagnóstico está terminado. Una respuesta que no aparece en ningún sitio significa que el servicio nunca aceptó la conexión, lo que es una investigación aparte con una causa aparte.

Dos rutas predeterminadas y una decisión de enrutamiento

Un cliente que instala una ruta predeterminada añade una segunda entrada con una métrica mejor que la de la puerta de enlace de la LAN. Algunos clientes instalan en su lugar dos rutas de medio rango, que cubren el mismo espacio de forma más específica y ganan la búsqueda del mismo modo. Cualquiera de las dos técnicas deja que los paquetes salientes ordinarios elijan la interfaz del túnel.

Esa elección se hace solo por destino. El núcleo no pregunta de dónde vino un paquete salvo que una regla de política se lo indique. Así, la respuesta a una dirección pública de cliente se entrega al túnel, cuyo extremo remoto recibe un paquete con una dirección de origen que no posee y lo descarta o lo reenvía a un lugar inútil. En Linux, el filtrado estricto de ruta inversa también puede descartar la petición original antes de que su servicio llegue a verla, lo que desde fuera parece idéntico. Ambos síntomas vienen de la misma asociación ausente entre un flujo entrante y su respuesta.

El túnel se comporta correctamente en todo momento. Se le dijo que llevara la ruta predeterminada y hace exactamente eso.

Repare la ruta de vuelta sin romper el túnel

Existen tres formas duraderas de reparación, y la elección depende de cuánto del tráfico propio del equipo debe quedarse dentro del túnel. Excluir el destino o el puerto del servicio es el cambio más pequeño. El enrutamiento por política según el origen o la marca es el más preciso. La traducción de origen es la más burda y la más fácil de explicar dos años después.

Elija según lo que el equipo deba hacer, no según cuál fragmento encontró primero.

Excluir un destino encaja con un servicio de dirección pública estable, y atar el demonio a la dirección física en lugar de a todas las direcciones hace más segura esa exclusión. Una regla de política que elige una tabla por origen mantiene las conexiones propias del equipo dentro del túnel mientras devuelve las respuestas del servicio por la puerta de enlace WAN. Enmascarar las respuestas en la interfaz WAN llega al mismo camino a costa de ocultar la dirección del cliente de los registros del servicio. Un cambio improvisado de la ruta predeterminada es un diagnóstico y no una configuración, porque el cliente reescribe las rutas en cada reconexión.

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

Cuando el equipo también enruta para una LAN detrás de él

Un salto más afuera, la misma asimetría vuelve con más piezas móviles. El tráfico llega al router desde internet, se reenvía a un dispositivo interno, y el único camino de vuelta de ese dispositivo es el túnel, así que la respuesta llega al cliente original desde la dirección del propio proveedor. El seguimiento de conexiones se encuentra entonces con una respuesta de un flujo que no vio empezar, y la descarta. El cliente, mientras tanto, no ve absolutamente nada.

Dos cambios lo reparan: traducción de destino para que la conexión entrante llegue al dispositivo interno, y traducción de origen para que la respuesta de ese dispositivo parezca venir del propio router.

En el firmware del router la expresión habitual es una regla de política que fija el reenvío de puertos al lado WAN mientras el tráfico propio del router viaja por el túnel. Sin traducción de origen, esa respuesta se dirige al cliente externo y el dispositivo interno simplemente no tiene ruta hacia ella. Pruebe tres cosas por separado, porque fallan por razones distintas: una conexión que llega de fuera, una que origina el propio equipo y una consulta de nombre.