Dos identidades en un inicio de sesión IKEv2: primero la máquina, después el usuario

Un certificado de cliente se valida, el primer intercambio se completa y entonces la conexión se detiene con un error sobre una ronda adicional de autenticación. Nada en la cadena de certificados está mal y nada en la red ha cambiado. La puerta de enlace está configurada para exigir una segunda prueba al lado que se conecta, y el cliente nunca la envía. Decidir quién demuestra qué, y en qué orden, es toda la tarea, y empieza leyendo la política desde el extremo en el que está. Dos pruebas de distinto tipo, en un orden fijo, son una decisión de diseño y no una casilla de verificación.

El síntoma: fallo tras una primera prueba correcta

El primer intercambio se completa y el registro parece sano, hasta que la puerta de enlace pide una identidad de usuario mediante EAP. Entonces el saludo se detiene o devuelve un error de protocolo que nombra la ronda adicional. Un certificado de máquina perfectamente válido se rechaza por un motivo que no tiene nada que ver con su validez. La política pedía una segunda prueba, y la respuesta del cliente nunca llegó.

Ambas descripciones de ese fallo son exactas según dónde esté. Desde el lado del cliente parece un servidor que rechaza un certificado válido, y desde el lado del servidor parece un cliente que no puede terminar el inicio de sesión. El mismo suceso se lee como un problema de confianza en un registro y un problema de capacidad en el otro. Solo la política configurada le dice cuál es.

Qué añade la extensión y qué no

IKEv2 lleva una extensión para ejecutar más de un intercambio de autenticación dentro de una sola sesión. RFC 4739 esboza, entre otras secuencias, un cliente que demuestra una identidad de certificado y después autentica a una persona mediante EAP. El documento es Experimental, lo que significa que ninguna implementación le debe la función. No suponga nada sobre el soporte hasta que el par lo negocie.

Ambos lados tienen que soportar la extensión y acordarla durante el intercambio. Una puerta de enlace configurada para una segunda ronda no puede obligar a un cliente a hacer una, y un cliente que la soporta no la usará si el servidor no lo pide. Esa asimetría es la razón por la que el fallo suele aparecer como un tiempo de espera o un error de protocolo en lugar de una declaración clara sobre la capacidad. Leer la configuración de un lado le dice la mitad de lo que ocurrirá.

Una prueba por extremo es la forma normal, y este no es ese diseño. La puerta de enlace presenta su certificado, el usuario responde por EAP, y cada lado ha autenticado al otro exactamente una vez. Esas dos pruebas vienen de extremos opuestos, así que ninguna dice nada por separado sobre la máquina y la persona que la usa.

EAP-TLS es una tercera forma, y tampoco es esta. Allí un certificado de cliente se presenta dentro de un método EAP, así que el cliente sigue completando una única autenticación IKE. Las credenciales pueden parecer idénticas al caso de varias rondas mientras el protocolo lleva una ronda en lugar de dos. Por eso un diseño copiado de un despliegue de EAP-TLS falla justo donde se espera la segunda prueba.

El mismo archivo se lee distinto en la puerta de enlace

El mismo archivo swanctl se lee distinto según dónde se ejecute, y esa es la parte que hace tropezar a la gente. En el portátil la puerta de enlace es el par, y en la puerta de enlace el portátil es el par, así que escriba el lado local como quién soy yo y el lado remote como a quién aceptaré. Un bloque local describe cómo se autentica este extremo, y un bloque remote indica qué exige del otro extremo. Copiar un bloque entre los dos archivos invierte su significado sin cambiar un solo carácter. Comparar los dos archivos no le dice casi nada, porque las mismas palabras significan cosas opuestas en cada uno.

La posición de una sección fija su orden salvo que un número de ronda la anule. Por eso las secciones local o remote adicionales describen rondas adicionales y no alternativas, y el número de ronda explícito en la referencia de swanctl.conf existe precisamente para hacer deliberado ese orden. Sin él, mover un bloque cambia el comportamiento. Por eso también dos configuraciones que sobre el papel parecen equivalentes pueden comportarse en órdenes opuestos.

Esa regla de orden produce el modo de fallo que vale la pena recordar. Un segundo bloque remote no es otra opción aceptable; es una segunda exigencia, y por eso una política que se lee como o/o se comporta como y-después. Una política de puerta de enlace puede aceptar el certificado de la máquina inscrita y después exigir el intercambio EAP de ese usuario, en ese orden.

Distinga rondas de factores independientes

Dos rondas no son automáticamente dos factores independientes. Repetir una prueba, o tener dos credenciales en el mismo almacén, no aporta la fuerza que el diseño debía añadir. La independencia es una propiedad de cómo se guardan los secretos y de qué los compromete, no de cuántos intercambios ejecuta el protocolo. Un diseño que cuenta rondas como factores exagera lo que tiene. Esa distinción importa sobre todo cuando una pregunta de cumplimiento pregunta cuántos factores usa realmente el inicio de sesión.

Un certificado de máquina demuestra la posesión de su clave aceptada, y nada más. No es una atestación de hardware ni un informe de salud del dispositivo, así que una política que necesita información de postura necesita otro mecanismo. El campo subject tampoco es una etiqueta de inventario fiable, porque el subject lo elige quien emitió o inscribió el certificado. Si el diseño necesita una prueba de que la máquina está sana, esa prueba tiene que venir de un componente que mida la máquina.

Anote qué demuestra realmente cada ronda antes de añadirla. Cuando dos rondas demuestran lo mismo dos veces, la segunda añade latencia y tickets de soporte en lugar de garantía. Esa nota es también lo que detiene una discusión sobre si la ronda adicional merece su coste.

Escriba la regla de emparejamiento y pruebe las denegaciones

Decida qué identidades de máquina pueden emparejarse con qué personas, y escriba la regla donde vive la aplicación. Dos credenciales válidas una al lado de la otra no demuestran nada sobre el emparejamiento, porque el emparejamiento es una decisión de autorización y no un resultado de autenticación. Los registros de inscripción o el backend de autenticación tienen que aplicar la relación que la organización quiere.

Después pruebe qué debería fallar: un usuario aceptado en una máquina no aprobada, un usuario no aprobado con la credencial de la máquina y un par que no puede realizar la ronda adicional. Si los tres reciben en silencio el mismo acceso, la política describe una intención en lugar de aplicarla. Compare la configuración declarada con lo que informa el demonio, porque una conexión que nunca coincidió parece idéntica a una regla que pasó:

swanctl --list-conns
swanctl --list-sas

Compruebe las rondas negociadas y la autorización resultante, no solo el inicio de sesión correcto. Y no recurra a ajustes antiguos de IKEv1 XAuth como atajo: haga coincidir el protocolo, los roles, el orden y el comportamiento real del cliente en lugar de borrar una ronda necesaria hasta que una conexión funcione. Borrar la ronda que falla es como un diseño de dos pruebas se convierte en silencio en un diseño de una prueba que nadie revisó. Deje el borrado en el registro de cambios.