Keyfile o Netplan: dove viene davvero salvato il profilo VPN?
Una VPN salvata può vivere in un keyfile o in un file Netplan generato. Abbinate l’UUID della connessione al suo vero proprietario prima di modificare qualcosa che viene riscritto.
Trovare il file importato è la parte facile e spesso l’inizio sbagliato. Ciò che conta è quale file NetworkManager legge oggi come connessione salvata, e questo dipende da un identificatore di connessione e dal backend di configurazione che i pacchetti installati usano davvero. Modificare l’importazione prima di rispondere a questa domanda è il modo in cui una VPN funzionante diventa due configurazioni mezze corrette.
Il file importato non è il profilo salvato
Tre nomi aleggiano intorno a ogni problema VPN: il nome della connessione, il nome del file importato e l’interfaccia virtuale che appare quando il tunnel sale. Nessuno di essi identifica la configurazione salvata, e il nome di una connessione può essere modificato mentre il file che c’è dietro conserva il suo identificatore originale.
Iniziate con un inventario in sola lettura e scegliete la VPN desiderata per identificatore invece che per etichetta:
nmcli -f NAME,UUID,TYPE connection show
Tenete i nomi host degli endpoint e le etichette di identità fuori da qualsiasi inventario incollato in un ticket. La parte utile è il tipo e l’identificatore; il resto è contesto che uno sconosciuto non ha bisogno di conoscere. Oscurate il resto prima di condividere e dite di averlo fatto, così nessuno si chiede cosa significhino gli spazi vuoti.
Le posizioni del keyfile non significano la stessa cosa
Con il plugin keyfile nativo, i file di connessione possono comparire in tre directory, e la differenza tra loro è la persistenza, non la comodità.
| Location | Role |
|---|---|
/etc/NetworkManager/system-connections/ | Administrator-owned persistence |
/usr/lib/NetworkManager/system-connections/ | Package-supplied defaults, replaced on upgrade |
/run/NetworkManager/system-connections/ | Runtime state, regenerated and not durable |
Modificare la copia di runtime sembra riuscire fino al successivo avvio, quando la modifica evapora e il file appare misteriosamente ripristinato. Modificare la copia fornita dal pacchetto funziona finché un aggiornamento non la sostituisce, che è una versione più lenta e confusa della stessa lezione.
La documentazione del keyfile aggiunge un dettaglio da rispettare: quei file possono contenere chiavi private e passphrase, e NetworkManager ignora qualsiasi keyfile che utenti diversi da root possano leggere o scrivere. Ampliare i permessi della directory per cercare un’impostazione rompe il comportamento di caricamento che stavate cercando di ispezionare.
Quando Netplan possiede la persistenza
Su Ubuntu, l’integrazione NetworkManager descritta nella documentazione di Netplan, disponibile dalla 23.10, cambia dove vive la copia durevole. Per le connessioni non temporanee scrive /etc/netplan/90-NM-<connection UUID>.yaml e genera un profilo NetworkManager effimero sotto /run/NetworkManager/system-connections/.
Questa è un’integrazione di distribuzione, non una regola per ogni installazione di NetworkManager. Confermate che i pacchetti installati la usino davvero prima di andare a cercare un file YAML. Ricordate anche che un profilo di runtime può essere una rappresentazione generata di qualcos’altro invece che la fonte che vale la pena modificare. Due comandi di verifica risparmiano un’ora di modifiche al file sbagliato.
L’esempio documentato salva una connessione OpenVPN tramite il tipo Netplan nm-devices con dati di passthrough di NetworkManager. Il fatto che Netplan non abbia un’interpretazione dedicata di un certo campo VPN non significa che la VPN salvata sia persa; significa che il campo viaggia come dati opachi.
Le interfacce transitorie non sono profili
L’attivazione crea connessioni e interfacce virtuali temporanee che non dovevano mai persistere. L’integrazione deliberatamente non scrive un nuovo file YAML per ciascuna, quindi la loro assenza da /etc/netplan non dice nulla sul fatto che il profilo padre sia salvato.
Se state inseguendo un file che appare e scompare, probabilmente state guardando uno di questi e non la vostra configurazione. Verificate se sopravvive a un riavvio prima di trarre qualsiasi conclusione dal suo contenuto. Un file di runtime che svanisce al riavvio vi dice che non è mai stato la fonte, e quella singola osservazione reindirizza l’intera indagine. Spiega anche perché una modifica sembrava riuscita in quel momento.
Segreti e proprietà
Un profilo può fare riferimento a un certificato o a una chiave conservati altrove, e una password può appartenere a NetworkManager, essere fornita da un agente segreto della sessione utente, o non essere salvata di proposito. Individuare un singolo file risolve quindi ben poco su ciò che richiederà un avvio senza sorveglianza.
Ispezionate i riferimenti e i flag dei segreti senza stampare valori segreti. Un accesso desktop può rendere disponibile un agente che mancava durante il boot, e copiare un file di runtime generato non riproduce quell’agente. Il sintomo pratico è un tunnel che si connette quando una persona accede e fallisce quando la macchina si avvia da sola. Questo schema indica la proprietà dei segreti, non il routing.
Effettuate le modifiche approvate tramite il gestore che possiede la connessione, poi verificate sia l’identificatore salvato sia la connessione effettiva. Mantenete un solo proprietario persistente, perché modificare separatamente l’importazione, un keyfile generato e una fonte YAML lascia tre spiegazioni concorrenti di ciò che userà la prossima riconnessione. Scegliete quella che persiste davvero, modificate solo quella e annotate nel ticket quale file avete trattato come autorevole. La persona successiva vi ringrazierà per una riga di provenienza.