Perché un servizio VPN avviato al boot non riesce a leggere il tuo portachiavi
Un VPN all’avvio non ha alcun agente dei segreti sbloccato da cui prendere in prestito. Leggi i flag dei segreti della connessione prima di reimpostare una password che il server non ha mai rifiutato.
Una connessione che funziona dopo l’accesso e fallisce prima significa di solito che il tentativo all’avvio non è riuscito a ottenere un segreto, non che il server ne abbia rifiutato uno. La credenziale esiste; il contesto che la chiede no. Questa sola distinzione risparmia una reimpostazione della password inutile.
Segui la richiesta: qualcosa avvia la connessione prima che esista una sessione desktop, e il deposito dei segreti che normalmente risponde non è ancora sbloccato. I due contesti non concordano su chi possiede il segreto, e il profilo registra quale dei due dovrebbe fornirlo.
Cosa chiede davvero il percorso di avvio
All’avvio, NetworkManager parte come servizio di sistema senza sessione utente, senza D-Bus di sessione e senza portachiavi sbloccato. Un profilo di connessione può comunque essere alzato, ma solo con segreti che il servizio riesca a raggiungere da solo. Tutto ciò che appartiene a un agente dei segreti resta in attesa finché una persona non accede e l’agente non compare. Il servizio fa esattamente ciò che dice la sua configurazione; è il profilo che deve cambiare.
Il guasto è scritto nella connessione, non nascosto in un portachiavi.
Leggere i flag dei segreti su una connessione
Chiedi alla connessione cosa si aspetta, non cosa ricorda il desktop. La colonna dei flag risponde direttamente alla domanda, e sopravvive ai riavvii nel file di profilo sul disco.
Inizia dall’elenco dei profili, poi conferma quale connessione è impostata per alzarsi da sola. Poi esporta una connessione e leggi i flag della password:
nmcli -f NAME,UUID,TYPE,AUTOCONNECT connection show nmcli connection show "Work VPN" | grep -i -E "password|secret|key" journalctl -b -u NetworkManager --grep "secret"
Il primo comando conferma quali profili esistono e se uno è impostato per la connessione automatica, che è come inizia un tentativo senza sorveglianza. Il secondo espone i valori dei flag, e il terzo mostra il servizio che si lamenta che nessun agente ha risposto per un dato segreto. Una riga di log che nomina un segreto come appartenente a un agente è tutta la diagnosi in una frase.
| Flag value | Where the secret lives | Behaviour before login |
|---|---|---|
| 0 | Stored in the connection profile | Available to the system service |
| 1 | Owned by a secret agent | Blocks until the agent is unlocked |
| 2 | Never stored | Prompts on every activation |
| 4 | Not required | Never requested at all |
Perché spostare la connessione nell’ambito di sistema cambia la risposta
Una connessione posseduta da un utente viene attivata sotto l’agente di quell’utente, per questo funziona perfettamente appena il desktop è su. Spostarla nell’ambito di sistema toglie l’agente dal percorso, quindi lo stesso profilo si comporta diversamente senza cambiare una sola riga di configurazione VPN.
Questo spostamento è un progetto legittimo, e porta con sé un requisito: il segreto deve essere raggiungibile dal servizio di sistema. Conservarlo nel profilo, fornirlo tramite una credenziale di ambito di sistema o accettare una richiesta interattiva al momento giusto sono tutte risposte valide. Lasciare il flag 1 e sperare, no.
Una chiave privata con la propria passphrase aggiunge un secondo strato. Neanche una password di account memorizzata sbloccherà una chiave che richiede una passphrase, quindi verifica quale segreto chiede davvero la fase che fallisce prima di cambiare qualsiasi cosa.
Cosa non fare e cosa fare invece
Rendere ogni file di credenziali leggibile da tutti, o disattivare l’autenticazione perché non serva alcuna richiesta, scambia un fastidio all’avvio con un’esposizione permanente. Entrambi nascondono anche la dipendenza invece di risolverla, e il prossimo aggiornamento dell’immagine reintroduce lo stesso guasto.
Usa in quella fase il meccanismo che la tua distribuzione documenta per l’attivazione senza sorveglianza, poi conferma che i flag del profilo corrispondano. Controlla il risultato da un avvio pulito, non da una shell che ha già un agente. Annota il proprietario della connessione, la fonte del segreto e la fase che deve funzionare, così che un cambiamento successivo dell’avvio automatico non possa reintrodurre silenziosamente una dipendenza dal fatto che qualcuno sblocchi prima un desktop. La documentazione è la differenza tra un servizio riparato e uno che si rompe di nuovo il prossimo trimestre.
Prova da un avvio pulito controllato, non da un nuovo tentativo manuale dopo l’accesso. Il nuovo tentativo riesce per la ragione per cui il tentativo all’avvio è fallito, ed è esattamente la prova che un test rapido distrugge.