Des secrets invalides sont un problème de conteneur, pas une règle de mot de passe
Un identifiant rejeté n'a peut-être jamais atteint la passerelle. Comparez d'abord le conteneur d'entrée, l'étape d'authentification et le compte lui-même.
Voir « secrets invalides » mène généralement à une conclusion : le VPN n'aime pas la ponctuation. Cette conclusion est souvent fausse, car le message vient souvent du traitement local avant qu'une passerelle ait regardé le compte. Deux conceptions livrent le même mot de passe, un champ graphique et un fichier d'identifiants, et elles échouent à des endroits différents. Comparez les conteneurs avant de simplifier un mot de passe qui était correct depuis le début.
L'erreur survient avant la passerelle
La validation locale, un magasin de secrets verrouillé, un agent absent et un fichier d'identifiants mal formé produisent tous des échecs que l'utilisateur vit comme un seul rejet. Aucun d'eux n'implique le serveur d'authentification. Le rejet propre à la passerelle est un événement distinct, et il arrive généralement avec un autre message et à un autre moment. Il se produit après qu'un tunnel existe et que les identifiants ont été transmis.
La première question n'est donc pas quels caractères sont légaux, mais où la tentative s'est arrêtée. Un client qui n'a jamais ouvert de connexion n'a été rejeté par personne. Notez l'étape que vous avez observée, car chaque étape suivante dépend de cette classification.
La distinction change aussi qui répare. Un problème de conteneur appartient à l'appareil et à son propriétaire, tandis qu'un rejet de compte appartient à celui qui exploite le backend d'authentification.
Comparez les conteneurs, pas les caractères
Un champ de mot de passe graphique, une entrée de trousseau, un fichier d'identifiants de deux lignes et un secret d'automatisation portent chacun la même valeur dans une enveloppe différente. L'enveloppe a ses propres règles, et ce sont ces règles qui cassent généralement. La valeur est rarement le problème ; le transport de la valeur l'est. Gardez les deux idées séparées et le diagnostic sera plus court.
| Where the value stops | What you see | What you check | Who owns the fix |
|---|---|---|---|
| GUI field or managed profile | A validation message before any connection opens | The selected authentication mode and whether the field holds the secret or the username | The device owner or the profile author |
| Keychain or secret agent | A prompt that keeps reappearing, or an agent error | Whether the agent is unlocked and holds an entry for this profile | The user who owns the keychain |
| Two-line credential file | A prompt for a password that was already supplied | Line count, line order and whether a trailing newline is present | Whoever generated the file |
| Shell argument or environment | Works interactively but fails in automation | Whether the shell expanded, trimmed or logged the value | Whoever wrote the automation |
Options client OpenVPN 2.6 de la communauté décrivent ce fichier de deux lignes pour auth-user-pass, y compris le comportement lorsque la ligne du mot de passe est absente : le client demande alors. Ce seul détail explique toute une classe de rapports du type « il demande un mot de passe que j'ai déjà fourni ». Il vous dit aussi qu'une seconde ligne vide est un état significatif et non un choix de formatage inoffensif.
Le guillemetage est encore une autre couche : les guillemets dans un fichier d'identifiants simple sont stockés comme données, tandis qu'un shell les supprime avant que le programme ne voie quoi que ce soit. Le même caractère est inoffensif à un endroit et structurel à l'autre. Un tableau ne peut pas vous dire quel conteneur votre client a utilisé, alors lisez la configuration du client avant de choisir une ligne.
Les sauts de ligne sont eux aussi structurels. Un fichier à champs délimités par des lignes ne peut pas porter une valeur contenant un saut de ligne, et c'est une limite du format, non un jugement sur la force du mot de passe. Utilisez le mécanisme de livraison pris en charge par le déploiement plutôt que de raccourcir le secret pour le faire tenir dans un fichier improvisé.
Créez le fichier d'identifiants sans dégâts du shell
La voie locale la plus sûre garde le secret hors de l'historique du shell et hors de la liste d'arguments du processus. Lisez les deux champs de façon interactive, puis écrivez les deux lignes attendues par le client. Tout le reste peut rester dans un fichier de configuration facile à relire.
read -r VPN_USER
read -rs VPN_PASS
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client/creds
chmod 600 /etc/openvpn/client/creds
openvpn --config /etc/openvpn/client/office.conf --auth-user-pass /etc/openvpn/client/credsLes deux premières commandes lisent le nom d'utilisateur puis le mot de passe sans l'afficher, la troisième écrit les deux lignes, la quatrième restreint le fichier et la dernière démarre le client avec ce fichier. Notez que read -r conserve les barres obliques inverses, et c'est exactement le genre de détail qui transforme un mot de passe fonctionnel en échec lorsqu'il est omis.
Évitez de construire le fichier avec une variable sans guillemets ou avec un here-document plein d'expansions du shell. Les deux peuvent transformer des caractères avant qu'ils n'atteignent le fichier, et l'échec qui en résulte ressemble à un rejet du VPN parce que le mot de passe sur le disque est réellement différent de celui que vous connaissez. Si vous le soupçonnez, comparez la longueur en octets du fichier avec la valeur attendue, sans imprimer le secret lui-même. Un écart d'un ou deux octets est la signature d'un accident de guillemets.
Lisez l'étape à partir de la première erreur
Conservez le premier message précis d'une tentative, puis classez-le. Une erreur de validation locale, une clé privée absente, un agent de secrets indisponible et un échec d'authentification sur la passerelle sont quatre résultats différents avec quatre propriétaires différents. Un seul d'entre eux concerne le compte.
Si la passerelle rejette réellement un identifiant correctement livré, vérifiez le compte, le backend d'authentification et toute demande d'authentification requise avec l'administrateur. Un échec d'authentification générique ne nomme aucun caractère interdit.
Restaurez la valeur approuvée par le mécanisme correct plutôt que de la réduire à des lettres et des chiffres. La politique de mots de passe appartient à l'exploitant, et un contournement qui la vide en silence n'est pas une correction. Il cache aussi le défaut réel à la personne suivante, qui rencontrera la même erreur avec un mot de passe plus faible et sans meilleure idée.