Perché un'unità VPN parte prima della rete e poi muore

Avviate la macchina, accedete e scoprite che il tunnel è salito e poi è morto pochi secondi dopo. Il profilo era a posto, il certificato era a posto, e l'unica traccia rimasta è il journal di quell'avvio. Quello che di solito è successo è una corsa: l'unità è partita prima che la macchina avesse un indirizzo, e l'ordine che dichiarava non significava ciò che sembra. Tutto quanto segue riguarda il dimostrare quella corsa con le prove e il chiuderla correttamente.

L'obiettivo è un punto d'incontro, non un gestore

network-online.target non ha idea di cosa sia una rete. È un punto di coordinamento che raccoglie il servizio che dovrebbe ritardare l'avvio finché il collegamento non è utilizzabile, e delega la definizione al gestore di rete che possiede la macchina. Sulla maggior parte di desktop e server ciò significa un servizio di attesa fornito da NetworkManager o da systemd-networkd. Se non ne attivate nessuno, l'obiettivo non ha nulla da attendere, quindi si completa nel momento in cui qualcosa lo tira dentro, il che può avvenire molto prima che DHCP risponda. La riga di ordinamento nella vostra unità era onesta e comunque inutile.

La prima domanda quindi non è cosa dichiara la vostra unità. È se qualcosa su questa macchina stia davvero facendo l'attesa.

Leggete l'ultimo avvio invece del file dell'unità

I file delle unità descrivono l'intenzione, e il journal descrive ciò che è successo. Chiedete solo quell'avvio, con marche temporali monotone perché ogni messaggio stia su un solo orologio. Poi trovate due righe: il momento in cui l'unità del tunnel ha iniziato ad avviarsi e il momento in cui è apparso l'indirizzo o è terminato il servizio di attesa. Ordinate quei due numeri e la corsa è confermata o esclusa.

La vista delle dipendenze lo corrobora. Se una catena critica per l'unità del tunnel non contiene alcun servizio di attesa, nulla su quel percorso ha ritardato l'avvio, e l'obiettivo non ha fatto il lavoro che davate per scontato. Due viste, una conclusione.

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

Aggiungete l'attesa, poi il nuovo tentativo

Usate un drop-in invece di modificare un'unità impacchettata, così un aggiornamento del pacchetto non scarta il cambiamento in silenzio. Contano due direttive: l'unità deve essere ordinata dopo l'obiettivo e deve tirare l'obiettivo nella stessa transazione. L'ordine da solo non evoca l'obiettivo; il desiderio sì.

L'unità impacchettata del client OpenVPN porta già entrambe. Le unità scritte a mano di solito ne portano una o nessuna, cosa che vale la pena controllare prima di aggiungere qualsiasi cosa.

[Service]
Restart=on-failure
RestartSec=15

Perché un sonno fisso è una trappola

Un sonno in ExecStartPre sembra una correzione di ordinamento e si comporta come un ritardo con passaggi in più. Rallenta ogni avvio, compresi quelli sani, e perde comunque quando il collegamento impiega più tempo del numero che avete scelto.

Peggio, nasconde se il servizio di attesa funzioni, così il guasto successivo si presenta come un problema del tutto nuovo anziché come lo stesso con un'altra temporizzazione. Un breve ritardo di riavvio è lo strumento migliore: non costa nulla su un avvio sano e trasforma una corsa persa in un altro tentativo. Mantenete l'intervallo modesto e lasciate che l'unità riesca. Se si riavvia all'infinito, il profilo è rotto e nessuna quantità di nuovi tentativi lo cambierà, quindi leggete il log invece di alzare l'intervallo.

Quando l'ordine è corretto e i nomi falliscono ancora

Un'unità attiva con una rotta del tunnel significa che l'ordinamento ha fatto il suo lavoro e che il guasto rimanente sta uno strato più in alto. La forma abituale è un'impostazione del resolver applicata dallo script up del tunnel prima che il collegamento o il resolver fossero pronti a trattenerla. Confrontate lo stato del resolver durante il guasto con lo stato dopo un riavvio dell'unità del tunnel.

Se il riavvio sistema le risoluzioni, avete un difetto di ordinamento dell'avvio e non un server DNS sbagliato, e i due richiedono correzioni diverse. Poi dimostrate il tutto con un avvio a freddo invece di un riavvio del servizio, perché un riavvio gira contro una rete già attiva e nasconderà esattamente il difetto che state inseguendo. Ripetetelo con il collegamento volutamente lento, e considerate ancora rotto un'unità che funziona solo quando la rete è veloce.