La misma IP de servidor, dos rutas: marcar el flujo exterior de OpenVPN

La protección de bucle habitual es una ruta de host: envía el tráfico hacia la dirección pública del servidor VPN por el enlace ascendente para que la sesión cifrada nunca entre en su propio túnel. Eso funciona justo hasta el momento en que también quieres llegar a un servicio web en ese mismo servidor a través del túnel, porque la exención está ligada al destino y el destino es idéntico. La salida es dejar de clasificar por destino y empezar a clasificar por qué socket envió el paquete.

Empieza por los dos flujos que quieres separar

Un flujo es el propio transporte OpenVPN cifrado, que tiene que salir por el enlace ascendente o el túnel llevaría su propia conexión exterior. El otro es una petición HTTPS corriente a la misma dirección pública, que quieres dentro del túnel para que llegue al servicio desde un origen de túnel. Mismo destino, en muchos casos mismo número de puerto, ruta necesaria distinta.

Para este recorrido, supón un cliente en 10.90.0.10 sobre tun1, una dirección pública de servidor de 198.51.100.25 y una tabla principal intacta cuya ruta predeterminada apunta al enlace ascendente habitual. El lado del servidor también tiene que aceptar el servicio web en la ruta interior y devolver el tráfico al origen del túnel; enviar un paquete a una dirección pública no anula el listener ni la política de firewall del servidor.

Antes de cambiar nada, captura las reglas actuales del host y elige valores que nadie más use: una marca, un número de tabla y tres prioridades de regla. Mantén una vía de vuelta a la máquina que no pase por esta conexión, porque un error aquí elimina tu propio acceso remoto en vez de solo romper una pestaña del navegador.

Marca el socket que lleva el sobre

La configuración del cliente gana una marca para sus paquetes cifrados de salida, y deja de instalar rutas por sí misma para que la política de sustitución sea lo único que decida las rutas:

mark 42
route-noexec
disable-dco

El decimal 42 es hexadecimal 0x2a, y la forma hexadecimal es la que harán coincidir las reglas de enrutamiento. La referencia de link-options describe mark como algo que se aplica a los paquetes cifrados de salida en Linux, que es exactamente el socket cuya ruta necesitas controlar. Desactivar la descarga del canal de datos mantiene este ejemplo en la ruta del espacio de usuario, donde el comportamiento de la marca es el que se describe.

route-noexec suprime las adiciones y eliminaciones automáticas de rutas de OpenVPN. No instala nada en su lugar, así que desde este momento el dueño de las rutas tiene que mantener todas las rutas que el túnel necesita. Si un destino privado desaparece tras el cambio, eso es la política de sustitución que falta, no un fallo en la marca.

No mantengas una ruta de host en la tabla principal para 198.51.100.25 mientras haces esto. Una ruta así reintroduce exactamente la exención que el diseño intenta estrechar, y ganará para el flujo HTTPS antes de que se consulte cualquiera de las políticas de abajo.

Envía todo lo demás a la tabla del túnel

Una vez que la interfaz del túnel existe y tiene su dirección, la política queda así:

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

La primera regla mantiene visibles las rutas específicas del host, incluida cualquier red local aprobada, mientras hace invisible la ruta predeterminada de la tabla principal para esta búsqueda. Esa distinción importa: suprimir la predeterminada no es lo mismo que ignorar la tabla, y las excepciones locales que aún necesitas sobreviven por eso. Lee esas excepciones una por una en vez de suponer que el resultado es un interruptor de parada universal.

El tráfico no marcado cae entonces en la tabla del túnel, toma el origen del túnel y sale por la VPN. El tráfico marcado falla la prueba fwmark en las dos reglas siguientes y continúa hacia la búsqueda principal habitual más abajo en la lista, donde sigue estando la predeterminada del enlace ascendente. La regla unreachable final es la que impide que un flujo no marcado caiga en silencio de vuelta al enlace ascendente cuando falta la ruta del túnel. El selector es la marca de principio a fin, y la dirección de destino nunca entra en la decisión.

Mantén esa guarda en su sitio entre desconexiones, e instálala con el resto de la política en vez de a mano. Una regla que desaparece con la interfaz no es una política, es una coincidencia. Borrar la política cuando cae el túnel cambia el modo de fallo de “bloqueado” a “filtrado”, y una ruta de túnel obsoleta que caduque después es un problema mucho más fácil de explicar que el tráfico que salió por la interfaz equivocada.

Haz que la ruta de vuelta vea la misma marca

Las marcas de salida son solo la mitad del mecanismo, y esta es la parte que la mayoría de las reproducciones omiten. Las respuestas a la sesión cifrada llegan por el enlace ascendente y están sujetas a la validación de ruta de vuelta, que pregunta si el origen enrutaría de vuelta por el mismo camino por el que vino. Sin ayuda, esa búsqueda aplica tu política de túnel no marcada y concluye que el paquete está en la interfaz equivocada.

La corrección pertenece al dueño del firewall: guarda la marca en la conexión de salida, restáurala en los paquetes entrantes correspondientes y activa el manejo de marcas validado por origen para la ruta pertinente. Que OpenVPN establezca una marca de socket no hace ninguna de esas tres cosas, y una receta que solo enumera las opciones del cliente está incompleta. Pide esa integración por escrito, porque es la parte menos visible del diseño y la más fácil de perder en una reconstrucción.

La comprobación laxa de ruta de vuelta tampoco es un sustituto. El modo laxo todavía necesita que exista alguna ruta para el origen, y la guarda unreachable que añadiste elimina deliberadamente una para las búsquedas no marcadas. Haz que la integración de la marca de conexión esté terminada y revisada antes de confiar en este diseño, y trata los filtros de host como una cuestión aparte: una marca es una señal de enrutamiento, no un permiso. Si falta la integración, el síntoma es una sesión que se establece y luego se queda en silencio en cuanto empiezan a llegar las respuestas.

Demuéstralo con dos búsquedas de ruta

Compara lo que decide el núcleo para los dos contextos, y lee los campos dev y src en vez del estado de salida:

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

La primera búsqueda debería resolver a tun1 con el origen del túnel, y la segunda al enlace ascendente. Son búsquedas sintéticas, así que prueban la política y no el proceso vivo: confirma la ruta de transporte real del cliente en ejecución por separado y luego haz una petición HTTPS real con la verificación de certificados activada.

Anota lo que el diseño no cubre antes de declararlo terminado. DNS, IPv6 y el ciclo de vida de las reglas necesitan cada uno su propia decisión, y esto es un ejemplo de enrutamiento IPv4 en vez de una configuración de privacidad completa. Su valor es el selector: el sobre recibe la exención del enlace ascendente, y un servicio normal en la misma dirección no tiene por qué heredarla.