Les paramètres n'importent pas le .ovpn que la CLI accepte

Le même fichier se connecte depuis un shell et refuse de s'importer dans le panneau du bureau. Cela exclut le serveur, les identifiants et la syntaxe du profil, car le client en ligne de commande a déjà analysé les trois. Reste le chemin du bureau lui-même : les paquets dont il a besoin, le sous-ensemble de directives qu'il comprend et l'objet qu'il écrit sur le disque. Chacun échoue différemment, et les messages pointent rarement le bon.

Trois choses dont la boîte de dialogue a besoin avant d'analyser quoi que ce soit

L'import s'exécute avec les droits de votre utilisateur, donc un fichier dans un répertoire accessible uniquement à root est rejeté avant même que son contenu ne compte. Le panneau ne liste aussi que les types de VPN dont le greffon NetworkManager est installé ; sans le greffon OpenVPN, l'option est absente plutôt que cassée. Enfin, la carte réseau doit être gérée : une interface marquée comme non gérée peut accepter une connexion enregistrée qui ne s'activera jamais. Vérifiez les trois avant de modifier le profil.

Deux commandes règlent la première passe : dpkg -l network-manager-openvpn-gnome pour le greffon et nmcli device status pour l'état de la carte.

Ce que l'importateur jette en silence

La traduction du bureau vise un ensemble fixe de propriétés. Les lignes hors de cet ensemble sont écartées silencieusement, ce qui explique pourquoi le tunnel peut monter avec des parties de la configuration prévue manquantes. Les scripts déclarés avec up, down et script-security disparaissent généralement, tout comme les options de l'interface de gestion et les blocs distants supplémentaires. Une route écrite avec le mot-clé vpn_gateway fait exception : l'importateur veut y une passerelle IPv4 littérale et abandonne avec une erreur plutôt que de supprimer la ligne.

Une route abandonnée a une forme reconnaissable. La connexion s'active, l'interface obtient une adresse et un sous-réseau précis devient inaccessible parce que la route n'est jamais arrivée dans le profil.

Lisez la connexion enregistrée, pas le fichier source

Le résultat faisant autorité d'un import est le fichier de clés, et non le .ovpn que vous avez sélectionné. sudo cat /etc/NetworkManager/system-connections/office.nmconnection montre ce que le panneau a réellement enregistré. Si une route y figure mais manque dans la table active, l'import a réussi et c'est l'activation qui pose problème. Si elle est absente du fichier, l'importateur l'a abandonnée et aucune reconnexion ne la rétablira.

Deux chemins alternatifs évitent la couche de traduction. nmcli connection import type openvpn file ./office.ovpn écrit le même objet et signale des erreurs que le panneau masque.

L'ancien éditeur, lancé avec nm-connection-editor, expose des champs de route que le panneau ne propose pas. Pour les profils qui dépendent de scripts ou de directives non prises en charge, gardez le client en ligne de commande et surveillez-le avec un service à la place, après avoir désactivé la connexion du bureau afin qu'un seul composant possède le tunnel.

Quand l'import fonctionne mais pas l'activation

L'onglet avancé conserve le transport qui a été importé ou choisi en dernier. Un serveur à l'écoute en UDP échoue rapidement quand TCP est sélectionné, et le message ne le dit presque jamais. Une connexion qui doit démarrer sans utilisateur connecté a besoin que son secret soit enregistré pour tous les utilisateurs, ce qui est un réglage différent de l'enregistrer pour cette session seulement.

Quand la boîte de dialogue n'apporte rien d'utile, journalctl -u NetworkManager -b montre pourquoi l'activation a échoué. Le client shell ne touche jamais ce chemin, ce qui explique qu'il continue de fonctionner alors que la copie du bureau ne le fait pas.

En dernier recours, comparez la version du greffon avec celle de la distribution. Un greffon qui ne correspond pas peut s'installer proprement et refuser quand même d'activer un profil que nmcli importe sans se plaindre.