strongSwan ESP-in-UDP: cuando no hay ningún NAT que detectar

La detección de NAT responde a una pregunta: ¿han cambiado las direcciones o los puertos en tránsito? No responde si un cortafuegos permite el protocolo IP 50. Las puertas de enlace de sitio sin ninguna traducción aún pueden estar detrás de una política que descarta el ESP nativo, y ese requisito debe configurarse en lugar de descubrirse. El mecanismo es ESP-in-UDP, y es una decisión, no un recurso alternativo que aparezca solo.

La detección es aritmética sobre direcciones, no una sonda del cortafuegos

IKEv2 transporta cargas útiles de detección de NAT con hashes de las direcciones y los puertos de origen y destino. Cada lado compara lo que recibió con lo que ve localmente, y una discrepancia le dice que algo tradujo el paquete. Nada en ese intercambio comprueba si un enrutador intermedio reenvía el protocolo 50.

Merece la pena decir la consecuencia práctica sin rodeos. Un túnel que funcionaba con ESP nativo no descubrirá por sí solo un cortafuegos nuevo más restrictivo, y su siguiente intento falla en la etapa de datos mientras IKE sigue teniendo éxito. Verá asociaciones de seguridad IKE establecidas y ningún tráfico protegido, lo que parece un fallo de enrutamiento hasta que captura en el cable.

La encapsulación es, por tanto, una propiedad de la conexión que configura, no un resultado que los pares negocien a partir del comportamiento de la red.

Cómo cambia encap el intercambio

En un despliegue moderno de strongSwan gestionado mediante swanctl.conf, la opción encap = yes en la conexión influye en el intercambio de detección de NAT para que ambos pares usen encapsulación UDP para ESP. Los paquetes protegidos viajan entonces dentro de UDP, convencionalmente en el puerto 4500, y ambos extremos deben ponerse de acuerdo sobre esa disposición.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

Ese fragmento pertenece dentro de una definición de conexión real y no es un perfil de sitio completo. Mantenga las direcciones de los pares, la autenticación y los selectores de tráfico child que ya ejecuta; la única clave añadida cambia cómo se envuelven los datos protegidos, no qué protege.

La guía de strongSwan sobre NAT-traversal describe este comportamiento, incluida la interacción con el puerto flotante cuando se usa MOBIKE.

Use la opción que corresponde a su backend

strongSwan tiene dos backends de configuración, y la clave difiere entre ellos. Una swanctl.conf conexión toma encap, mientras que una ipsec.conf conexión heredada toma forceencaps. Meter la palabra clave de un backend en el otro produce una configuración que se carga sin queja y no cambia nada, lo cual es peor que un error.

Compruebe qué demonio se ejecuta realmente antes de editar nada. En muchas distribuciones existen ambos ficheros porque uno es un resto de una migración anterior, y el activo es el que arranca la unidad de servicio. Lea esa unidad en lugar de adivinar por las marcas de tiempo de los ficheros. Una comprobación de cinco segundos aquí evita horas probando una opción que nada ha cargado.

Aplique el cambio a través del propietario de la conexión y restablezca la asociación durante una ventana controlada. Un child ya instalado conserva su encapsulación actual hasta que se reemplaza, así que editar el fichero por sí solo no demuestra que la nueva disposición esté en uso.

Verifique los datos envueltos, no solo el puerto

Capture en la puerta de enlace mientras fluye tráfico protegido y luego compare eso con la propia visión de strongSwan:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

El ESP nativo aparece como protocolo IP 50 y no se parece en nada a UDP. El ESP envuelto aparece como datagramas UDP en 4500 cuya carga útil no es IKE. El tráfico IKE en ese mismo puerto no es prueba de encapsulación, porque MOBIKE puede mover IKE allí mientras la ruta de datos sigue siendo nativa, así que lea la carga útil, no el número de puerto.

Tenga en cuenta también la MTU de la ruta. La envoltura añade sobrecarga, y una ruta que transportaba ESP nativo puede necesitar ajustes cuando crezcan los paquetes. El manejo de ICMP necesario ya debería formar parte del diseño; la encapsulación no elimina esa dependencia.

Acepte el cambio cuando el tráfico nuevo de aplicaciones dentro del túnel sea visible en la captura como ESP envuelto en ambos extremos, y cuando el servicio interno y su ruta de retorno sigan funcionando. Cualquier cosa menos es una configuración que parece correcta en un fichero.