OpenVPN all’avvio su Ubuntu: NetworkManager o systemd?

La maggior parte delle guide presenta la scelta come cosmetica: o lasciate che NetworkManager alzi il tunnel, oppure abilitate un’istanza systemd e avete finito. I due percorsi differiscono in una cosa che decide il risultato su una macchina senza schermo, e non ha nulla a che vedere con quale strumento sia più recente. NetworkManager sblocca i segreti tramite una sessione; un’istanza systemd non ha alcuna sessione da sbloccare. Scegliete quella il cui trattamento dei segreti corrisponde alla macchina che avete davanti.

Tutto il resto, dall’installazione delle rotte al comportamento di riconnessione, deriva da quella prima decisione.

Il portachiavi è la differenza di cui nessuno parla

Quando NetworkManager possiede un profilo VPN, la password può risiedere nel portachiavi di accesso, che viene sbloccato quando un utente effettua l’accesso. Funziona bene su un portatile: la persona è presente, il portachiavi si apre, il tunnel si alza. Su un server che si avvia senza supervisione non c’è nessuno a sbloccare nulla, quindi il profilo attende un segreto che non arriva mai. La connessione sembra configurata e non si attiva mai.

L’istanza systemd evita questo problema leggendo un file di credenziali dal disco, il che rende il file ciò che proteggete. chmod 400 più la proprietà di root è il minimo, e il file dovrebbe restare fuori dai backup e dai modelli di immagine che non controllate.

Collegare la VPN a una connessione non garantisce l’avvio

In nm-connection-editor, selezionate la connessione cablata o wireless anziché la VPN, aprite la scheda General, spuntate l’opzione per connettersi automaticamente a una VPN e nominate il profilo. NetworkManager attiva quindi la VPN come connessione secondaria quando quella primaria raggiunge lo stato connesso. È una dipendenza, non una regola del firewall. I pacchetti possono ancora uscire nei secondi prima che il tunnel sia attivo, e un segreto memorizzato che non si sblocca lascia la macchina online senza di esso.

Se il requisito è che nulla esca senza il tunnel, ditelo e costruite un kill switch, perché questa impostazione non ne fornirà uno. Provate anche la sospensione e la ripresa, dato che la connessione secondaria viene rivalutata al ritorno.

L’istanza systemd ha bisogno di un nome file che corrisponda

Mettete il profilo nella directory client prevista dal pacchetto, ad esempio /etc/openvpn/client/office.conf, e fate riferimento al file di credenziali dall’interno con auth-user-pass office.cred. Il nome dell’istanza è il nome del file senza il suffisso, quindi openvpn-client@office legge office.conf. Abilitatela con sudo systemctl enable --now openvpn-client@office e confermate la corrispondenza con systemctl cat openvpn-client@office invece di fidarvi di un esempio trovato su un blog.

I percorsi all’interno del profilo vengono risolti rispetto alla directory di lavoro dell’unità, non al profilo stesso, quindi una riga relativa ca o auth-user-pass può fallire all’avvio pur funzionando quando la provate a mano. Usate percorsi assoluti per tutto ciò che l’unità deve trovare. Poi leggete journalctl -u openvpn-client@office -b dopo un avvio reale; un’unità che si dichiara attiva senza tunnel di solito nomina un file mancante in quel registro.

I pacchetti più vecchi forniscono un nome di modello diverso, quindi systemctl list-unit-files 'openvpn*' stabilisce quale esiste su questo host.

Il comportamento di riconnessione è una decisione separata

Un profilo con ping-restart ricostruisce il tunnel dopo che cade, e un’unità con una direttiva di riavvio fa qualcosa di simile a livello di servizio. Sono politiche che scegliete, non valori predefiniti che ereditate. Se la connessione deve salire solo su richiesta, rimuovete deliberatamente il comportamento di riavvio e scrivete perché. Se l’unità si avvia prima che la rete sia utilizzabile, ha bisogno di una politica di nuovi tentativi, perché un tentativo fallito all’avvio non si ripete da solo.

Anche l’arresto è altrettanto letterale: sudo systemctl disable --now openvpn-client@office arresta l’istanza in esecuzione e rimuove il collegamento all’avvio. Disabilitare da solo lascia il tunnel in esecuzione fino al riavvio successivo, il che sorprende chiunque provi disabilitando e guardando l’interfaccia restare attiva.

Riavviate, poi controllate quattro cose in ordine

Riavviare il servizio mette alla prova il servizio; riavviare la macchina mette alla prova il percorso di avvio. Dopo il riavvio, verificate che l’unità sia salita, poi che esista una rotta per la sottorete remota, poi quale indirizzo la macchina presenta a internet, e infine che i nomi si risolvano attraverso il tunnel. Questi quattro controlli falliscono in quest’ordine quando qualcosa non va, il che rende il primo fallimento quello utile.

Un’unità attiva senza rotta di solito significa che il profilo si è connesso ma il server non ha spinto alcuna rotta, oppure che la rotta è stata installata su un’interfaccia scomparsa in seguito. Una rotta senza risoluzione dei nomi funzionante punta alla configurazione DNS, non al tunnel stesso.

Decidete in anticipo cosa deve succedere quando il tunnel non riesce a salire. Tornare alla connettività semplice è una politica, e dovrebbe essere scritta invece di essere lasciata al gestore che è partito per primo.