Modo trap de strongSwan: por qué el túnel IPsec espera tráfico

No aparece ningún CHILD SA en la salida de estado, el túnel parece muerto y, de repente, un ping a la subred remota lo levanta. En una configuración IPsec bajo demanda esa secuencia es el diseño, no una avería. Una política trap instala un selector y espera, y el primer paquete que coincide con ella es lo que inicia IKE y la negociación del CHILD SA.

Parte de la confusión es de vocabulario: “up” se usa para dos estados distintos. La configuración está cargada y la política del kernel existe, pero la asociación de datos no. Un monitor que solo cuenta SA activas informará de un sitio sano como caído mientras nadie le envíe tráfico.

Un túnel inactivo bajo demanda no tiene ningún CHILD SA que mostrar

Una entrada trap no autentica nada por sí misma. Pide al kernel que mantenga una política para el tráfico seleccionado y que levante una acquisition cuando un paquete necesite esa política. El demonio recibe la acquisition, la empareja con la definición de child y negocia desde ahí. Hasta ese momento tampoco hay ninguna IKE SA que mostrar, por eso ambas listas pueden estar vacías a la vez.

Ese orden es lo que hace legibles los registros. Primero llega la acquisition, luego IKE_SA_INIT e IKE_AUTH, y luego el CHILD SA. Si el registro termina justo después de la acquisition, el disparador funcionó. La negociación falló, y la siguiente pregunta es sobre credenciales, propuestas o alcanzabilidad, no sobre el trap.

Con el backend del kernel Linux puedes ver la política antes de que exista ningún SA. Ejecuta ip xfrm policy y busca el selector con dirección out y una plantilla que apunte a la conexión. Esa entrada es el estado bajo demanda, y su presencia es lo primero que hay que confirmar.

start_action decide si algo espera siquiera

Cada child en swanctl.conf lleva un start_action. start se inicia cuando se carga la configuración, trap instala la política y espera, y none deja la iniciación a otra cosa. Solo trap produce el comportamiento de “ping y sube” descrito arriba.

children {
    office-lan {
        local_ts = 192.168.50.0/24
        remote_ts = 192.168.70.0/24
        start_action = trap
    }
}

Los dos selectores de tráfico definen qué cuenta como interesante, y un paquete de un host fuera de esos prefijos no dispara el trap; se enruta como de costumbre. Ampliar los selectores para que el disparador sea más ávido también amplía el alcance que el túnel dice proteger, así que derívalos del tráfico que realmente piensas cifrar.

La referencia de swanctl.conf enumera los valores aceptados, junto con las acciones separadas close y DPD que gobiernan qué ocurre una vez existe la SA.

Averigua si el disparador se activó

Empieza con swanctl --list-conns y confirma que el child está cargado con la acción que pretendías. Luego envía un paquete desde un host dentro de local_ts a una dirección dentro de remote_ts y observa swanctl --list-sas. Si la salida no cambia, ninguna acquisition llegó al demonio.

Dos motivos habituales de un trap silencioso: el paquete pasó por source-NAT antes de llegar a la política y ya no coincide con local_ts, o la conexión nunca se cargó por un error de sintaxis o de credenciales. Vuelve a ejecutar swanctl --load-all y lee su salida antes de tocar los selectores. Una conexión que no se cargó no instala política, así que no hay nada que el tráfico pueda disparar.

La dirección también importa: un trap instalado para tráfico saliente no se inicia con un paquete entrante. Si el lado remoto debe levantar el túnel, necesita su propio trap, o este lado necesita start.

Esperar el primer paquete no siempre es el intercambio correcto

Las sesiones interactivas notan el coste de la configuración. La primera petición paga el intercambio IKE y la negociación CHILD, y un cliente con poco margen puede rendirse antes de que exista la SA. Un start proactivo elimina ese retraso del primer paquete. Pero mantiene un túnel abierto para tráfico que quizá nunca llegue.

Tres hechos deciden la elección: con qué frecuencia se usa el camino, si la primera petición tiene un plazo ajustado y si el peer es alcanzable al arrancar. El tráfico por lotes ocasional y un peer que puede estar fuera de línea al arrancar favorecen ambos trap. Un cliente sensible a la latencia y un peer siempre alcanzable favorecen start. Si ambos lados pueden iniciar, acordad quién posee el disparador para no tener negociaciones duplicadas.

Una política instalada tampoco es una garantía a prueba de fugas. Si el requisito es fail-closed, el cortafuegos debe descartar el tráfico sin SA, y esa regla vive fuera de la definición de child.

Anota las tres líneas que cierran la próxima discusión

Escribe los selectores, la acción de arranque y la salida del comando que muestra la política presente sin SA. Esas tres líneas separan “bajo demanda e inactivo” de “no se carga” la próxima vez que alguien informe de que el túnel está caído. Cuestan un minuto de capturar. Sin ellas, la misma investigación vuelve a empezar de cero.

Prueba desde un host que esté realmente dentro del selector. Un ping desde el propio router suele seguir un camino distinto y no demuestra nada sobre la política que protege la subred que hay detrás.