Échec de l’authentification VPN : rarement le port ou le DNS

L’échec de l’authentification signifie que le service a reçu une identité et l’a refusée, ce qui est une affirmation plus étroite que ce que la plupart des gens y lisent. Le port est ouvert, la session TLS a peut-être abouti, et quelque chose dans les identifiants ou le compte a été rejeté. Changer les paramètres réseau ne peut pas y remédier, et répéter la tentative peut verrouiller le compte. Le texte de l’erreur nomme déjà l’étape, alors commencez par là.

L’erreur vous a déjà dit quelle étape a échoué

Une connexion qui n’achève jamais sa poignée de main TLS n’a pas du tout atteint l’authentification. Une connexion qui achève la poignée de main puis signale un refus des identifiants l’a atteinte et y a échoué. Ces deux issues demandent des enquêtes différentes, et elles sont souvent confondues parce que toutes deux se terminent par une fenêtre fermée.

OpenVPN rend la distinction explicite avec un message AUTH_FAILED du serveur, qui est une décision et non une erreur de transport. Un délai d’attente de la négociation TLS ou une erreur de vérification du certificat relèvent de l’étape précédente. Lisez laquelle vous avez avant de toucher aux identifiants, car une réinitialisation de mot de passe ne peut pas réparer une poignée de main et un changement de pare-feu ne peut pas réparer un identifiant refusé. Une ligne du journal du client répond à la question.

La même logique s’applique à une session qui se connecte puis tombe plus tard. Un échec de réauthentification à la quarantième minute est un défaut différent d’un refus à la première connexion, et l’intervalle est l’indice.

Confirmez que le profil pointe vers le bon service

Le compte utilisé sur le site d’un fournisseur n’est pas toujours celui que sa passerelle VPN accepte. Un profil enregistré peut aussi pointer vers une ancienne passerelle longtemps après le déménagement du service.

Comparez le point de terminaison du profil à celui publié par l’opérateur, et vérifiez quel système d’identité la passerelle consulte. Une réinitialisation de mot de passe sur un portail web ne change rien si le tunnel s’authentifie auprès d’un annuaire séparé. Les identifiants d’un serveur public sans rapport ne fonctionneront pas sur le vôtre, et tester un mot de passe professionnel dans un profil reçu par un message non fiable est de toute façon un mauvais échange. Confirmez l’origine avant de taper quoi que ce soit.

Deux minutes sur le profil évitent une journée de devinettes sur les identifiants.

Le format de connexion fait partie des identifiants

Un nom d’utilisateur peut exiger une forme d’adresse électronique, un préfixe de domaine ou un suffixe d’annuaire. La passerelle compare la chaîne qu’elle a reçue, donc la forme fait partie des identifiants et non de la décoration.

Écartez ensuite les causes ennuyeuses avant d’escalader. Vérifiez la disposition du clavier, un espace final introduit par un copier-coller, et une ancienne entrée du gestionnaire de mots de passe. Après une réinitialisation, confirmez que le VPN utilise la même source d’identité que la page où le mot de passe a été changé. Si ces détails sont corrects, arrêtez de deviner et demandez à l’opérateur si le compte est activé et autorisé pour l’accès VPN. C’est une correction côté service, pas un réglage client.

openvpn --config office.ovpn --verb 3
journalctl -u openvpn-client@office -n 40 --no-pager

La ligne de journal qui porte AUTH_FAILED inclut généralement un code de raison ou une chaîne de défi. Copiez-la exactement au lieu de la paraphraser lorsque vous demandez de l’aide.

Les seconds facteurs ont leur propre contrat

Le profil peut attendre un code à usage unique, un défi interactif ou une connexion au navigateur qui renvoie un jeton au client. Utilisez le flux pris en charge par l’opérateur au lieu d’en inventer un.

N’ajoutez pas de code au mot de passe, sauf si ce format est explicitement requis, car certains déploiements utilisent un champ séparé et d’autres une chaîne de défi. Pour les codes temporels, vérifiez l’horloge de l’appareil, car quelques minutes de dérive invalident tous les codes. Si la connexion au navigateur réussit et que le client ne reprend jamais, notez exactement ce point, car il identifie la transmission et non l’identifiant. Une autre réinitialisation de mot de passe n’aidera probablement pas.

La limite de sessions est l’autre refus courant. Si le compte n’autorise qu’une session, une seconde connexion peut mettre fin à la première, et le symptôme ressemble à une connexion intermittente plutôt qu’à une politique.

Un certificat n’est pas un mot de passe

Un certificat client peut expirer ou être révoqué alors que le mot de passe du compte reste parfaitement correct. La phrase secrète d’une clé privée est encore un troisième secret, et elle protège un fichier et non un compte.

Lisez l’erreur avant de remplacer quoi que ce soit, puis obtenez le bon remplacement auprès de l’opérateur vérifié. Gardez la vérification de l’identité du serveur activée pendant ce temps : accepter un certificat sans rapport ou copier la clé privée de quelqu’un d’autre n’est pas une réparation, c’est un second incident. Testez ensuite la ressource dont vous avez réellement besoin, car un tunnel connecté avec un service inaccessible relève d’une autre enquête. Notez quelle étape a échoué pour que la personne suivante ne relance pas tout le processus.

Si la session s’établit et échoue plus tard, consignez l’intervalle et tout événement de renouvellement proche. Cette consignation sépare un problème de durée de vie du jeton d’un échec de première connexion, et c’est la différence entre une correction de cinq minutes et une semaine de nouvelles tentatives.