Encaminar solo un servicio web local fuera de la VPN según el puerto

Un servicio del host tiene que responder a internet por el enlace ascendente físico mientras todo lo demás de la máquina sigue usando el túnel. Tres condiciones deciden si el enrutamiento basado en políticas puede soportar esa carga, y cada una es barata de comprobar antes de escribir una regla. El servicio debe terminar en este host y no detrás de un DNAT o un puerto reenviado, las propias reglas de la VPN deben permitir la excepción, y hay que hacer coincidir la respuesta en lugar de la petición. Si falla cualquiera de las tres, los comandos de abajo se cargan sin errores pero no hacen nada útil.

Compruebe las tres condiciones antes de escribir una regla

Un contenedor que publica un puerto mediante DNAT, o un servidor detrás de un reenvío de puerto, genera paquetes que no se originan en este host. Esos paquetes se reenvían, así que una regla basada en la entrada local del host nunca los ve y el tráfico sigue tomando la ruta predeterminada. Confirme dónde se ejecuta realmente el servicio antes de continuar, porque es la condición que la gente suele acertar menos.

La segunda condición es política y no mecánica. Cualquier ruta que evite el túnel es una excepción al propósito del túnel, y en un host gestionado esa decisión corresponde a quien posee la política, no a quien depura un tiempo de espera.

Haga coincidir la respuesta, no el puerto de destino del cliente

La respuesta de un servidor que escucha en TCP 443 sale del host con el puerto de origen 443. Un navegador del mismo host que se conecta a un sitio HTTPS remoto envía un puerto de origen efímero y un puerto de destino 443. Ambos son tráfico del puerto 443 y solo uno debería usar la tabla WAN, por eso una coincidencia de puerto de destino atraparía la mitad equivocada.

La dirección de la respuesta es lo que puede distinguir. Haga coincidir el puerto de origen, limite la regla a paquetes generados localmente, y la regla cubre las respuestas del propio servicio sin tocar las peticiones del navegador.

Construya una tabla de retorno completa antes de que la regla apunte a ella

Una tabla vacía significa ninguna ruta, lo que parece un servicio roto más que una política rota. Rellénela primero, con un número de tabla y una prioridad que nada más en el host reclame:

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

Lea los números del host en vivo en lugar de copiarlos. ip -4 rule show le dice qué prioridades están ocupadas, y añadir una regla en una prioridad que ya existe cambia en silencio el orden de dos reglas que por separado parecen correctas.

Dos selectores hacen el trabajo real aquí. iif lo es cómo el núcleo informa de los paquetes que el host ha generado él mismo, así que la regla no puede capturar por accidente tráfico reenviado que llega de fuera. ipproto tcp sport 443 lo reduce a un transporte y un puerto, que es tan ajustado como el requisito permite. Quite el selector de protocolo y la regla también atrapará UDP 443, que es otro servicio con otro comportamiento.

Mantenga las respuestas privadas dentro del túnel

Si el mismo oyente también responde a clientes del lado privado, una ruta WAN predeterminada que lo atrapa todo en la tabla 100 intentará devolver esas respuestas por el enlace ascendente. Añada los prefijos privados que no deben seguir la ruta WAN predeterminada, o déjelos caer a la siguiente regla de política:

ip -4 route add table 100 throw 10.90.0.0/24

Una ruta throw termina la búsqueda en esta tabla y devuelve el paquete a la lista de reglas, así que la política VPN que sigue tiene su oportunidad. No encamina nada al túnel por sí misma, y si ninguna regla posterior tiene una ruta coincidente el paquete sigue fallando; verifique la política siguiente en lugar de suponer que el throw es una solución.

El filtrado de ruta inversa y las reglas del cortafuegos del host siguen aplicándose a la petición que llega. Mire sus veredictos reales antes de relajar la validación, porque una excepción de enrutamiento no hace que rp_filter acepte una ruta de retorno que considera imposible.

Pruebe TCP, luego QUIC, luego un reinicio

Abra una conexión desde un cliente externo autorizado y otra desde el lado privado, y luego inspeccione la búsqueda de respuesta con las direcciones y los puertos reales. Si la respuesta externa toma la tabla 100 y la privada no, la política hace lo que pidió.

HTTP/3 se sirve por UDP y una regla TCP no lo hará coincidir, así que un oyente QUIC necesita su propio selector o seguirá usando el túnel mientras HTTPS funciona. Persista las reglas que elija con el componente que posee la interfaz, y confírmelas tras una reconexión o una renovación de DHCP. Cuando un gestor competidor elimina una ruta en tiempo de ejecución tras un reinicio, eso es un problema de propiedad que hay que arreglar en el origen, no un motivo para añadir reglas NAT más amplias encima.