Une erreur, trois secrets : quelle information d’identification VPN a échoué ?
Le client affiche une erreur pour chaque étape. Lisez l’association, l’échange utilisateur et la méthode avant de réinitialiser un mot de passe que personne n’a vérifié.
« L’authentification a échoué » peut désigner un certificat de serveur, une clé prépartagée de la machine ou un mot de passe utilisateur. Laquelle de ces trois choses dépend du protocole, car chaque protocole définit un ensemble de secrets différent. Réinitialisez le mauvais et l’erreur reste inchangée. La sortie consiste à établir combien de preuves le protocole exige avant de modifier quoi que ce soit.
Deux preuves qui pointent en sens opposés
Un tunnel doit répondre s’il a atteint la bonne passerelle et, séparément, qui est l’utilisateur. La preuve de la passerelle est au niveau machine : un certificat de serveur, une clé prépartagée ou une clé publique statique. La preuve de l’utilisateur est au niveau de la personne : un mot de passe, un jeton, un certificat client, ou rien du tout. Ce sont des directions de confiance opposées et elles consomment des éléments différents.
IKEv2 effectue la preuve de la passerelle dans IKE_AUTH et, lorsque EAP est utilisé, exécute ensuite la preuve de l’utilisateur dans un échange distinct. La spécification IKEv2 les conserve comme des sections distinctes, ce qui est un indice fort sur l’endroit à examiner quand un seul message couvre les deux tours.
Lisez l’étape, pas le message
Le client affiche une seule chaîne d’erreur, quelle que soit l’étape qui a échoué, donc la chaîne elle-même ne porte presque aucune information. Ce qui porte de l’information, c’est l’état que vous pouvez inspecter à chaque étape : si une association existe, si un échange utilisateur a commencé et si le client a proposé la méthode que la passerelle voulait. Le tableau trie les étapes de cette façon plutôt que par nom de protocole.
| Stage that failed | Evidence you can inspect | What a password change cannot fix |
|---|---|---|
| The machine proof | no security association in the state list | a mismatched pre-shared key or an untrusted chain |
| The user proof | an association is up while PPP or EAP reports failure | an expired token, a locked account, a missing client key |
| The client's method support | the client offers no method the gateway accepts | a client without the required EAP or key material |
| The server's policy | the gateway rejects before any user exchange starts | a policy that requires a certificate the profile lacks |
Seule la deuxième ligne concerne une information que l’utilisateur peut retaper. Les trois autres sont des faits de configuration, et c’est ce décalage qui explique pourquoi tant de ces rapports finissent par une réinitialisation de mot de passe qui ne change rien. Lisez la ligne qui correspond à votre preuve avant de toucher un champ.
Un protocole à deux secrets montre son jeu
L2TP sur IPsec rend le décompte visible, car les deux contrôles se produisent dans des processus différents. La couche IPsec doit d’abord monter avec une clé prépartagée ou un certificat, et ce n’est qu’ensuite que PPP à l’intérieur tente une connexion utilisateur.
Quand le secret de la machine est faux, aucune association ne se forme et l’information d’identification de l’utilisateur n’est jamais essayée. Quand le secret de la machine est correct et celui de l’utilisateur faux, l’association existe et PPP rejette la connexion alors que le tunnel est déjà monté. Les deux produisent le même message à l’écran à partir de deux événements différents.
sudo swanctl --list-sas
sudo ip xfrm state list
sudo journalctl -u xl2tpd -n 50 --no-pagerUne liste d’associations vide écarte immédiatement la couche utilisateur, alors vérifiez-la avant le mot de passe. Une association établie avec des échecs PPP répétés pointe dans l’autre sens, vers la couche utilisateur ou vers le protocole d’authentification qu’elle contient. Aucune des deux conclusions n’est disponible dans le texte d’erreur du client.
De quoi dépend réellement l’accès par mot de passe seul
L’accès par mot de passe seul est courant pour L2TP, PPTP, SSTP et IKEv2 avec EAP. WireGuard n’a pas du tout cette option, car ses pairs sont des clés et non des utilisateurs. Pour OpenVPN, la réponse vient de l’exigence de certificat client du serveur : une passerelle qui demande à la fois certificat et mot de passe continuera de rejeter un client muni d’un mot de passe seul, quoi qu’on tape dans le champ.
Le composant dont vous avez besoin découle de la même réponse. Une connexion par mot de passe sous IKEv2 exige un client qui parle EAP, tandis qu’une connexion par certificat a besoin de la clé privée du client et de la chaîne du serveur. Installez le mauvais et l’échec se lit comme une erreur d’identification, alors même que c’est la méthode d’authentification elle-même qui manque.
Changez une chose, puis retestez
Établissez d’abord trois faits : quel protocole tourne, combien de secrets il définit et lesquels appartiennent à la machine plutôt qu’à l’utilisateur. Les machines échouent à la première étape et les personnes à la seconde, et confondre les deux, c’est tout le problème.
Changez ensuite exactement une chose et retestez depuis le même client. Cette discipline transforme un échec déroutant en correction que vous pouvez décrire à la personne suivante, ce qui est plus utile qu’une connexion qui marche et que personne ne sait expliquer.