Por qué una ruta de OpenVPN pierde ante una política XFRM de strongSwan

Los paquetes pueden seguir una ruta de OpenVPN y aun así ser capturados por una política IPsec, y esa combinación parece un error de enrutamiento desde todos los ángulos menos el correcto. Linux resuelve una ruta y luego consulta una base de datos de políticas de seguridad separada, así que una ruta de destino más específica no desplaza una política XFRM coincidente. El síntoma visible es tráfico que sale del host y nunca llega, mientras ambos túneles se declaran sanos. Tres opciones lo resuelven, y cuál elija depende de cuál de los dos caminos debe llevar ese prefijo.

Dos decisiones, no una

La selección de ruta responde una pregunta estrecha: qué siguiente salto y qué dirección de origen deben llevar este paquete. La base de datos de políticas de seguridad responde otra: ¿requiere este paquete protección IPsec y bajo qué selectores? Ambas se ejecutan para el mismo paquete, y satisfacer la primera no dice nada sobre la segunda. Por eso cambiar una métrica o añadir una ruta estática puede dejar el síntoma intacto.

Un selector IPsec amplio es la causa habitual. Una política que protege 172.16.0.0/12 también cubre 172.20.8.0/24, al que un administrador puede querer llegar por el túnel de OpenVPN. La intención solo existe en la tabla de enrutamiento, y la base de datos de políticas nunca la conoció.

Trátelo como un conflicto entre dos caminos de protección configurados y no como una competencia entre dos métricas. La corrección pertenece al componente que se configuró con el alcance equivocado.

Lea la ruta que el núcleo elige de verdad

Empiece por la consulta que hace el núcleo, incluida la dirección de origen y cualquier regla de política que pudiera desviarla a otra tabla. Una ruta de la tabla principal puede no consultarse nunca si una regla anterior elige otra tabla, y la coincidencia del prefijo más largo solo se aplica dentro de la tabla que elige una regla.

ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15

El último comando es el que importa, porque imprime la ruta elegida junto con la dirección de origen que el núcleo usaría. Compare esa salida con el selector con el que coincide la política IPsec. Cuando la ruta apunta a la interfaz de OpenVPN y la política sigue coincidiendo con el mismo par, ha reproducido el conflicto sin adivinar.

Mantenga los volcados libres de direcciones no relacionadas antes de que lleguen a un ticket. Una tabla de enrutamiento de un host de producción lleva topología interna, y solo las líneas que responden la pregunta merecen pegarse.

Lea la política que también se aplica

El listado de políticas muestra dirección, selectores y la plantilla que decide qué ocurre con un paquete coincidente. Lea primero la dirección de salida y luego el lado de entrada para el tráfico de retorno, porque una excepción unidireccional produce una conexión que empieza y nunca se completa.

ip -s xfrm policy
swanctl --list-sas

Compare los selectores del listado con los prefijos que negoció la conexión. Desactivar la instalación de rutas de strongSwan no elimina esas políticas, y cambiar una métrica no altera qué par de origen y destino protege una política. Esas dos falsas soluciones conviene descartarlas pronto porque son las primeras que la gente prueba.

Si el listado no contiene ninguna política para el prefijo que esperaba, el problema está en otro sitio y la tabla de enrutamiento probablemente dice la verdad. Si contiene una política más amplia que cubre el prefijo, ha encontrado la captura.

Tres opciones cuando ambos caminos son legítimos

Estrechar el selector IPsec es la opción más limpia cuando el prefijo amplio era una comodidad y no un requisito. Reducir el selector de tráfico remoto a las subredes que de verdad pertenecen detrás de IPsec elimina el conflicto para todos los hosts a la vez, y cuesta una renegociación de claves en vez de un componente nuevo.

Una excepción de paso directo es la opción quirúrgica cuando el selector amplio debe quedarse. strongSwan admite una conexión separada cuyo hijo usa el modo pass, que dice al núcleo que el tráfico coincidente no debe procesarse por IPsec. La dirección remota de loopback evita que esa conexión se elija para pares entrantes, y los selectores deben describir el par autorizado real y no todo.

connections {
    openvpn-exception {
        remote_addrs = 127.0.0.1
        children {
            openvpn-exception {
                local_ts = 10.44.7.0/24
                remote_ts = 172.20.8.0/24
                mode = pass
                start_action = trap
            }
        }
    }
}

Los ejemplos de configuración de strongSwan documentan este tipo de política y la convención de par de loopback. La tercera opción es un diseño basado en enrutamiento con interfaces XFRM, que ata la política al tráfico enrutado por una interfaz con nombre en lugar de a un selector global. Es una migración y no un ajuste, y el tráfico debe seguir satisfaciendo los selectores negociados.

Demuestre la excepción sin debilitar el resto

Después de cargar el cambio, pruebe la excepción y un destino corriente que deba seguir protegido. Compruebe ambos sentidos, luego baje el túnel de OpenVPN y confirme qué ocurre con el tráfico exceptuado. Una excepción que envía ese prefijo en claro en silencio cuando el túnel está caído es una decisión de política que conviene tomar a propósito, no descubrir durante un incidente.

Anote qué prefijo usa qué camino y por qué. Si no, el siguiente ingeniero que vea un selector amplio reabrirá la misma investigación, y la respuesta estará en un mensaje de commit que nadie lee.