IKEv2 dirección del servidor versus identidad: lo que el cliente realmente verifica

Una puerta de enlace que cambia de dirección puede seguir funcionando mientras la misma puerta de enlace detrás de un nuevo certificado se detiene, y también ocurre lo contrario. La dirección le dice al cliente dónde enviar paquetes; la identidad autenticada le dice al cliente si el par que responde es en quien debe confiar. IKEv2 los mantiene como dos campos separados, lo cual es útil una vez que dejas de tratarlos como una sola cadena. También están configurados en diferentes lugares, por lo que uno puede estar correcto mientras que el otro está equivocado.

Verifíquelos en este orden y deténgase en la primera discrepancia, porque las verificaciones posteriores suponen que las anteriores pasaron.

Primero, ¿qué valor es la dirección

La dirección de conexión es lo que marca el cliente: una IP, un nombre DNS que se resuelve en uno o una interfaz con equilibrio de carga. Eso es información de transporte y nada más. La identidad se incluye en la carga útil de ID IKEv2 y luego se compara con el certificado del par. Un nombre DNS en el cuadro de dirección no se convierte en la identidad esperada, y una IP sin formato no se convierte en la identidad solo porque el socket está conectado a ella.

En términos de strongSwan, la dirección es right o left, y la identidad esperada es rightid o leftid, y eso es lo que describe la documentación de configuración IKEv2. Si alguna vez solo has editado la dirección, has configurado la mitad del par.

En segundo lugar, qué puede probar el certificado

La identidad tiene un tipo y el certificado debe llevar un nombre coincidente. Una identidad DNS se satisface mediante una entrada dNSName en la extensión de nombre alternativa del sujeto; una identidad IP necesita una entrada iPAddress. Un certificado emitido para vpn.example.com no prueba nada sobre la dirección literal 203.0.113.10, y uno emitido para esa dirección no prueba nada sobre el nombre. Por lo tanto, la reemisión para un nombre diferente no es un reemplazo directo, incluso cuando se reutilizan la misma clave y CA.

Los clientes modernos ignoran el nombre común cuando existe un nombre alternativo del sujeto, y muchos lo ignoran por completo. Si la lista SAN no contiene el valor que el cliente verifica, el protocolo de enlace falla después de que el certificado ya ha sido aceptado como confiable, razón por la cual el registro se lee como un error de identidad en lugar de un error de confianza.

En tercer lugar, cómo cada cliente expresa sus expectativas

Windows toma el nombre del servidor o la dirección que usted escribió y requiere que el certificado coincida, por lo que escribir una IP crea una expectativa de IP. El cliente IKEv2 de Android se comporta de la misma manera y ambos rechazan un certificado válido y de confianza pública que nombra un host diferente. Un perfil puede empezar a fallar simplemente porque alguien reemplazó el nombre de host con su dirección durante una migración. Mire lo que solicitó el cliente antes de mirar lo que contiene el certificado.

En strongSwan la expectativa es explícita: establezca rightid en la identidad que el servidor realmente presenta, que puede diferir de la derecha. Establecerlo en %any acepta todo lo que ofrece el par y elimina exactamente el cheque que está tratando de mantener.

Cuarto, separe el inicio de sesión del usuario de la identidad del par

La autenticación EAP y la identidad del servidor responden preguntas diferentes. Una identidad EAP como [email protected] dice quién es el usuario, después de que el cliente ha decidido que el servidor es el correcto. Rotar esa contraseña no puede solucionar una discrepancia en la identidad de un par, porque la conexión nunca llega a la etapa de inicio de sesión del usuario.

Un informe saneado debe nombrar ambos: la identidad que esperaba el cliente, la identidad que presentó el servidor y las entradas SAN del certificado.

Quinto, cámbialo a través de un canal verificado

Cuando la puerta de enlace se mueve legítimamente, primero actualice la dirección y deje la identidad en paz, porque ese es el caso IKEv2 se maneja bien. Cuando la identidad misma cambie, trátela como un evento de confianza y obtenga el nuevo valor de una fuente en la que ya confía, no del punto final que actualmente está fallando. Un mensaje entregado a través de la conexión que está intentando validar no es evidencia de esa conexión.

Registre la dirección final, la identidad y la lista SAN juntas en las notas del perfil. La siguiente persona que toque el certificado verá cuál de los tres puede moverse.