La tua VPN funziona solo dopo l’accesso per via del portachiavi

Il comando funziona quando hai effettuato l’accesso, quindi lo metti in uno script di avvio e vai a casa. La mattina dopo la macchina è online e il tunnel no. Il mito è che un’invocazione funzionante sia un servizio funzionante. In pratica la differenza è di solito una di due cose: il profilo appartiene alla tua sessione utente invece che al sistema, oppure il segreto viene sbloccato da qualcosa che esiste solo dopo l’accesso. Entrambi funzionano perfettamente in una prova manuale e falliscono esattamente nel momento in cui nessuno guarda.

Perché l’accesso lo fa funzionare

Un accesso grafico avvia un bus di sessione e un agente del servizio dei segreti, ed è lì che molti client orientati al desktop conservano la password del profilo o la passphrase della chiave privata. Un’attivazione che gira come il tuo utente dopo l’accesso può chiedere il segreto a quell’agente e riuscire. La stessa attivazione eseguita da un’unità di avvio non ha sessione, né bus, né agente, quindi la ricerca fallisce o si blocca su un prompt che nessuno vede.

Esegui lo stesso profilo prima e dopo l’accesso e ottieni due esiti diversi da un’unica configurazione. È la firma di una dipendenza dalle credenziali, non di un tunnel rotto, e spiega perché una prova manuale in un terminale dimostra meno di quanto sembri. Il tunnel va bene; manca ciò che sblocca il suo segreto.

Decidi quale proprietario avvia il tunnel

Ci sono due schemi supportati, e mescolarli è l’altro modo in cui questo fallisce. NetworkManager può attivare una connessione a livello di sistema, cosa adatta quando la macchina già centralizza lì la sua rete. In alternativa, un’unità systemd dedicata esegue la VPN direttamente e possiede l’interfaccia.

systemctl list-unit-files 'openvpn*'
systemctl list-unit-files 'wg-quick*'
nmcli connection show --active
systemctl enable --now wg-quick@wg0

Non eseguire entrambi i proprietari sulla stessa configurazione. Se NetworkManager gestisce l’interfaccia e un’unità la alza anche, si scontreranno per rotte e DNS, e lo stato risultante dipende da chi ha finito per ultimo.

Metti il segreto dove un servizio può leggerlo

Un servizio in background non può rispondere a un prompt. Le frasi d’accesso dei certificati, le password degli account e i file di autenticazione referenziati hanno tutti bisogno di una disposizione di archiviazione che l’unità possa raggiungere senza un umano, di proprietà dell’account che esegue il servizio e illeggibile per tutti gli altri.

La scorciatoia tentante è rendere il file leggibile da tutti finché l’errore di permessi non scompare. Questo scambia un fallimento all’avvio con un’esposizione prolungata delle credenziali, ed è il tipo di modifica che nessuno rivede. Usa il meccanismo di cui il deployment si fida già: un file di credenziali limitato, una chiave non cifrata protetta dai permessi del file, o una connessione a livello di sistema con il proprio archivio di segreti.

Testa l’evento che accade davvero

Avviare il servizio manualmente dopo l’accesso non testa quasi nulla. Riavvia, o disabilita l’accesso grafico per un ciclo, e osserva l’unità salire da sola. È l’unico test che esercita insieme disponibilità delle credenziali, prontezza della rete e ordine delle unità. È anche il test che riproduce il guasto segnalato dall’utente, cosa che un avvio manuale non fa mai.

systemctl is-enabled wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager
systemctl status systemd-networkd-wait-online --no-pager

L’ordine conta quanto le credenziali. Un’unità che parte prima che il collegamento ascendente sottostante sia configurato si arrenderà, e alcune distribuzioni differiscono su se attendono la connettività. Se l’unità segnala un guasto all’avvio ma riesce quando la avvii a mano trenta secondi dopo, hai trovato un problema di ordine e non un problema di segreto.

Verifica rotte e DNS, non solo l’interfaccia

Un’interfaccia che esiste non è un tunnel funzionante. Dopo un avvio non presidiato, controlla le rotte, lo stato del resolver e una destinazione per indirizzo prima di controllare un nome. Poi controlla l’applicazione per cui il tunnel esiste.

ip -4 route show
resolvectl status
ping -c 3 10.61.0.1
curl -sS --max-time 5 https://internal.example/ -o /dev/null -w '%{http_code}\n'

Se l’indirizzo funziona e il nome no, il problema rimanente è la politica DNS e non il tunnel. Annota quale proprietario avvia il servizio e dove vive il segreto, perché la prossima persona che riavvierà questa macchina avrà bisogno di entrambi i fatti.