Llista de VPN amb nmcli: perfils desats enfront de túnels actius

Executeu nmcli connection show esperant una llista de VPN i obteniu totes les connexions que la màquina ha desat mai, incloent-hi un bridge i un punt d’accés. La VPN que busqueu pot ser-hi, pot ser d’un tipus diferent de vpn o pot no ser cap connexió del NetworkManager. Saber en quin d’aquests tres casos esteu requereix dues ordres.

Dues llistes, dues preguntes

connection show respon què ha desat el NetworkManager, i connection show --active respon què està connectat ara a un dispositiu. La primera llista inclou perfils inactius, i això és deliberat: una VPN desada que està caiguda continua sent un perfil que potser haureu d’arreglar. Confondre les dues dona la impressió que un túnel funciona quan només existeix la seva configuració.

Trieu camps en lloc de llegir la taula per defecte, perquè la sortida per defecte amaga el tipus en terminals estrets i parteix els noms llargs.

NAME, UUID i TYPE solen ser tot el que cal en una primera passada, i després inspeccioneu l’única entrada que us interessa per UUID.

TYPE és on són les sorpreses

OpenVPN les connexions gestionades pel connector apareixen com a tipus vpn, perquè el connector és un servei dins del marc genèric de VPN. El suport natiu de WireGuard és un tipus de connexió de primera classe per si mateix, així que filtrar per vpn no el trobarà. Una cerca d’un túnel WireGuard que no retorna res sol ser un problema de filtre i no un perfil que falta. Això és una diferència arquitectònica, no una raresa de nomenclatura.

El mateix passa amb altres tipus de túnel que el NetworkManager ha après a gestionar de manera nativa amb el temps, així que llegiu la columna TYPE abans de concloure que hi falta alguna cosa.

Llista-ho tot i filtra després, i el perfil apareix.

Llegiu l’UUID, no només el nom

Els noms són etiquetes que la gent edita, i dos perfils poden compartir-ne un després d’una importació descurada. L’UUID és la identitat a què fan referència les ordres i els fitxers. Quan una entrada sembla duplicada, compareu l’UUID i la configuració subjacent abans d’esborrar res.

Les ordres d’activació accepten qualsevol dels dos, i per això mateix un costum basat en el nom acaba modificant el perfil equivocat.

Copieu l’UUID a les vostres notes quan canvieu una cosa que potser haureu de desfer.

Què no us diu un perfil desat

Un perfil desat no diu res sobre si el seu túnel està aixecat, i una connexió activa no diu res sobre si el trànsit que hi passa funciona. Un túnel iniciat per wg-quick o per una unitat de servei no és cap connexió del NetworkManager, així que falta a les dues llistes mentre la interfície clarament hi passa trànsit. Comproveu la interfície i la taula d’encaminament abans de suposar que el perfil falta. Una llista buida només demostra que el NetworkManager no n’és el propietari.

Dos gestors per a la mateixa interfície és l’altra versió d’aquest problema, i produeix una llista que sembla correcta mentre l’estat del nucli pertany a una altra cosa.

Un propietari per interfície manté la llista honesta, i la referència d’nmcli documenta quins camps informa realment cada vista.

Informeu sense filtrar secrets

connection show amb un nom imprimeix la configuració, i afegir --show-secrets imprimeix les claus privades i les contrasenyes amb ella. Per enganxar una diagnosi en un tiquet no calen. Informeu en canvi del tipus, l’UUID, l’estat i les rutes rellevants, i redacteu tot el que provingui d’un magatzem de secrets.

L’activació interactiva amb --ask és la manera admesa de proporcionar una credencial que falta, i l’automatització sense supervisió necessita un altre acord aprovat en lloc d’una contrasenya desada en text pla.

Un informe curt i redactat és més fàcil de revisar que un bolcat complet.