¿IPsec con varias subredes pierde el tráfico de vuelta? Cuente los reqid

El tráfico sale de un sitio y nunca vuelve, ambas puertas de enlace informan de una negociación completada, y la única pista es un montón de paquetes salientes sin respuestas. En un extremo Linux, la causa habitual no es la fuerza del cifrado, la MTU ni una tabla de rutas. Es la granularidad de las entradas de política y el número que une cada política a una asociación de seguridad. El procedimiento siguiente lee esas dos bases antes de tocar cualquier otra cosa.

Separe el síntoma antes de cambiar nada

Un fallo en un solo sentido con una negociación IKE completada reduce el problema a la ruta de datos. O la política de salida coincidía y la respuesta se descartó, o la respuesta nunca llegó porque el otro lado no tenía por dónde enviarla. Desde una aplicación ambos casos se ven igual, y las bases xfrm los distinguen.

No empiece por la MTU. Una MTU incorrecta produce bloqueos y síntomas de fragmentación, no una separación limpia de dirección con contadores de salida que suben.

Lea la base de políticas y la base de estados

En Linux el cifrado lo deciden las entradas de política, así que una política coincidente, no una ruta, es lo que mete un paquete en el túnel. Ejecute ip xfrm policy para ver los selectores, la dirección, la prioridad y la plantilla de cada entrada, y ip xfrm state para ver las asociaciones establecidas con sus reqid. La política y la asociación se unen por ese reqid.

Mire las tres direcciones. Salida y entrada cubren el tráfico hacia y desde este host; la dirección de reenvío importa cuando el host enruta para otros. Una entrada ausente o discordante en una dirección explica un resultado en un solo sentido sin ninguna falla criptográfica.

La asimetría clásica: un reqid para varias subredes

Un fallo frecuente viene de un par que instala políticas para todas las subredes negociadas bajo un único reqid, lo que ocurre con generate_policy require de racoon. El tráfico sale entonces por la asociación establecida en último lugar, mientras el otro lado mantiene una asociación distinta por subred. Las respuestas llegan por una asociación cuyo reqid no identifica la política que debería aceptarlas, y el núcleo las descarta tras el descifrado.

La solución es un cambio de configuración, no una regla de cortafuegos: generate_policy unique; da a cada política su propio reqid, de modo que las asociaciones por política del par tengan parejas correspondientes. Aplíquelo, renegocie y cuente los reqid distintos de las subredes esperadas antes de declarar el éxito.

Si dos subredes siguen compartiendo un reqid mientras el otro lado espera dos, ha encontrado la asimetría. Anote la correspondencia, porque es la prueba de que el siguiente cambio la corrigió o la conservó.

Los selectores vienen de la negociación, no de su configuración

Los rangos protegidos son lo que ambos extremos acordaron, no lo que pidió una de las partes. Un cliente que ofrece un par de hosts frente a un rango remoto amplio recibe la versión restringida de la puerta de enlace, y el cliente no puede ampliarla. Lea los selectores instalados en lugar de los de su archivo local.

Cuando el objetivo es lo contrario, mantener un destino fuera del túnel, añada una política de omisión con un número de prioridad más bajo para que gane a la entrada instalada automáticamente. Una política sin plantilla permite texto en claro, lo que la convierte en una excepción deliberada para un registro de cambios en vez de un paso de depuración.

Verifique en este orden, y sepa cómo revertir

Liste las políticas de cada subred en ambas direcciones, incluida la de reenvío si el host enruta. Cuente los reqid distintos y confirme uno por política en el lado que lo espera. Compare los selectores instalados con los negociados. Vuelva a leer los contadores por asociación tras una renovación de clave, porque la asociación inspeccionada puede haber desaparecido ya. Compruebe las rutas al final, ya que una ruta ausente hacia la subred remota produce un síntoma similar en un solo sentido con contadores de política limpios.

Antes de cambiar el par, guarde la salida actual de ambos comandos xfrm. Si el nuevo ajuste no restaura la dirección de vuelta, restaurar esa salida es una reversión más rápida que reconstruir el túnel de memoria, y mantiene honesta la comparación.