Como se traslada a autenticación híbrida de IKEv1 á autenticación de usuarios de IKEv2

Todo perfil VPN herdado que pide un certificado de servidor e despois un nome de usuario leva dous acontecementos de autenticación dentro dun só intercambio, e esa forma sobrevive ao protocolo que a introduciu. O modo híbrido de IKEv1 construíuse exactamente para isto: a pasarela demóstrase cunha clave pública mentres o usuario se demostra máis tarde mediante XAuth. IKEv2 expresa a mesma idea en dous pasos con mecanismos distintos, e é nesas diferenzas onde fallan as migracións. Ningún número de versión converte un no outro, e copiar os nomes de opción antigos nun perfil novo produce un cliente que negocia e despois non autentica nada.

Que facía o modo híbrido dentro de IKEv1

Nun perfil híbrido o respondente asina o intercambio da fase un co seu certificado mentres o iniciador non presenta ningún a propósito. A proba de identidade é, por tanto, asimétrica, e iso permitiu a unha pasarela conservar a súa PKI existente mentres os usuarios conservaban os contrasinais do directorio. Cando remata a fase un, XAuth execútase como unha petición e unha resposta que levan os atributos de nome de usuario e contrasinal dentro da canle ISAKMP xa cifrada.

Fíxese en onde recae a confianza. O certificado responde a que pasarela chegou o cliente; XAuth responde a que usuario quere acceso. Ningún substitúe o outro, e un cliente configurado para aceptar calquera certificado de servidor descartou en silencio a primeira resposta. A etiqueta híbrida tamén se usa para o modo agresivo con clave precompartida máis XAuth, unha disposición distinta coa mesma experiencia de usuario, así que lea o perfil e non o nome. Ambas as variantes proceden de borradores que nunca chegaron a ser estándares, e por iso dous fabricantes poden implementar o modo híbrido e non interoperar con ningún.

Como chega IKEv2 ás mesmas dúas probas

IKEv2 reparte o traballo entre IKE_SA_INIT e IKE_AUTH. O primeiro intercambio acorda propostas e claves sen identidade ningunha; o segundo leva IDi, IDr e as cargas AUTH. Baixo EAP a primeira carga AUTH do iniciador sae baleira, o respondente autentícase primeiro co seu certificado e a súa sinatura, e a conversa EAP corre despois dentro das mensaxes IKE_AUTH.

O mecanismo que o fai seguro é o material de claves. Un método EAP correcto exporta unha clave de sesión, e a carga AUTH final do iniciador calcúlase a partir dela, de xeito que a proba do usuario e as claves do túnel quedan ligadas. XAuth non ten equivalente: os seus atributos chegan despois da fase un e non contribúen en nada ás claves. Esa fenda é xustamente o que o marco de IKEv2 deseñouse para pechar, e por iso un inicio de sesión IKEv2 que funciona valida o certificado do servidor antes de pedir nada.

Esta orde tamén é un diagnóstico útil. Cando un cliente se queixa das credenciais antes de lle ter mostrado un certificado, non está facendo un intercambio EAP de IKEv2 en absoluto.

Manteña tres identidades separadas

Unha migración vai mal cando tres identidades colapsan nun só campo. Está a identidade da pasarela que valida o cliente, normalmente un nome DNS no suxeito ou no SAN do certificado. Está a identidade do usuario presentada en EAP, que pode ser un inicio de sesión de dominio, un enderezo ou unha cadea de identidade EAP explícita. E está a fonte de autorización que asigna ese usuario a redes e rutas.

A sintaxe swanctl de strongSwan fai visible a separación: a conexión fixa remote { auth = pubkey } para a pasarela e local { auth = eap-mschapv2 } para o usuario, coa identidade EAP levada á parte.

Cando a identidade de usuario no perfil novo difire dos atributos XAuth antigos, por exemplo un UPN en lugar dun nome curto, o servidor de autenticación ve un usuario descoñecido e o fallo parece un contrasinal incorrecto. Comprobe a cadea de identidade antes de comprobar a credencial.

Mapee as opcións e conte coas trampas

A correspondencia é curta e cada fila ten unha trampa que só aparece no momento da autenticación.

Ningunha desas filas é un simple cambio de nome. A carga de configuración entrega enderezos e resolvedores mediante unha lista de atributos tipados, mentres que o espazo de atributos de XAuth foi invención propia; tratalos como intercambiables é como un perfil acaba pedindo un axuste que a pasarela nunca enviará.

Os selectores de tráfico merecen o seu propio aviso. IKEv1 expresaba o tráfico interesante mediante identificadores de proxy ligados a un intercambio de modo rápido, mentres que IKEv2 negocia os selectores durante IKE_AUTH e o respondente pode estreitalos. Un desaxuste produce unha IKE SA establecida sen SA filla, que algúns clientes mostran moi contentos como conectada.

Trate a conexión antiga como unha fronteira

O RFC 9395 depreca IKEv1, así que unha conexión híbrida herdada é unha fronteira de compatibilidade con data, non un alicerce. Execute ambos os perfis en paralelo durante o cambio, porque a proba que importa non é se o perfil novo arranca, senón se o mesmo usuario no mesmo dispositivo chega aos mesmos recursos.

Manteña estrita a validación de certificados de principio a fin. En canto o cliente deixa de presentar o seu propio certificado, a tentación é relaxar a comprobación do servidor ata que o handshake remate, e iso cambia a única proba que queda por unha icona verde.

Anote catro cousas antes de retirar o perfil antigo: o método EAP, a cadea de identidade, a fonte de autorización e a data en que remata o soporte.