Com es trasllada l’autenticació híbrida d’IKEv1 a l’autenticació d’usuaris d’IKEv2

Qualsevol perfil VPN heretat que demana un certificat de servidor i després un nom d’usuari porta dos esdeveniments d’autenticació dins d’un sol intercanvi, i aquesta forma sobreviu al protocol que la va introduir. El mode híbrid d’IKEv1 es va construir exactament per a això: la passarel·la es demostra amb una clau pública mentre l’usuari es demostra més tard mitjançant XAuth. IKEv2 expressa la mateixa idea en dos passos amb maquinària diferent, i és en aquestes diferències on fallen les migracions. Cap número de versió converteix l’un en l’altre, i copiar els noms d’opció antics en un perfil nou produeix un client que negocia i després no autentica res.

Què feia el mode híbrid dins d’IKEv1

En un perfil híbrid el responedor signa l’intercanvi de la fase u amb el seu certificat mentre l’iniciador no en presenta cap a propòsit. La prova d’identitat és, per tant, asimètrica, i això és el que va permetre a una passarel·la conservar la seva PKI existent mentre els usuaris conservaven les contrasenyes del directori. Un cop completada la fase u, XAuth s’executa com una petició i una resposta que porten els atributs de nom d’usuari i contrasenya dins del canal ISAKMP ja xifrat.

Fixeu-vos on recau la confiança. El certificat respon a quina passarel·la ha arribat el client; XAuth respon a quin usuari vol accés. Cap dels dos substitueix l’altre, i un client configurat per acceptar qualsevol certificat de servidor ha descartat en silenci la primera resposta. L’etiqueta híbrida també s’usa per al mode agressiu amb clau prèviament compartida més XAuth, una disposició diferent amb la mateixa experiència d’usuari, així que llegiu el perfil i no el nom. Totes dues variants provenen d’esborranys que mai no van esdevenir estàndards, i per això dos fabricants poden implementar el mode híbrid i no interoperar amb cap.

Com arriba IKEv2 a les mateixes dues proves

IKEv2 reparteix la feina entre IKE_SA_INIT i IKE_AUTH. El primer intercanvi acorda propostes i claus sense cap identitat; el segon porta IDi, IDr i les càrregues AUTH. Amb EAP la primera càrrega AUTH de l’iniciador surt buida, el responedor s’autentica primer amb el seu certificat i la seva signatura, i la conversa EAP corre després dins dels missatges IKE_AUTH.

El mecanisme que ho fa segur és el material de claus. Un mètode EAP correcte exporta una clau de sessió, i la càrrega AUTH final de l’iniciador es calcula a partir d’ella, de manera que la prova de l’usuari i les claus del túnel queden lligades. XAuth no té equivalent: els seus atributs arriben després de la fase u i no aporten res a les claus. Aquesta escletxa és exactament el que el marc d’IKEv2 es va dissenyar per tancar, i per això un inici de sessió IKEv2 que funciona valida el certificat del servidor abans de demanar res.

Aquest ordre també és un bon diagnòstic. Quan un client es queixa de les credencials abans d’haver-vos mostrat un certificat, no està fent cap intercanvi EAP d’IKEv2.

Manteniu tres identitats separades

Una migració va malament quan tres identitats col·lapsen en un sol camp. Hi ha la identitat de la passarel·la que valida el client, normalment un nom DNS al subjecte o al SAN del certificat. Hi ha la identitat de l’usuari presentada a EAP, que pot ser un inici de sessió de domini, una adreça o una cadena d’identitat EAP explícita. I hi ha la font d’autorització que assigna aquest usuari a xarxes i rutes.

La sintaxi swanctl de strongSwan fa visible la separació: la connexió fixa remote { auth = pubkey } per a la passarel·la i local { auth = eap-mschapv2 } per a l’usuari, amb la identitat EAP portada a part.

Quan la identitat d’usuari del perfil nou difereix dels atributs XAuth antics, per exemple un UPN en lloc d’un nom curt, el servidor d’autenticació veu un usuari desconegut i la fallada sembla una contrasenya incorrecta. Comproveu la cadena d’identitat abans de comprovar la credencial.

Mapegeu les opcions i espereu les trampes

La correspondència és curta i cada fila té una trampa que només apareix en el moment de l’autenticació.

Cap d’aquestes files no és un simple canvi de nom. La càrrega de configuració lliura adreces i resoledors mitjançant una llista d’atributs tipats, mentre que l’espai d’atributs de XAuth era una invenció pròpia; tractar-los com a intercanviables és com un perfil acaba demanant un paràmetre que la passarel·la no enviarà mai.

Els selectors de trànsit mereixen el seu propi avís. IKEv1 expressava el trànsit interessant mitjançant identificadors de proxy lligats a un intercanvi de mode ràpid, mentre que IKEv2 negocia els selectors durant IKE_AUTH i el responedor pot estretir-los. Un desajust produeix una IKE SA establerta sense SA filla, que alguns clients mostren ben contents com a connectada.

Tracteu la connexió antiga com una frontera

L’RFC 9395 depreca IKEv1, així que una connexió híbrida heretada és una frontera de compatibilitat amb data, no un fonament. Executeu tots dos perfils en paral·lel durant el canvi, perquè la prova que importa no és si el perfil nou arrenca, sinó si el mateix usuari al mateix dispositiu arriba als mateixos recursos.

Manteniu estricta la validació de certificats de principi a fi. Quan el client deixa de presentar el seu propi certificat, la temptació és relaxar la comprovació del servidor fins que l’handshake es completa, i això canvia l’única prova que queda per una icona verda.

Anoteu quatre coses abans de retirar el perfil antic: el mètode EAP, la cadena d’identitat, la font d’autorització i la data en què acaba el suport.