OpenVPN: il bind locale fallisce all'avvio — attendere o riprovare

Per un server OpenVPN che non si avvia al boot vengono proposte due soluzioni: attendere l'indirizzo o lasciare che il servizio riprovi finché il bind riesce. Entrambe affrontano lo stesso sintomo con un comportamento di errore diverso. L'attesa codifica un prerequisito preciso e fallisce rumorosamente quando manca; il nuovo tentativo nasconde il prerequisito e continua a provare. Quale delle due appartiene alla vostra unit dipende dal fatto che quell'indirizzo sia una dipendenza progettata o un caso del timing.

Entrambe sono meglio di uno sleep fisso, che non attende nulla e non riporta cosa stava attendendo.

Che cosa richiede davvero l'opzione local

local nomina l'indirizzo a cui il demone associa il proprio socket, e associarsi a un indirizzo che non esiste ancora fallisce subito con un errore sull'indirizzo richiesto. Quando l'opzione manca, il demone ascolta su tutti gli indirizzi, per questo lo stesso profilo funziona su una macchina la cui interfaccia non è ancora salita: ascolta ovunque invece che sull'unico indirizzo che avete nominato. Questa differenza è tutto l'errore, e resta invisibile fino a un riavvio.

Il requisito non è che l'interfaccia sia attiva in senso generale. L'indirizzo deve essere assegnato all'interfaccia corretta nel momento del bind, e deve essere l'interfaccia sottostante, non un tunnel che lo stesso demone creerebbe più tardi. Un controllo fatto pochi minuti dopo l'accesso non prova nulla sulla sequenza di boot.

Attendere l'indirizzo o riprovare il bind

Attendere significa un ExecStartPre che interroga finché l'indirizzo compare, con un numero limitato di tentativi e un'uscita diversa da zero quando il tempo scade. Riprovare significa lasciare che il processo principale fallisca e chiedere al gestore dei servizi di riavviarlo, per esempio Restart=on-failure con RestartSec=5. Il primo segnala un prerequisito mancante come unit fallita, mentre il secondo lo segnala come una serie di riavvii che alla fine si ferma, il che è più rumoroso nel journal ma sopravvive a un indirizzo che arriva tardi per ragioni che non potete prevedere.

Preferite l'attesa quando l'indirizzo è una dipendenza progettata, e il nuovo tentativo quando l'indirizzo di solito compare ma il suo timing varia. Combinarli è ragionevole: un'attesa limitata copre il caso comune e una politica di riavvio l'eccezione. Ciò che nessuno dei due dovrebbe fare è girare all'infinito, perché un'unit che riprova senza fine nasconde una configurazione errata invece di segnalarla.

Perché network-online.target non basta

network-online.target promette ciò che l'implementazione di rete attiva intende per online, e nulla di più. Con systemd-networkd, systemd-networkd-wait-online decide quando quella destinazione è raggiunta, e la sua nozione predefinita di online può essere soddisfatta prima che esista il vostro indirizzo specifico. Sotto NetworkManager, il servizio wait-online applica le proprie regole. Ordinare dopo la destinazione è una base solida, non una garanzia che un indirizzo, una risposta DNS o un peer remoto sia pronto.

Lo stesso ragionamento esclude le alternative abituali. Una voce di avvio automatico del desktop attende una sessione utente che su un server potrebbe non aprirsi mai, e un comando cron ritardato aggiunge tempo trascorso senza nominare la risorsa di cui sperava la comparsa. Entrambe possono sembrare riuscite per mesi e poi fallire all'unico boot che conta.

Controllate il bind dopo un avvio a freddo

Verificate con un vero avvio a freddo invece che con un riavvio del servizio, perché un riavvio eredita un indirizzo che la sequenza di boot ha dovuto creare. Dopo l'avvio, ss -lntp o ss -lunp mostra l'indirizzo locale a cui ogni listener si è effettivamente associato, e journalctl -b -u openvpn-server@server mostra se il primo tentativo è fallito. Confrontate l'indirizzo associato con quello nel profilo, poi ripetete il confronto dopo una riconnessione di rete.

Se il profilo non ha mai avuto bisogno di un indirizzo fisso, rimuovere local è una semplificazione legittima, ma fatene una decisione di sicurezza invece di un'abitudine di troubleshooting.

Ampliare il listener cambia chi può raggiungerlo, quindi abbinate questo cambiamento alla politica di firewall che avrebbe dovuto limitarlo. Un servizio che si avvia in modo affidabile su ogni interfaccia non ha risolto il problema originale; ha spostato il problema al bordo della rete.