Stesso profilo, due sessioni: si connette dal desktop e si blocca via SSH su una richiesta a cui nulla può rispondere. Niente è rotto e nessuna impostazione è andata persa. NetworkManager chiede la credenziale a un agente dei segreti, e un agente dei segreti è un componente desktop che non esiste nella sessione che stai usando.

Esegui la sequenza qui sotto e il tunnel si alza senza interfaccia grafica, con l'avvertenza che memorizzare un segreto cambia chi può usare quel profilo.

Conferma la diagnosi prima di modificare qualsiasi cosa

La differenza tra attivazione interattiva e non interattiva è tutta la diagnosi. Se nmcli --ask connection up riesce mentre un'attivazione normale si blocca, il profilo è corretto e manca l'origine del segreto. Quell'unico confronto ti risparmia di riscrivere una configurazione che funziona.

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office IPsec" | grep -i flags

Leggi i flag invece di indovinarli. I valori che significano "chiedi a un agente" sono quelli che cerchi, e i nomi esatti delle chiavi variano tra i plugin VPN perché vivono nel dizionario dati del plugin stesso. Un profilo FortiSSL e un profilo IPsec non usano necessariamente gli stessi nomi, quindi parti dall'output del tuo profilo.

Verifica anche che il pacchetto del plugin per quel protocollo sia installato. Un plugin mancante si presenta come un tipo di connessione sconosciuto o come un errore di attivazione che non dice nulla sulle password, e inseguire il segreto in quello stato spreca la stessa ora due volte. Una sola interrogazione dei pacchetti costa meno di un intero pomeriggio passato a modificare file di chiavi.

Sposta il segreto nel file delle chiavi

Il file di connessione vive sotto /etc/NetworkManager/system-connections/. I segreti non vengono conservati lì per impostazione predefinita, ed è proprio il senso dei flag che hai appena letto. Portare un flag a zero dice a NetworkManager che il valore è memorizzato con il profilo invece di essere richiesto al momento dell'attivazione.

[vpn]
password-flags=0

[vpn-secrets]
password=YOUR-VPN-PASSWORD

Per un profilo con due segreti lo schema si ripete: un flag per segreto nella sezione [vpn], e i valori in [vpn-secrets]. Un profilo IPsec di solito porta una chiave precondivisa accanto alla credenziale utente, e il plugin le nomina diversamente da un normale campo password, quindi copia i nomi delle chiavi dall'output di vpn.data invece che da un post di blog che usava un altro plugin. Un solo nome di chiave sbagliato produce un profilo che si carica e poi fallisce l'autenticazione, cosa che si legge esattamente come una password errata. Confronta il tuo file con un profilo funzionante dello stesso plugin prima di riconnetterti.

Metti tra virgolette i valori che contengono spazi, virgolette o un segno di dollaro. Un valore senza virgolette con dentro $ verrà letto letteralmente o espanso a seconda di dove viene analizzato, e il conseguente errore di autenticazione sembra una password sbagliata.

Poi sistemare proprietà e modo del file. Questi file di chiavi sono letti da un servizio privilegiato, e un file che altri utenti possono leggere viene considerato inaffidabile, che è il motivo abituale per cui un profilo modificato sembra ignorato. Proprietario root, modo 600, nessuna eccezione.

Ricarica, poi attiva

Il file viene letto quando la connessione viene caricata, quindi modificarlo non basta. Ricarica i profili e poi alza la connessione in modo esplicito.

sudo nmcli connection reload
sudo nmcli connection up "Office IPsec"

Se il ricaricamento non recepisce la modifica, un riavvio completo del servizio lo fa, e ci sono resoconti esattamente di questo. Preferisci il ricaricamento quando contano altri collegamenti, perché riavviare il servizio interrompe ogni connessione gestita, e su un host remoto questo può terminare la tua sessione prima che il tunnel desiderato sia su.

Usa l'UUID quando i nomi sono ambigui. Le macchine con più profili client accumulano quasi-duplicati, e attivare quello sbagliato produce un guasto che sembra un problema di credenziali.

Quando il segreto memorizzato non è il problema

Un profilo FortiSSL può fallire anche con una credenziale memorizzata corretta perché il client non si fida mai del certificato del gateway. Quell'impostazione non è nella finestra principale; sta dietro le opzioni avanzate della VPN, dove si inserisce il digest del certificato attendibile. Se il log menziona il certificato invece della password, sei in questo ramo e nessuna modifica di [vpn-secrets] aiuterà.

Qui rientrano altri due controlli. Verifica che il profilo non sia stato importato da un file che punta ancora a un percorso che il plugin non può leggere, e verifica che il profilo sia quello attivo e non un duplicato obsoleto. Entrambi producono guasti di attivazione che si leggono come errori di autenticazione.

Decidi se memorizzare è accettabile

Una PSK e una password memorizzate sono leggibili da qualsiasi cosa giri come root su quella macchina. Su una macchina che controlli è uno scambio ragionevole per un servizio senza interfaccia. Su un host condiviso merita una conversazione, perché il profilo ora contiene una credenziale che prima era protetta dal portachiavi del desktop. Chiedi chi altro può arrivare a root su quell'host prima di decidere, non dopo che la modifica è in vigore.

Se la policy vieta di memorizzare segreti VPN, non indebolire il profilo per far funzionare un'attività cron. Esegui la connessione da una sessione che ha un agente, oppure usa un altro meccanismo per l'automazione.

Infine, annota quali profili portano segreti così che nessuno ne copi uno su un portatile senza accorgersene. Un commento sopra la sezione dei segreti con la data e il motivo basta, e risparmierà a qualcuno una revisione imbarazzante più avanti.

Articoli correlati