Cómo se traslada la autenticación híbrida de IKEv1 a la autenticación de usuarios de IKEv2

Todo perfil VPN heredado que pide un certificado de servidor y después un nombre de usuario encierra dos acontecimientos de autenticación en un solo intercambio, y esa forma sobrevive al protocolo que la introdujo. El modo híbrido de IKEv1 se creó justo para esto: la pasarela se identifica con una clave pública y el usuario lo hace más tarde mediante XAuth. IKEv2 expresa la misma idea en dos pasos con mecanismos distintos, y esas diferencias son donde fallan las migraciones. Ningún número de versión convierte uno en otro, y copiar los nombres de opción antiguos a un perfil nuevo produce un cliente que negocia y luego no autentica nada.

Qué hacía el modo híbrido dentro de IKEv1

En un perfil híbrido el respondedor firma el intercambio de la fase uno con su certificado mientras el iniciador no presenta ninguno a propósito. La prueba de identidad es, por tanto, asimétrica, y eso permitió a una pasarela conservar su PKI existente mientras los usuarios conservaban sus contraseñas de directorio. Cuando termina la fase uno, XAuth se ejecuta como una petición y una respuesta que llevan los atributos de usuario y contraseña dentro del canal ISAKMP ya cifrado.

Fíjese en dónde recae la confianza. El certificado responde a qué pasarela llegó el cliente; XAuth responde a qué usuario quiere acceso. Ninguno sustituye al otro, y un cliente configurado para aceptar cualquier certificado de servidor ha descartado en silencio la primera respuesta. La etiqueta híbrida también se usa para el modo agresivo con clave precompartida más XAuth, una disposición distinta con la misma experiencia de usuario, así que lea el perfil y no el nombre. Ambas variantes proceden de borradores que nunca llegaron a ser estándares, y por eso dos fabricantes pueden implementar el modo híbrido y no interoperar con ninguno.

Cómo llega IKEv2 a esas dos pruebas

IKEv2 reparte el trabajo entre IKE_SA_INIT e IKE_AUTH. El primer intercambio acuerda propuestas y claves sin identidad alguna; el segundo lleva IDi, IDr y las cargas AUTH. Bajo EAP la primera carga AUTH del iniciador sale vacía, el respondedor se autentica primero con su certificado y su firma, y la conversación EAP corre después dentro de los mensajes IKE_AUTH.

El mecanismo que lo hace seguro es el material de claves. Un método EAP correcto exporta una clave de sesión, y la carga AUTH final del iniciador se calcula a partir de ella, de modo que la prueba del usuario y las claves del túnel quedan ligadas. XAuth no tiene equivalente: sus atributos llegan después de la fase uno y no aportan nada a las claves. Esa laguna es justo lo que el marco de IKEv2 se diseñó para cerrar, y por eso un inicio de sesión IKEv2 que funciona valida el certificado del servidor antes de pedir nada.

Este orden también sirve de diagnóstico. Cuando un cliente se queja de las credenciales antes de haberle mostrado un certificado, no está haciendo un intercambio EAP de IKEv2 en absoluto.

Mantenga separadas tres identidades

Una migración se estropea cuando tres identidades se funden en un solo campo. Está la identidad de la pasarela que valida el cliente, normalmente un nombre DNS en el sujeto o en el SAN del certificado. Está la identidad del usuario que se presenta en EAP, que puede ser un inicio de sesión de dominio, una dirección o una cadena de identidad EAP explícita. Y está la fuente de autorización que asigna ese usuario a redes y rutas.

La sintaxis swanctl de strongSwan hace visible la separación: la conexión fija remote { auth = pubkey } para la pasarela y local { auth = eap-mschapv2 } para el usuario, y la identidad EAP viaja aparte.

Cuando la identidad de usuario del perfil nuevo difiere de los atributos XAuth antiguos, por ejemplo un UPN en lugar de un nombre corto, el servidor de autenticación ve un usuario desconocido y el fallo parece una contraseña incorrecta. Compruebe la cadena de identidad antes de comprobar la credencial.

Asigne las opciones y espere las trampas

La correspondencia es corta y cada fila tiene una trampa que solo aparece en el momento de la autenticación.

Ninguna de esas filas es un simple cambio de nombre. La carga de configuración entrega direcciones y resolutores mediante una lista de atributos tipados, mientras que el espacio de atributos de XAuth fue invento propio; tratarlos como intercambiables es cómo un perfil acaba pidiendo un ajuste que la pasarela nunca enviará.

Los selectores de tráfico merecen su propia advertencia. IKEv1 expresaba el tráfico interesante mediante identificadores de proxy ligados a un intercambio de modo rápido, mientras que IKEv2 negocia los selectores durante IKE_AUTH y el respondedor puede estrecharlos. Un desajuste produce una IKE SA establecida sin SA hija, que algunos clientes muestran como conectada sin más.

Trate la conexión antigua como una frontera

El RFC 9395 declara obsoleto IKEv1, así que una conexión híbrida heredada es una frontera de compatibilidad con fecha, no un cimiento. Ejecute ambos perfiles en paralelo durante el cambio, porque la prueba que importa no es si el perfil nuevo arranca, sino si el mismo usuario en el mismo dispositivo llega a los mismos recursos.

Mantenga estricta la validación de certificados de principio a fin. En cuanto el cliente deja de presentar su propio certificado, la tentación es relajar la comprobación del servidor hasta que el handshake termine, y eso cambia la única prueba que queda por un icono verde.

Anote cuatro cosas antes de retirar el perfil antiguo: el método EAP, la cadena de identidad, la fuente de autorización y la fecha en que termina el soporte.