L’intercanvi IKEv2 funciona, després falla l’autenticació: on

Un client que rep una resposta IKEv2 ha demostrat que la passarel·la és abastable, que les dues parts poden negociar una proposta i que l’intercanvi inicial de claus s’ha completat. No ha demostrat que ningú estigui autenticat. L’intercanvi següent porta identitats, certificats o EAP, i aquí és on normalment s’atura la connexió. Llegir quina d’aquestes comprovacions ha fallat és tot el diagnòstic, i el missatge d’error sol rarament ho diu.

Comprovació 1: llegiu l’etapa, no el missatge

Hi ha tres llocs d’on pot venir un rebuig: el client que rebutja la identitat del servidor, la passarel·la que rebutja la prova del client i un servei d’autenticació extern que rebutja el compte.

Cadascun produeix una línia de registre diferent en una màquina diferent, i cadascun té una solució diferent. Un rebuig del certificat del servidor per part del client és un problema de confiança o de nom al client; un rebuig del certificat del client per part de la passarel·la és un problema de confiança a la passarel·la; una fallada d’EAP és un problema de compte o de backend. El missatge que veieu sol ser el resum del client d’un d’aquests, i per això el registre de la passarel·la importa tant com el del client.

Comprovació 2: quina identitat s’ha comprovat

Un client pot rebutjar el certificat del servidor o la identitat esperada abans que s’ofereixi cap credencial d’usuari, i una adreça de servidor que funciona no substitueix aquesta comprovació. L’identificador que el client espera ha de coincidir amb el que presenta la passarel·la, cosa que és un fet de configuració i no de xarxa.

En termes de strongSwan això és rightid al client i la identitat pròpia de la passarel·la a l’altre costat, i una discrepància falla abans que es parli d’EAP.

La passarel·la, per separat, pot rebutjar el certificat del client, la prova de la seva clau o l’autenticació del compte, i aquestes tres coses no són intercanviables. Restablir la contrasenya d’un usuari no renova el certificat d’un dispositiu, i reinstal·lar el certificat d’un dispositiu no arregla una identitat de servidor equivocada. En fallades de certificat, mireu primer el rellotge, després la cadena de confiança i després l’identificador esperat; un client amb el rellotge uns minuts desviat falla una comprovació de validesa que sembla una fallada de confiança. swanctl --list-certs als dos extrems mostra què té realment cada part.

Comprovació 3: si hi ha EAP pel mig

El client i el servidor han d’acordar un mètode admès, i el backend ha d’acceptar la identitat que es proporciona.

Un nom d’usuari pot necessitar un sufix de domini o un format de compte concret que el desplegament exigeix, i el format està documentat, no s’endevina. Proporcionar els camps documentats per l’operador és més ràpid que provar variants, i evita un segon problema: els intents repetits poden activar el bloqueig del compte, que llavors amaga l’etapa original darrere d’una fallada nova. Si el mètode és EAP-MSCHAPv2 contra un directori, la fallada pot ser del directori i no de la VPN.

No proveu els problemes d’identitat desactivant les comprovacions d’identitat. Això converteix una fallada diagnosticable en una d’indiagnosticable i deixa la connexió més feble que abans.

Comprovació 4: què passa després d’un inici de sessió correcte

Un cop IKE_AUTH s’ha completat, la negociació de CHILD_SA decideix quins selectors de trànsit s’instal·len, i aquí és on una connexió pot tenir èxit i no passar res.

Un inici de sessió que acaba de funcionar sovint revela un problema de selector o de ruta que abans quedava amagat darrere la fallada d’autenticació. Si el túnel s’aixeca i una aplicació encara no arriba a la seva destinació, mireu els selectors negociats i les rutes, no la identitat una altra vegada. Canviar la configuració d’identitat en aquest punt apunta a l’etapa equivocada i normalment trenca un inici de sessió que funciona. Confirmeu-ho amb swanctl --list-sas, que mostra els fills i els seus selectors per separat de l’IKE SA.

Comprovació 5: què cal lliurar al suport

Una cronologia sanejada i el rebuig exacte valen més que una exportació de diagnòstic completa, i l’exportació pot contenir claus privades o credencials que no hauríeu de compartir.

Anoteu l’hora amb la zona horària, les versions del client i de la passarel·la, el mètode, la cadena d’identitat que es va oferir i no la contrasenya, i l’etapa exacta que el va rebutjar. documentació de configuració d’IKEv2 de strongSwan descriu els paràmetres d’identitat i d’EAP que decideixen aquests resultats, i és la referència que cal llegir abans de canviar un camp. Després canvieu una cosa i torneu a provar una connexió nova, perquè una sessió en memòria cua us parlarà de la configuració antiga.