¿EAP o certificados de cliente? Decidir la autenticación IKEv2

Su puerta de enlace puede demostrar su propia identidad con un certificado mientras demuestra la suya mediante EAP, y esa combinación es habitual, no contradictoria. Los dos mecanismos responden preguntas distintas: ¿es este extremo el que espero?, ¿está permitido este usuario o dispositivo? Ver EAP en un perfil no desactiva la validación del servidor. Leer el perfil como un único ajuste es lo que lleva a la gente a restablecer la credencial equivocada.

Determine qué afirmación falló antes de tocar cualquiera de los dos objetos. La etapa del fallo se lo dice, si la lee en orden.

Dos credenciales, dos afirmaciones

Un certificado de servidor vincula un nombre a una clave, y el cliente comprueba esa vinculación contra su almacén de confianza. Un certificado de cliente vincula una identidad a una clave, y la puerta de enlace comprueba que el certificado presentado encadene con algo en lo que confía. EAP transporta un intercambio de autenticación cuyo contenido depende del método elegido. Son tres estructuras con vidas útiles distintas, propietarios distintos y modos de fallo distintos.

Una frase de contraseña que desbloquea una clave privada no es una contraseña de cuenta, incluso cuando ambos avisos aparecen con segundos de diferencia. Una es local al almacén de claves del dispositivo, y la otra la valida un servidor de autenticación detrás de la puerta de enlace.

EAP es un contenedor, no un método

EAP es un marco: la puerta de enlace y el cliente negocian un método, y el método decide si intervienen una contraseña, un token, un intercambio interno tunelizado o un certificado, como expone la documentación de strongSwan sobre IKEv2. Por eso EAP-TLS no se parece en nada a EAP-MSCHAPv2 desde el lado del cliente, aunque ambos aparecen como EAP en un menú. Un perfil que solo nombra EAP no le ha dicho qué se le pedirá al usuario.

Lea el método y el backend juntos. El backend determina el formato de cuenta, el comportamiento de bloqueo y qué cambia realmente un restablecimiento de contraseña, y nada de eso es visible en el perfil del cliente.

El despliegue mixto es normal

Certificado de servidor más EAP para el usuario es la forma que despliegan la mayoría de las puertas de enlace de acceso remoto, porque da al cliente un extremo verificable y al operador una identidad por usuario en un almacén de cuentas central. También existen despliegues con certificados de cliente, normalmente donde la identidad del dispositivo importa más que una contraseña. Ambos son legítimos, y el error es suponer que lo que vio la semana pasada es lo que tiene delante.

Pida al operador el método y el formato de cuenta documentados en lugar de inferirlos de los nombres de campo de un cliente.

Decidir a partir de la etapa del fallo

Ordene las observaciones. Un error de confianza antes de cualquier aviso al usuario es un problema de certificado de servidor y ninguna contraseña lo arreglará. Un aviso seguido de un rechazo es un problema de autenticación de usuario, con el método EAP y el backend como sospechosos. Una autenticación correcta seguida de un fallo de child-SA no es ninguno de los dos.

Importan dos distinciones más. Un cliente que rechaza el certificado del servidor suele informar de una discrepancia de nombre o de una autoridad desconocida, que es una cuestión del almacén de confianza. Una puerta de enlace que rechaza al usuario a menudo registra el método EAP y una categoría de motivo, que es una cuestión de cuenta o de política.

Operar los dos modelos

Con los certificados el trabajo es la emisión, la renovación, la revocación y la retirada de dispositivos perdidos, y ocurre según un calendario que usted controla. Con EAP el trabajo es el ciclo de vida de la cuenta, la compatibilidad de métodos en cada plataforma cliente y el segundo factor que exija el backend. Ningún modelo es más barato en abstracto; cargan a equipos distintos. Anote cuál usa realmente su despliegue, porque los scripts de soporte difieren más que la configuración.

Manténgalos separados en sus notas. Una caducidad de certificado produce un fallo en una fecha, un bloqueo de cuenta produce un fallo tras un cambio de contraseña, y una discrepancia de método produce un fallo solo en una plataforma.

Después de aceptar la identidad

La autenticación es una puerta. La asociación de seguridad hija, los selectores de tráfico, el DNS y los permisos propios de la aplicación son puertas posteriores, y cada una falla con sus propias condiciones. Una identidad aceptada que no llega a nada no es un problema de autenticación.

Registre el método, la cuenta o el certificado utilizado y la etapa que falló. Esa nota convierte el siguiente incidente en una consulta en lugar de un experimento.