O intercambio IKEv2 funciona e despois falla a autenticación: onde buscar

Un cliente que recibe unha resposta IKEv2 demostrou que a pasarela é accesible, que ambas as partes poden negociar unha proposta e que o intercambio de claves inicial rematou. Non demostrou que ninguén estea autenticado. O seguinte intercambio leva identidades, certificados ou EAP, e é aí onde a conexión adoita deterse. Ler cal desas comprobacións fallou é todo o diagnóstico, e a mensaxe de erro por si soa raramente o di.

Comprobación 1: lea a etapa, non a mensaxe

Un rexeitamento pode vir de tres lugares: o cliente que rexeita a identidade do servidor, a pasarela que rexeita a proba do cliente e un servizo de autenticación externo que rexeita a conta.

Cada un produce unha liña de rexistro distinta nunha máquina distinta, e cada un ten unha corrección distinta. Un rexeitamento do certificado do servidor por parte do cliente é un problema de confianza ou de nomeado no cliente; un rexeitamento do certificado do cliente por parte da pasarela é un problema de confianza na pasarela; un fallo de EAP é un problema de conta ou de backend. A mensaxe que ve adoita ser o resumo do cliente dun deses casos, e por iso o rexistro da pasarela importa tanto como o do cliente.

Comprobación 2: que identidade se comprobou

Un cliente pode rexeitar o certificado do servidor ou a identidade esperada antes de que se ofreza calquera credencial de usuario, e un enderezo de servidor que funcione non substitúe esa comprobación. O identificador que o cliente espera debe coincidir co que presenta a pasarela, o que é un feito de configuración e non de rede.

En termos de strongSwan iso é rightid no cliente e a identidade propia da pasarela no outro lado, e unha discrepancia falla antes de que se discuta EAP.

A pasarela, por separado, pode rexeitar o certificado do cliente, a súa proba de clave ou a autenticación da súa conta, e eses tres casos non son intercambiables. Restablecer o contrasinal dun usuario non renova un certificado de dispositivo, e reinstalar un certificado de dispositivo non corrixe unha identidade de servidor incorrecta. Para fallos de certificado, comprobe primeiro o reloxo, despois a cadea de confianza e despois o identificador esperado; un cliente cuxo reloxo está uns minutos fóra falla unha comprobación de validez que parece un fallo de confianza. swanctl --list-certs en ambos os extremos mostra o que cada parte ten realmente.

Comprobación 3: se EAP está en xogo

O cliente e o servidor teñen que acordar un método admitido, e o backend ten que aceptar a identidade que se subministra.

Un nome de usuario pode necesitar un sufixo de dominio ou un formato de conta concreto que esixa o despregamento, e o formato está documentado en vez de ser adiviñable. Subministrar os campos documentados polo operador é máis rápido que probar variantes, e evita un segundo problema: os intentos repetidos poden activar un bloqueo de conta, que despois agocha a etapa orixinal detrás dun novo fallo. Se o método é EAP-MSCHAPv2 contra un directorio, o fallo pode pertencer ao directorio e non á VPN.

Non probe os problemas de identidade desactivando as comprobacións de identidade. Iso converte un fallo diagnosticable nun indiagnosticable e deixa a conexión máis feble que antes.

Comprobación 4: que ocorre despois dun inicio de sesión correcto

Unha vez que IKE_AUTH remata, a negociación de CHILD_SA decide que selectores de tráfico se instalan, e é aí onde unha conexión pode ter éxito e aínda así non pasar nada.

Un inicio de sesión que acaba de funcionar adoita revelar un problema de selector ou de ruta que antes estaba oculto detrás do fallo de autenticación. Se o túnel sobe e unha aplicación segue sen chegar ao seu destino, mire os selectores e as rutas negociados en vez da identidade outra vez. Cambiar a configuración de identidade nese punto apunta á etapa incorrecta e adoita romper un inicio de sesión que funciona. Confirme con swanctl --list-sas, que mostra os fillos e os seus selectores por separado do IKE SA.

Comprobación 5: que entregar ao soporte

Unha cronoloxía depurada e o rexeitamento preciso valen máis que unha exportación de diagnóstico completa, e a exportación pode conter claves privadas ou credenciais que non debería compartir.

Anote a hora coa zona horaria, as versións do cliente e da pasarela, o método, a cadea de identidade ofrecida en vez do contrasinal e a etapa exacta que o rexeitou. A documentación de configuración IKEv2 de strongSwan describe a identidade e a configuración de EAP que deciden estes resultados, e é a referencia que hai que ler antes de cambiar un campo. Despois cambie unha soa cousa e volva probar unha conexión nova, porque unha sesión en caché falaralle da configuración antiga.