openvpn3 session-start ignore votre fichier d’identifiants

Connectez-vous avec le client 2.x et le profil fonctionne ; donnez le même fichier au client 3.x et il s’arrête sur une invite de mot de passe. Passez --auth-user-pass creds.txt à openvpn3 session-start et le résultat est identique, car le client plus récent n’a aucune étape qui lise le fichier. Le refus est délibéré : les identifiants appartiennent à une session, et une session est créée par un service, non par le processus de votre terminal. Choisissez entre l’invite interactive et l’assistant de chargement automatique, et sachez ce que chacun stocke.

Pourquoi le fichier enregistré n’a nulle part où aller

Dans la conception plus récente, la gestion de la configuration et la gestion des sessions sont des services distincts qui dialoguent sur le bus système. C’est cette séparation qui permet à un utilisateur ordinaire de démarrer une session sans qu’un démon privilégié lise en son nom un fichier de mots de passe protégé. Les identifiants basés sur un fichier n’ont pas leur place dans ce modèle, car aucun démarrage côté démon ne les lirait. Le refus est une conséquence de l’architecture, pas une fonctionnalité manquante.

L’ancien schéma mérite d’être nommé pour être plus facile à désapprendre : un profil référence un fichier d’identifiants, et le démon le lit au démarrage du tunnel. Dans le nouveau modèle, les identifiants appartiennent à une session et sont fournis au début de cette session. openvpn3 session-start --config work.ovpn les demande, et --auth-user-pass creds.txt est rejeté car rien sur ce chemin n’ouvrirait le fichier. Chaque recette 2.x que vous trouverez suppose une étape qui n’existe plus.

La configuration et les réglages locaux au site sont eux aussi séparés, ce qui explique une seconde surprise. Un profil peut sembler complet alors que la connexion qu’il produit manque de configuration de routage et de résolution. Ces pièces sont appliquées comme réglages locaux au site, séparément du fichier importé.

Le chemin de l’invite et la session qu’il laisse

Fournir le mot de passe au démarrage de la session est le flux de travail prévu. Le client demande une fois, remet les identifiants au backend de session et poursuit :

openvpn3 session-start --config work.ovpn
openvpn3 sessions-list

Par ce chemin, rien n’est écrit sur le disque. La session continue aussi de tourner après la fermeture du terminal, ce qui surprend ceux qui attendent que le processus meure avec leur shell. C’est précisément l’intérêt de déplacer la gestion des sessions dans un service. La session survit au terminal qui l’a demandée, et il faut l’arrêter explicitement.

Pour un poste de travail avec un humain devant, c’est aussi l’option la plus sûre, car il n’y a aucun secret stocké à protéger ou à oublier. Elle n’est inadaptée que là où personne n’est présent pour taper.

Automatiser sans personne au clavier

Là où une machine doit se connecter sans personne, le projet fournit openvpn3-autoload. Il lit un répertoire de profils et un descripteur correspondant par profil, et le descripteur fournit les identifiants en texte clair. L’assistant est un binaire distinct, généralement à /usr/sbin/openvpn3-autoload, pas une option de session-start. Le configurer suppose de créer le répertoire, de copier le profil sous le nom attendu par le descripteur et d’écrire le descripteur.

Une installation par utilisateur ressemble à ceci, exécutée avec le compte qui possédera la session. Le mode du répertoire tient les autres utilisateurs locaux à l’écart :

mkdir -m700 -p ~/.openvpn3/autoload
cp work.ovpn ~/.openvpn3/autoload/client.conf
$EDITOR ~/.openvpn3/autoload/client.autoload

Le descripteur nomme les identifiants et demande un démarrage automatique. Gardez la valeur du mot de passe hors du contrôle de version :

{
  "autostart": true,
  "user-auth": {
    "autologin": true,
    "username": "svc-vpn",
    "password": "change-this-value"
  }
}

Appelez ensuite l’assistant une fois et confirmez que la session apparaît. La seconde commande est la vérification, pas une étape de configuration de plus :

/usr/sbin/openvpn3-autoload --directory ~/.openvpn3/autoload
openvpn3 sessions-list

Au démarrage, une unité empaquetée nommée openvpn3-autoload.service utilise le répertoire à l’échelle du système /etc/openvpn3/autoload, et non celui de chaque utilisateur. Cet emplacement exige la propriété de root et un mode plus strict, et le descripteur contient toujours le mot de passe en clair. Le compromis est explicite : le mot de passe réside désormais sur le disque, alors traitez ce répertoire comme un secret, excluez-le des sauvegardes hors de l’hôte, et choisissez le chemin interactif dès qu’une personne est présente.

Des pannes de bus qui ressemblent à des pannes de mot de passe

Certaines pannes attribuées aux identifiants n’en sont pas. Une erreur de permission nommant le chemin d’activation du service signifie l’une de deux choses : le backend n’est pas démarré, ou l’appelant n’a pas la permission de l’activer. Aucune modification de profil ne changera l’une ou l’autre. Vérifiez l’état du service et la politique de bus fournie avant de toucher à la configuration.

Les commandes ci-dessous séparent les deux. La première indique si le backend tourne ; la seconde montre les erreurs de bus récentes :

systemctl status openvpn3-service-client
journalctl -b -u openvpn3-service-client --no-pager | tail -20

L’autre mauvaise lecture fréquente est une session qui apparaît puis disparaît aussitôt. Ce schéma signifie généralement que les réglages locaux au site n’ont jamais été appliqués, si bien que le tunnel est monté sans les changements de routage et de résolution qui le rendent utile. Lisez la séquence plutôt que la dernière ligne : la session a-t-elle été créée, a-t-elle atteint un état connecté et a-t-elle survécu sont trois faits distincts.

Quand l’ancien client est encore utilisé

Le client 2.x accepte encore un fichier d’identifiants, et un trousseau de clés peut répondre à son invite sans que le secret n’atteigne jamais le disque. Un enrobage résout l’entrée, si bien que le fichier nomme la recherche plutôt que le mot de passe. Cet arrangement dépend d’un trousseau déverrouillé, ce qu’un conteneur sans session de connexion ou une unité qui démarre avant que quiconque ne se connecte ne peuvent fournir. L’outil de recherche signale alors une collection dans laquelle il ne peut pas écrire, si bien que l’erreur ressemble à une panne d’identifiants alors qu’il s’agit d’une panne de trousseau.

Avant de construire quoi que ce soit de tout cela, vérifiez si un réglage keepalive du profil supprime entièrement le besoin de redémarrer. Une session qui reste montée n’atteint jamais l’invite que vous cherchez à automatiser.