Elenco VPN con nmcli: profili salvati e tunnel attivi

Eseguite nmcli connection show aspettandovi un elenco di VPN e ottenete ogni connessione che la macchina abbia mai salvato, compresi un bridge e un hotspot. Il VPN che cercate può essere lì, può essere tipizzato diversamente da vpn, oppure non essere affatto una connessione NetworkManager. Sapere in quale di questi tre casi vi trovate richiede due comandi.

Due elenchi, due domande

connection show risponde a cosa ha salvato NetworkManager, e connection show --active risponde a cosa è attualmente collegato a un dispositivo. Il primo elenco include profili inattivi, ed è deliberato: un VPN salvato che è giù resta un profilo che potreste dover sistemare. Confondere i due dà l’impressione che un tunnel sia in funzione quando esiste solo la sua configurazione.

Scegliete i campi invece di leggere la tabella predefinita, perché l’output predefinito nasconde il tipo sui terminali stretti e manda a capo i nomi lunghi.

NAME, UUID e TYPE di solito bastano per un primo passaggio, poi ispezionate l’unica voce che vi interessa tramite UUID.

TYPE è dove stanno le sorprese

OpenVPN le connessioni gestite dal plugin compaiono come tipo vpn, perché il plugin è un servizio dentro il quadro VPN generico. Il supporto nativo di WireGuard è un tipo di connessione a sé stante, quindi un filtro su vpn non lo troverà. Una ricerca di un tunnel WireGuard che non restituisce nulla è di solito un problema di filtro e non un profilo mancante. È una differenza architetturale, non una stranezza di denominazione.

Lo stesso vale per altri tipi di tunnel che NetworkManager ha imparato a gestire nativamente nel tempo, quindi leggete la colonna TYPE prima di concludere che manchi qualcosa.

Elencate tutto e filtrate dopo, e il profilo compare.

Leggete l’UUID, non solo il nome

I nomi sono etichette che le persone modificano, e due profili possono condividerne uno dopo un’importazione distratta. L’UUID è l’identità a cui fanno riferimento comandi e file. Quando una voce sembra duplicata, confrontate l’UUID e le impostazioni sottostanti prima di eliminare qualcosa.

I comandi di attivazione accettano entrambi, ed è proprio per questo che un’abitudine basata sul nome finisce per modificare il profilo sbagliato.

Copiate l’UUID nelle vostre note quando cambiate qualcosa che potreste dover annullare.

Cosa un profilo salvato non vi dice

Un profilo salvato non dice nulla sul fatto che il suo tunnel sia su, e una connessione attiva non dice nulla sul fatto che il traffico al suo interno funzioni. Un tunnel avviato da wg-quick o da un’unità di servizio non è affatto una connessione NetworkManager, quindi manca da entrambi gli elenchi mentre l’interfaccia chiaramente passa traffico. Controllate l’interfaccia e la tabella di routing prima di supporre che il profilo manchi. Un elenco vuoto dimostra solo che NetworkManager non è il proprietario.

Due gestori per la stessa interfaccia è l’altra versione di questo problema, e produce un elenco che sembra corretto mentre lo stato del kernel è di qualcos’altro.

Un solo proprietario per interfaccia tiene l’elenco onesto, e la riferimento nmcli documenta quali campi ogni vista riporta realmente.

Riferite senza divulgare segreti

connection show con un nome stampa le impostazioni, e aggiungere --show-secrets stampa le chiavi private e le password insieme a esse. Per incollare una diagnosi in un ticket non servono. Riferite invece il tipo, l’UUID, lo stato e le rotte pertinenti, e oscurate tutto ciò che proviene da un archivio di segreti.

L’attivazione interattiva con --ask è il modo supportato per fornire una credenziale mancante, e l’automazione senza supervisione richiede un’altra disposizione approvata invece di una password salvata in chiaro.

Un rapporto breve e oscurato è più facile da rivedere di un dump completo.