Liste VPN avec nmcli : profils enregistrés et tunnels actifs

Vous lancez nmcli connection show en attendant une liste de VPN et vous obtenez toutes les connexions que la machine a jamais enregistrées, y compris un pont et un point d’accès. Le VPN que vous cherchez est peut-être là, peut-être typé autre chose que vpn, ou peut-être pas du tout une connexion NetworkManager. Savoir dans lequel de ces trois cas vous êtes demande deux commandes.

Deux listes, deux questions

connection show répond à ce que NetworkManager a enregistré, et connection show --active répond à ce qui est actuellement attaché à un appareil. La première liste inclut les profils inactifs, et c’est délibéré : un VPN enregistré qui est arrêté reste un profil qu’il faudra peut-être réparer. Confondre les deux donne l’impression qu’un tunnel tourne alors que seule sa configuration existe.

Choisissez des champs plutôt que de lire le tableau par défaut, car la sortie par défaut masque le type sur les terminaux étroits et replie les noms longs.

NAME, UUID et TYPE suffisent généralement pour un premier passage, puis vous inspectez la seule entrée qui vous intéresse par UUID.

TYPE est là où se trouvent les surprises

OpenVPN les connexions gérées par le greffon apparaissent avec le type vpn, car le greffon est un service à l’intérieur du cadre VPN générique. La prise en charge native de WireGuard est un type de connexion à part entière, donc un filtre sur vpn ne la trouvera pas. Une recherche de tunnel WireGuard qui ne renvoie rien est généralement un problème de filtre et non un profil manquant. C’est une différence d’architecture, pas une bizarrerie de nommage.

Il en va de même pour les autres types de tunnel que NetworkManager a appris à gérer nativement au fil du temps, alors lisez la colonne TYPE avant de conclure que quelque chose manque.

Listez tout et filtrez ensuite, et le profil apparaît.

Lisez l’UUID, pas seulement le nom

Les noms sont des étiquettes que les gens modifient, et deux profils peuvent en partager un après un import négligent. L’UUID est l’identité à laquelle les commandes et les fichiers se réfèrent. Quand une entrée semble en double, comparez l’UUID et les paramètres sous-jacents avant de supprimer quoi que ce soit.

Les commandes d’activation acceptent l’un ou l’autre, et c’est précisément pourquoi une habitude fondée sur le nom finit par modifier le mauvais profil.

Copiez l’UUID dans vos notes quand vous modifiez quelque chose que vous devrez peut-être annuler.

Ce qu’un profil enregistré ne vous dit pas

Un profil enregistré ne dit rien sur l’état de son tunnel, et une connexion active ne dit rien sur le fonctionnement du trafic à l’intérieur. Un tunnel lancé par wg-quick ou par une unité de service n’est pas du tout une connexion NetworkManager, il manque donc dans les deux listes alors que l’interface fait clairement passer du trafic. Vérifiez l’interface et la table de routage avant de supposer que le profil est absent. Une liste vide prouve seulement que NetworkManager n’est pas le propriétaire.

Deux gestionnaires pour la même interface est l’autre version de ce problème, et cela produit une liste qui semble correcte alors que l’état du noyau appartient à autre chose.

Un seul propriétaire par interface garde la liste honnête, et la référence nmcli documente les champs que chaque vue rapporte réellement.

Rapportez sans divulguer de secrets

connection show avec un nom imprime les paramètres, et ajouter --show-secrets imprime les clés privées et les mots de passe avec eux. Un copier-coller de dépannage dans un ticket n’en a pas besoin. Rapportez plutôt le type, l’UUID, l’état et les routes pertinentes, et masquez tout ce qui vient d’un magasin de secrets.

L’activation interactive avec --ask est le moyen pris en charge de fournir un identifiant manquant, et l’automatisation sans surveillance exige un autre arrangement approuvé plutôt qu’un mot de passe enregistré en clair.

Un rapport court et masqué est plus facile à relire qu’un vidage complet.