El intercambio IKEv2 funciona y luego falla la autenticación: dónde

Un cliente que recibe una respuesta IKEv2 ha demostrado que la puerta de enlace es alcanzable, que ambas partes pueden negociar una propuesta y que el intercambio inicial de claves se completó. No ha demostrado que nadie esté autenticado. El siguiente intercambio lleva identidades, certificados o EAP, y ahí suele detenerse la conexión. Leer cuál de esas comprobaciones falló es todo el diagnóstico, y el mensaje de error por sí solo rara vez lo dice.

Comprobación 1: lea la etapa, no el mensaje

Un rechazo puede venir de tres lugares: el cliente rechaza la identidad del servidor, la puerta de enlace rechaza la prueba del cliente y un servicio de autenticación externo rechaza la cuenta.

Cada uno produce una línea de registro distinta en una máquina distinta, y cada uno tiene una solución distinta. Un rechazo del certificado del servidor por parte del cliente es un problema de confianza o de nombre en el cliente; un rechazo del certificado del cliente por parte de la puerta de enlace es un problema de confianza en la puerta de enlace; un fallo de EAP es un problema de cuenta o de backend. El mensaje que ve suele ser el resumen del cliente de uno de esos, por eso el registro de la puerta de enlace importa tanto como el del cliente.

Comprobación 2: qué identidad se comprobó

Un cliente puede rechazar el certificado del servidor o la identidad esperada antes de que se ofrezca cualquier credencial de usuario, y una dirección de servidor que funciona no sustituye esa comprobación. El identificador que el cliente espera debe coincidir con lo que presenta la puerta de enlace, lo que es un hecho de configuración y no de red.

En términos de strongSwan eso es rightid en el cliente y la identidad propia de la puerta de enlace en el otro lado, y una discrepancia falla antes de que se hable de EAP.

La puerta de enlace, por separado, puede rechazar el certificado del cliente, su prueba de clave o la autenticación de su cuenta, y esas tres cosas no son intercambiables. Restablecer la contraseña de un usuario no renueva el certificado de un dispositivo, y reinstalar el certificado de un dispositivo no arregla una identidad de servidor equivocada. En fallos de certificado, mire primero el reloj, luego la cadena de confianza, luego el identificador esperado; un cliente cuyo reloj va unos minutos desviado falla una comprobación de validez que parece un fallo de confianza. swanctl --list-certs en ambos extremos muestra qué tiene realmente cada parte.

Comprobación 3: si hay EAP de por medio

El cliente y el servidor deben acordar un método admitido, y el backend debe aceptar la identidad que se entrega.

Un nombre de usuario puede necesitar un sufijo de dominio o un formato de cuenta concreto que exige el despliegue, y el formato está documentado, no se adivina. Aportar los campos documentados por el operador es más rápido que probar variantes, y evita un segundo problema: los intentos repetidos pueden activar el bloqueo de la cuenta, que luego oculta la etapa original tras un fallo nuevo. Si el método es EAP-MSCHAPv2 contra un directorio, el fallo puede ser del directorio y no de la VPN.

No pruebe los problemas de identidad desactivando las comprobaciones de identidad. Eso convierte un fallo diagnosticable en uno indiagnosticable y deja la conexión más débil que antes.

Comprobación 4: qué pasa tras un inicio de sesión correcto

Una vez completado IKE_AUTH, la negociación de CHILD_SA decide qué selectores de tráfico se instalan, y ahí es donde una conexión puede tener éxito y no pasar nada.

Un inicio de sesión que acaba de funcionar suele revelar un problema de selector o de ruta que antes quedaba oculto tras el fallo de autenticación. Si el túnel sube y una aplicación sigue sin llegar a su destino, mire los selectores negociados y las rutas, no la identidad otra vez. Cambiar la configuración de identidad en ese punto apunta a la etapa equivocada y normalmente rompe un inicio de sesión que funciona. Confírmelo con swanctl --list-sas, que muestra los hijos y sus selectores por separado del IKE SA.

Comprobación 5: qué entregar al soporte

Una cronología saneada y el rechazo exacto valen más que una exportación de diagnóstico completa, y la exportación puede contener claves privadas o credenciales que no debería compartir.

Anote la hora con la zona horaria, las versiones de cliente y puerta de enlace, el método, la cadena de identidad que se ofreció y no la contraseña, y la etapa exacta que lo rechazó. documentación de configuración de IKEv2 de strongSwan describe los ajustes de identidad y EAP que deciden estos resultados, y es la referencia que hay que leer antes de cambiar un campo. Después cambie una cosa y vuelva a probar una conexión nueva, porque una sesión en caché le hablará de la configuración antigua.