Por qué su servicio público de Linux responde a través de la VPN

Nada en el socket recuerda qué interfaz transportó la solicitud, así que una ruta predeterminada de VPN de túnel completo puede capturar una respuesta que pertenece a la WAN. El servicio no ignora la interfaz de entrada; Linux enruta una respuesta generada localmente según el destino y la política de origen. Una regla basada en el origen puede enviar solo las respuestas del servicio por una tabla WAN completa, dejando la salida ordinaria en el túnel. El puerto sigue abierto mientras la respuesta sale por la ruta equivocada, y por eso el síntoma parece unilateral.

La idea errónea: las respuestas siguen la interfaz por la que llegaron

Parece lógico que un paquete que llega por eth0 deba salir por eth0. Los filtros de paquetes sin estado pueden escribirse así, y tcpdump en el lado de entrada muestra la solicitud exactamente donde se espera. El enrutamiento no funciona así para el tráfico que origina el propio host.

Una vez que el servicio acepta la conexión, su respuesta es un nuevo paquete generado localmente. El núcleo consulta las reglas de enrutamiento para el destino y el origen de la respuesta, y la ruta predeterminada de la VPN es una respuesta perfectamente válida. Nada en el socket recuerda qué interfaz transportó la solicitud.

Por eso el síntoma parece unilateral: llegan solicitudes, desaparecen respuestas. Por eso también añadir una regla de cortafuegos para el puerto de entrada no cambia nada. El paquete no se bloquea a la entrada; se enruta a otro lugar a la salida. Siga la respuesta con una búsqueda cualificada por origen y el desvío se hace visible.

Lo que realmente enruta el núcleo: la dirección de origen

El asa que necesita es la dirección local que el servicio usa para las respuestas. En un host con la dirección eth0 ilustrativa 192.0.2.10/24 y la puerta de enlace 192.0.2.1, esa dirección está presente en la interfaz. En una VM en la nube, la dirección pública puede estar traducida aguas arriba y ausente en el invitado, así que use la dirección que el host realmente tiene.

Inspeccione el estado actual antes de reservar un número de tabla o una prioridad de regla. Las reglas de política existentes pueden eclipsar una nueva, y una tabla antigua con el mismo número puede ya llevar rutas no relacionadas:

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

Luego seleccione una tabla por origen. La regla coincide con las respuestas que ya llevan 192.0.2.10, exactamente el tráfico terminado localmente que quiere eximir. El tráfico reenviado y los paquetes de otras direcciones locales no coinciden.

Construya una tabla de retorno completa, no media ruta predeterminada

Una tabla con solo una ruta predeterminada no basta. El núcleo todavía tiene que resolver la puerta de enlace, y esa resolución necesita el prefijo conectado en la misma tabla. Una tabla a la que le falta ese prefijo falla en la resolución de la puerta de enlace aunque su ruta predeterminada parezca correcta. Añada ambas y luego apunte la regla de origen a la tabla:

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

Use el prefijo y la puerta de enlace reales en lugar de copiar el ejemplo. Una interfaz en la nube configurada como /32 con una puerta de enlace en el enlace necesita una ruta conectada distinta, y una tabla construida con el prefijo equivocado falla en el primer salto. El atributo src indica el origen preferido para esa ruta; no sustituye a la regla de origen.

El orden también importa. Una regla amplia con un número de prioridad más bajo se evalúa primero, así que la regla de origen debe alcanzarse antes que cualquier regla que devolviera este tráfico a la tabla principal. Compruebe las prioridades con ip rule show después de añadirla, no solo al arrancar.

Verifique con una búsqueda cualificada por origen

Pida al núcleo que enrute un destino de prueba desde la dirección del servicio. La respuesta debería nombrar eth0 y la puerta de enlace WAN, no el túnel:

ip -4 route get 198.51.100.25 from 192.0.2.10

Luego establezca una nueva conexión autorizada y observe ambas direcciones. Una búsqueda que selecciona la tabla correcta mientras la conexión real sigue fallando apunta al filtrado de ruta inversa o a una regla de cortafuegos, no a la tabla. Compruebe esos controles antes de desactivar nada globalmente.

Coloque las rutas finales y la regla bajo el gestor de red que posee la interfaz. Los cambios de dirección, la renovación de DHCP y las reconexiones de VPN reescriben todo el estado del núcleo, y una regla añadida a mano desaparece o apunta a una puerta de enlace obsoleta tras el siguiente evento.

Dónde se detiene esta excepción

La regla exime el tráfico terminado localmente de una dirección de origen. No cubre los puertos publicados por Docker, el DNAT ni los servicios reenviados a través del host, porque esos paquetes se enrutan como tráfico reenviado y nunca llevan el origen local del host de la misma manera. Esos diseños suelen necesitar una marca puesta en la entrada y una regla que coincida con la marca.

Tampoco hace que la dirección pública del host aparezca en la interfaz. Cuando un NAT aguas arriba posee esa dirección, la respuesta todavía tiene que salir por la ruta que ese NAT espera, y por eso la tabla WAN debe reflejar la puerta de enlace y el prefijo originales en lugar de un rango público adivinado.

Mantenga la excepción documentada con su número de tabla, la prioridad de la regla y la dirección de origen exacta. El próximo cambio en la VPN o en la interfaz puede romperla en silencio, y una nota que nombre los tres valores se comprueba más rápido que redescubrir el síntoma en un informe de cliente.

Si el servicio sigue respondiendo por la ruta equivocada después de que la búsqueda cualificada por origen pase, compare la dirección de origen del socket activo con la de la regla. Un servicio vinculado a una dirección comodín puede elegir un origen distinto de la dirección que probó, y esa discrepancia es la brecha restante.