Llegar a un cliente IKEv2 en su IP virtual asignada

Una puerta de enlace debe iniciar una conexión hacia un portátil conectado a ella por IKEv2, usando la dirección virtual asignada a ese cliente. El túnel está activo, el cliente llega a todo lo que hay detrás de la puerta de enlace y la dirección inversa sigue fallando. Esa asimetría es normal: la política negociada describe qué direcciones pueden hablar, no qué lado puede iniciar. Tres cosas deben alinearse antes de que funcione una petición iniciada por la puerta de enlace.

El túnel no corrige la dirección de origen

Una CHILD SA cubre un par de selectores de tráfico, uno por lado, y permite tráfico en ambas direcciones de ese par. No dice nada sobre qué par abrió primero el intercambio IKE. Una puerta de enlace que originalmente escuchaba el túnel todavía puede enviar el primer paquete de aplicación, siempre que el origen y el destino elegidos caigan dentro de los selectores instalados. Cuando la petición sale por la interfaz equivocada, sencillamente no es apta para el túnel.

El enrutamiento hacia el cliente es necesario y no suficiente. La política tiene que admitir el origen que realmente usaste.

Lee la política instalada, no el archivo de configuración

Empieza por la asociación activa y sus selectores, porque la asignación dinámica cambia lo que está instalado en el núcleo.

ipsec statusall
ip xfrm policy

La salida de estado nombra la conexión, la dirección virtual asignada y los selectores vigentes en este momento para ese par. El volcado de política muestra los mismos selectores como estado del núcleo, y es lo que consulta realmente la selección de paquetes. Compara el selector del lado de la puerta de enlace con el origen que usará tu aplicación, porque una discrepancia explica el fallo de inmediato. Lee la dirección actual del cliente y no una de una sesión anterior, porque una VIP reasignada invalida la política antigua.

El cliente debe escuchar donde llega el paquete

Incluso una política perfecta llega a un puerto cerrado cuando el servicio se enlaza solo a loopback. El oyente tiene que estar en la dirección asignada o en una dirección local comodín.

ss -ltnp 'sport = :9090'
iptables -S INPUT

El listado de sockets muestra si el puerto está enlazado a la dirección virtual, y las reglas del cortafuegos muestran si se aceptan conexiones nuevas desde el origen protegido. Una regla escrita para conexiones establecidas no admite una conexión que inicia la puerta de enlace. Conserva la autenticación propia del servicio, porque llegar por el túnel solo establece de qué red vino el paquete. Un cliente detrás de su propio NAT sigue sin necesitar redirección de puerto entrante, porque estas peticiones viajan dentro del túnel existente.

Prueba la nueva dirección por separado

Una petición correcta de cliente a servidor nunca recorre este camino. Genera la petición desde la puerta de enlace y observa ambos extremos.

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

La consulta de ruta responde qué origen e interfaz usaría la puerta de enlace, y ese es el valor que la política debe admitir. La captura debería mostrar la petición saliendo dentro de ESP y no como TCP plano en la interfaz pública. En el cliente, captura el tráfico descifrado para confirmar la llegada y si el servicio respondió. Si la petición desaparece sin ESP en el cable, sospecha de la dirección de origen antes que del cortafuegos del cliente.

Repite la prueba tras un cambio de claves o una reconexión, porque la VIP puede cambiar. Un camino que solo funciona hasta la próxima sesión no es un camino que funcione.