IKEv2 no es un solo intercambio: IKE SA, autenticación y luego CHILD SA
Que la puerta de enlace responda demuestra alcance, no identidad. Sigue IKE_SA_INIT, IKE_AUTH y el primer CHILD SA, y luego comprueba qué debe cumplirse antes de que fluya el tráfico.
Puedes pensar que una conexión IKEv2 es un solo intercambio que termina con tu tráfico cifrado. Son al menos dos, y el primero no autentica a nadie. Los pares empiezan con mensajes de control, acuerdan parámetros criptográficos, demuestran identidad y solo entonces negocian el estado que transporta los paquetes de aplicación. Ese orden explica el desajuste que la gente reporta constantemente: la puerta de enlace responde, el cliente dice conectado y la aplicación privada sigue agotando el tiempo de espera. Esto es lo que hace realmente cada etapa y qué debe cumplirse después de ella.
El mito: si la puerta de enlace responde, estás conectado
Una respuesta al primer mensaje demuestra que el extremo es alcanzable y está dispuesto a hablar. No demuestra que se haya aceptado una cuenta, que se haya validado una cadena de certificados ni que se haya instalado alguna política de datos.
Esos fallos ocurren más tarde y producen síntomas distintos. El rechazo de un certificado o un fallo de EAP llega después de que el primer intercambio ya haya tenido éxito, y por eso un ping al UDP 500 y un icono verde en el cliente te dicen tan poco.
IKE_SA_INIT: acordar parámetros, no identidad
El primer intercambio lleva las propuestas para la asociación de seguridad IKE: algoritmos de cifrado e integridad, una función pseudoaleatoria y un grupo Diffie-Hellman. Los pares también intercambian nonces, y cada lado deriva el material de claves para el IKE SA a partir del secreto compartido que producen esos valores. Nada en este intercambio establece quién es la otra parte. Establece que ambos lados pueden calcular las mismas claves y que coinciden en una propuesta. Un respondedor al que no le gusta ninguna propuesta rechaza aquí el intercambio, y por eso un desajuste de versión o de algoritmo parece que el servidor está caído.
El IKE SA creado en este punto protege todos los intercambios de gestión posteriores. Esa es su tarea, y es una tarea distinta de proteger tus paquetes.
IKE_AUTH: demostrar identidad y luego construir el primer CHILD SA
El segundo intercambio lleva la identidad. Con certificados, cada par firma con su clave privada y presenta una cadena que el otro debe validar; con EAP, el respondedor desafía al iniciador mediante el método elegido. Aquí es donde por fin aparecen un nombre de servidor incorrecto, un certificado caducado o una contraseña rechazada.
En el caso normal, IKE_AUTH también negocia el primer CHILD SA, así que la protección de datos se acuerda en el mismo viaje de ida y vuelta. El iniciador propone selectores de tráfico, el respondedor los estrecha o los rechaza, y las claves para la ruta de datos se derivan del IKE SA. Eso significa que un solo intercambio puede fallar en dos lugares muy distintos: la identidad o la política. Lee la carga útil de notificación o el error en lugar del fallo genérico de negociación, porque la solución para uno es un certificado y la solución para el otro es un desajuste de subred.
Dos SA, dos trabajos
| Asociación | Protege | Comportamiento de la vigencia |
|---|---|---|
| IKE SA | Intercambios de gestión: recifrado de claves, borrado, cargas útiles de configuración | Se recifra según su propio calendario; la ruta de datos puede sobrevivir al cambio |
| CHILD SA | Tráfico de aplicación que coincide con los selectores de tráfico | Se recifra de forma independiente, a menudo con más frecuencia |
Mantenerlos separados explica dos comportamientos que parecen errores. Un túnel puede mostrarse establecido mientras un recifrado falla en segundo plano, y un CHILD SA puede reemplazarse sin que el cliente pierda la conexión.
En strongSwan, la referencia de configuración de IKEv2 y swanctl --list-sas muestran ambos niveles, y ip xfrm state más ip xfrm policy muestran lo que el núcleo instaló realmente. Comparar esas dos vistas es la forma más rápida de ver si la negociación terminó o solo lo pareció. Si el demonio lista un CHILD SA para el que el núcleo no tiene estado, la instalación falló en silencio. Si el núcleo mantiene estado que el demonio no conoce, estás viendo un resto de un intento anterior.
Qué debe seguir siendo cierto con el túnel levantado
Los selectores de tráfico definen qué direcciones quedan cubiertas. Si el cliente propone una subred y el servidor espera otra, el CHILD SA se instala pero no transporta nada útil, y el error aparece como un problema de enrutamiento y no de negociación. Después la pila local tiene que cooperar: reenvío habilitado donde el host enruta, rutas que apuntan al túnel, reglas de cortafuegos que permiten los paquetes desencapsulados y un resolutor interno si hay nombres privados implicados. Cada uno de esos falla por separado y ninguno se arregla reiniciando el demonio IKE.
Mantén el registro visible mientras diagnosticas: el intercambio inicial, luego la validación de identidad, después la autenticación de usuario cuando corresponda, a continuación la instalación del CHILD y por último el tráfico de aplicación. La etapa que se detiene es la que hay que corregir, y un fallo de enrutamiento posterior nunca es motivo para relajar las comprobaciones de identidad que ya pasaron.