Un profil, deux propriétaires : NetworkManager ou systemd

Rien ne se passe avec un fichier .ovpn tant que rien ne le possède. Sur un bureau Pi, les propriétaires plausibles sont NetworkManager, qui range une connexion importée dans son propre fichier de clés, et une unité de service autonome qui lit une configuration dans un répertoire. Ce sont deux modèles de fonctionnement avec un stockage différent, un traitement différent des identifiants et des règles d'activation différentes. Choisir l'un d'eux délibérément est toute la tâche ; copier le fichier aux deux endroits ne fait que rendre le choix accidentel.

Les deux peuvent fonctionner sur une même machine, mais pas sur le même tunnel au même moment, et le conflit ressemble à une panne réseau plutôt qu'à une panne de configuration.

Deux façons de posséder le même tunnel

Le greffon OpenVPN de NetworkManager ajoute un éditeur et un service qui gèrent la connexion pour vous, et installer le programme OpenVPN n'installe pas cette intégration. Une unité autonome est la disposition inverse : pas d'éditeur, pas d'intégration au bureau, un seul fichier de configuration et les privilèges que l'unité accorde. La première garde l'état de la connexion dans sa propre base de données, la seconde le garde là où le profil et l'unité le disent. L'essentiel de la confusion vient de supposer qu'un profil importé et un fichier copié sont le même objet.

Ce ne sont pas deux vues d'une même chose. Modifier le fichier téléchargé ne change ni ce que NetworkManager a enregistré ni ce que lit l'unité, et l'un ou l'autre peut être celui qui a bâti le tunnel que vous venez de tester.

Suivez la connexion que le bureau utilise réellement

L'opération d'importation documentée, nmcli connection import type openvpn file office.ovpn, crée une connexion via le greffon. Notez son UUID et utilisez cet identifiant ensuite, car les noms sont modifiés et deux connexions peuvent partager une étiquette. nmcli connection show liste ce qui existe, et lire les propriétés de la connexion elle-même vous dit de quel fichier elle vient et ce qu'elle stocke. Si l'UUID que vous modifiez n'est pas celui que le bureau active, vos modifications sont décoratives.

Les secrets vivent dans le stockage du propriétaire. Vider chaque secret enregistré pour savoir quel profil est actif est lent et risqué ; interrogez plutôt l'objet de connexion et gardez le matériel privé là où le propriétaire l'attend.

Une connexion importée n'a pas besoin d'une session graphique pour tourner, mais elle peut encore avoir besoin d'une source d'identifiants. Qu'elle démarre sans surveillance dépend de ses permissions et de ses secrets, pas de la présence du bureau.

Lisez le modèle de l'unité avant de compter dessus

Là où le paquet fournit l'unité client de style upstream, une instance nommée office correspond à %i.conf dans le répertoire configuré de l'unité, qui pour le modèle 2.6 est /etc/openvpn/client. Lisez l'unité installée et tout fichier supplémentaire avant de faire confiance à un exemple de guide, car les distributions déplacent les chemins. Un lancement manuel depuis un terminal ne prouve rien sur la vision que le service a des fichiers, des secrets ou des permissions. La boîte de dialogue de mot de passe du bureau ne prouve pas non plus qu'une unité non interactive dispose d'un moyen approuvé d'obtenir le même mot de passe.

N'accordez à l'unité que ce dont elle a besoin. Assouplir tout le bac à sable du service parce qu'un fichier référencé est illisible échange une petite correction de permission contre une grande exposition, et l'erreur nomme généralement le fichier qui demande attention.

Retirez le doublon sans perdre l'accès

Si les deux propriétaires peuvent démarrer le tunnel, l'un finira par gagner au mauvais moment et les routes et le périphérique du perdant resteront en arrière. Supprimez le doublon accidentel via son propre propriétaire, gardez un chemin de récupération ouvert et confirmez que le propriétaire restant se connecte toujours après un redémarrage. Deux VPN délibérément séparés avec des politiques de routage différentes sont une autre question de conception, pas une permission pour deux chemins de lancement de se disputer une connexion.

Notez ensuite le cycle de vie que vous avez accepté : activation manuelle, connexion, ou démarrage et reconnexion. Vérifiez le point de terminaison enregistré, l'authentification du pair et la ressource que le tunnel est censé atteindre, car réinstaller le bureau ne remplace pas le fait de savoir quelle configuration a tourné.