Cómo el tránsito por NAT envuelve el ESP dentro de UDP

Dos clientes detrás del mismo router hablan con una sola pasarela IPsec, y uno no deja de caerse mientras el otro se mantiene. El ESP nativo es el protocolo IP 50 sin puertos, así que un traductor no tiene dónde anclar una asignación cuando varios clientes comparten una dirección. El tránsito por NAT cierra esa brecha envolviendo el ESP en UDP en el 4500, y esa cabecera explica la mayoría de los síntomas que siguen. También señala el dispositivo que hay que cambiar.

Por qué el plano de datos se traslada al puerto 4500

Durante la configuración, IKEv2 compara las direcciones y los puertos que cada lado cree usar, intercambiando hashes en sus notificaciones de detección de NAT. Cuando los hashes no coinciden, hay un traductor en algún punto de la ruta, y ambos pares cambian el tráfico protegido a encapsulación UDP. Por eso una sesión que se topó con un traductor se ve distinta de una que no.

El envoltorio es un sobre, no un cambio de protocolo: El ESP conserva su cabecera, su comprobación de integridad y su cifrado, y UDP solo aporta los puertos que el traductor necesita. El puerto 500 lleva el intercambio IKE; el 4500 lleva los datos encapsulados tras la detección, y a menudo también los mensajes IKE posteriores. Ninguno de los dos puertos convierte el flujo en una conexión TCP, una suposición que engaña a la mayoría de quien lee una captura.

Compruebe las dos etapas en orden

Demuestre primero el intercambio de control, luego la ruta de datos, y mantenga ambos separados en sus notas. Una captura que muestra tráfico en el 500 y nunca en el 4500 suele significar que la ruta de datos está filtrada, así que la corrección corresponde a la regla del cortafuegos y no al cliente.

Vigile ambos puertos con tcpdump -ni any 'udp port 500 or udp port 4500', y lea la tabla de traducción del router mientras la sesión está activa. Esa tabla muestra el puerto de origen que la pasarela verá realmente, y una captura en el portátil discrepa por diseño: el portátil cree 500 mientras la pasarela ve 4500 con un puerto de origen traducido, y ambos tienen razón. El mismo flujo, antes y después de la traducción:

client 192.0.2.10:500 -> router 203.0.113.7:62000 -> gateway 198.51.100.9:4500

Síntomas que explica el envoltorio, y dos que no

Un router que permite el intercambio de control y bloquea los datos encapsulados produce el informe de que el túnel está levantado pero no pasa nada. Las tablas de asignación caducan, así que una sesión inactiva necesita tráfico de mantenimiento que los pares envían a propósito, y esos paquetes no son comprobaciones de estado. Cuando varios clientes detrás de una pasarela fallan a la vez, examine la traducción de esa pasarela y cualquier función antigua de paso directo. El envoltorio no explica una aplicación que falla en todos los clientes tras levantar el túnel, ni un aviso de certificado en una página de bloqueo; ambos viven por encima de esta capa.

Lea la tabla de asignación para dos clientes a la vez: si ambos muestran el mismo puerto traducido, el dispositivo no los separa como exige la pasarela. Un modo de paso directo que entrega el ESP nativo a un solo equipo no equivale a servir a varios clientes traducidos, aunque los fabricantes describan ambos como compatibles con IPsec. El NAT doble añade una capa de asignación y otro punto de caducidad, pero no rompe automáticamente las conexiones salientes.

El tráfico de mantenimiento merece su propia línea en el manual de operaciones, porque es lo que mantiene abierta la ruta de respuesta durante los periodos de inactividad. Actívelo donde el fabricante lo documenta, y compruébelo primero cuando una sesión muere tras minutos de silencio en lugar de en el primer uso.

Cambie el propietario de la asignación y vuelva a probar

Siga los ajustes de tránsito por NAT admitidos en ambos pares en lugar de adivinar un puerto. Editar el puerto de origen local en un cliente no puede cambiar el servicio que escucha en el otro extremo, y normalmente rompe la asignación ya construida. Si el cliente está detrás de un dispositivo que usted no controla, el cambio corresponde a su propietario.

Tras cualquier cambio, repita ambas comprobaciones de etapa y confirme que un paquete de datos atraviesa, no solo que la pantalla de estado se puso verde. Guarde las tuplas, la salida de la tabla de asignación y el cambio de regla en una sola nota, para que la siguiente persona no empiece de nuevo desde el intercambio de control. Las notas de strongSwan sobre el tránsito por NAT cubren los ajustes de encapsulación y de mantenimiento tras ambas etapas.