¿Rompe un cliente VPN en tu servidor web sus respuestas?

El sitio se carga desde un portátil en la misma red y agota el tiempo desde cualquier otro lugar, y el host también ejecuta un cliente VPN para su propio tráfico saliente. Esa combinación produce un fallo concreto: llega la conexión entrante, la respuesta sale por la ruta equivocada y el cliente de fuera nunca ve una respuesta. Ambas mitades aparecen en la misma captura de paquetes, así que el orden de los acontecimientos es la parte que merece la pena leer.

Una regla de enrutamiento basada en el origen suele corregir el síntoma. También suele eximir más tráfico que el sitio que la motivó, y esa es la parte que conviene entender antes de guardar la regla.

El síntoma: responde localmente y no desde fuera

Dentro de la red la respuesta no tiene que cruzar el túnel, así que la página carga y el servicio parece sano. Desde fuera, la petición llega al host y la respuesta se enruta hacia la VPN, donde el extremo remoto no tiene motivo para aceptarla. El navegador ve un tiempo de espera en lugar de un rechazo, que es la firma de una ruta de un solo sentido y no de un puerto cerrado.

Confirma la forma antes de cambiar el enrutamiento: el escucha está activo, la petición local tiene éxito y la petición externa no produce ninguna respuesta. Esas tres observaciones juntas apuntan a la ruta de retorno y no a la configuración del servidor web. Una asimetría tan limpia es más útil que cualquier línea de registro, porque descarta al escucha antes de que leas un solo mensaje de error.

Mantén abierta una ruta de administración independiente mientras trabajas. Una regla que rompe tu propia sesión SSH convierte una corrección de diez minutos en una visita física.

Qué hace coincidir realmente un selector de origen

En el enrutamiento de políticas de Linux, una regla como from 192.168.50.2 hace coincidir paquetes cuyo origen es esa dirección. No codifica el hecho de que el paquete continúa una conversación que entró por el router doméstico, y no sabe qué proceso lo creó. La dirección de ese ejemplo es ilustrativa; sustituye la dirección que tu host usa realmente. Trata la línea como una afirmación sobre direcciones y nada más.

Si la tabla seleccionada proporciona una ruta predeterminada ordinaria, cada paquete que lleve ese origen puede tomar la misma excepción. Otro servicio vinculado a la misma dirección la hereda, y una aplicación que se vincula deliberadamente a esa dirección también la hereda. La referencia de reglas de política enumera origen, destino, protocolo, puerto, marca y prioridad como selectores separados, lo que recuerda que el origen por sí solo es el más tosco de los disponibles.

La prioridad decide el resultado. Las búsquedas se ejecutan en orden y la primera tabla que produce un resultado puede terminar la búsqueda, así que una regla colocada demasiado pronto puede ocultar una ruta más específica que una tabla posterior habría proporcionado. Lee toda la lista ordenada en lugar de la única línea que añadiste. Una regla que nunca coincide no cuesta nada, mientras que una que coincide demasiado pronto cambia silenciosamente todo lo que hay detrás.

Comprueba la ruta de retorno y el tráfico que no pretendías

Lee las reglas y las tablas, y luego pregunta al núcleo qué ruta tomaría un par concreto de origen y destino. Probar desde el propio host no es lo mismo que probar desde fuera, así que haz ambas cosas.

ip rule show
ip route show table 100
ip route get 203.0.113.44 from 192.168.50.2
ss -ltnp '( sport = :443 )'

Después acepta una conexión externa nueva y, por separado, una petición que aún debe salir por la VPN. Si la segunda ahora sale directamente, la excepción es más amplia que el problema que estabas resolviendo, y la prueba que importa es la que no pensabas cambiar.

Una comprobación de dirección pública en un navegador solo informa de las peticiones que hizo ese navegador. No dice nada sobre las respuestas del servidor web, sobre la selección de origen de otra aplicación local ni sobre qué ocurre con el tráfico de gestión tras la siguiente reconexión de la VPN.

Decide cuán estrecha puede ser la excepción

Dos diseños son defendibles y deben elegirse deliberadamente. Si el host existe para publicar este servicio y su tráfico saliente no es importante, una dirección local dedicada con una política solo para WAN es un arreglo razonable siempre que aceptes todo el alcance. Si solo deben cualificar conexiones entrantes concretas, la selección de dirección es demasiado tosca y delante de ella corresponde un diseño consciente de las conexiones.

Registra el contrato en el que te apoyas: el mapeo público, la dirección del host a la que se entrega la petición y la ruta que se espera que tome la respuesta. Un servicio entrante publicado a través de un proveedor de VPN es un contrato distinto del publicado a través de un router doméstico, y una excepción copiada de un ejemplo suele ser errónea para el otro.

Persiste la política en el componente que posee el enrutamiento en lugar de pegar un comando en un archivo de inicio. El orden de las reglas, la limpieza tras un cambio de red y la repetición tras un reinicio tienen que sobrevivir, y un archivo de inicio no probado suele fallar en el momento en que no miras. Termina con el resultado de aceptación que puedas defender: un sitio publicado restaurado y un flujo no relacionado sin cambios.