Riavviare OpenVPN ogni giorno? Scegliete il guasto, non l’orologio

Ereditate un cron job che riavvia OpenVPN ogni giorno alle 04:10 e che da un anno tiene le cose stabili. Però disconnette anche un tunnel sano a un’ora fissa e non fa nulla per l’interruzione che accade davvero a pranzo. Un riavvio a calendario è una decisione di manutenzione. Il ripristino è un progetto diverso, con un trigger preciso.

Tre forme di guasto richiedono tre proprietari diversi. Scegliete prima il guasto e il meccanismo seguirà.

Tre guasti, tre proprietari

Un tunnel può essere attivo mentre il suo peer è sparito: il processo gira, l’interfaccia esiste e nulla di utile la attraversa. Un processo può essere morto mentre il peer sta bene, e in quel caso solo ciò che lo ha avviato può riportarlo in vita. Un’applicazione dietro il tunnel può essere rotta mentre sia il tunnel sia il peer sono sani, e riavviare il client in quel momento allarga l’interruzione senza toccare la causa. Separare questi tre casi è tutta la decisione.

Ognuno ha il proprio segnale e il proprio proprietario. La vitalità appartiene al protocollo VPN, il ciclo di vita del processo appartiene al gestore dei servizi, e la salute dell’applicazione appartiene al monitoraggio con un mandato ristretto.

Cosa può e cosa non può fare un’opzione di vitalità

keepalive è un ausilio che si espande in una coppia ping e ping-restart, come descrive il riferimento alle opzioni di collegamento, e i timeout che produce non sono identici sul server e sul client. I valori inviati da un server possono anche sovrascrivere ciò che un client ha configurato localmente, ed è per questo che un timeout che sembra corretto in un file locale potrebbe non essere quello in vigore.

Questo lo rende lo strumento giusto per un peer perduto e lo strumento sbagliato per un processo morto, dato che un processo terminato non può eseguire i propri timer. Non dice nulla nemmeno sulla risposta di un’applicazione dietro il tunnel, perché lo scambio avviene tra i due estremi del VPN. Copiare una coppia di timeout da un’altra installazione senza verificare ruolo, interruzioni attese e comportamento di riautenticazione è il modo in cui un tunnel stabile inizia a sfarfallare.

Cosa possiede il gestore dei servizi

Se il demone esce, il gestore che lo ha avviato decide cosa succede dopo. Una politica di riavvio legata al guasto, con un ritardo e un limite di frequenza di avvio, gestisce un ciclo di crash senza trasformarlo in una fork bomb. Queste impostazioni reagiscono agli esiti del processo e ai timeout, e non rilevano un processo vivo ma inutile. Non è una lacuna da rattoppare con una politica più ampia; è il confine tra ciclo di vita e vitalità.

La proprietà conta quanto le impostazioni. Una connessione avviata da un gestore di rete desktop dovrebbe mantenere l’assetto di ripristino di quel gestore, e aggiungere un’unità di servizio concorrente per la stessa interfaccia dà due proprietari a un solo tunnel. Sceglietene uno e scrivete quale.

Quando un riavvio programmato è legittimo

Un riavvio a orario può essere un’azione di manutenzione ragionevole: ha un proprietario, una finestra, un’istanza con nome e un accesso indipendente. Ciò che non può essere è una politica generale di affidabilità che disconnette anche tutti a un’ora fissa.

Se il riavvio esiste per aggirare una perdita nota o uno stato bloccato, ditelo nella descrizione dell’unità, altrimenti la persona successiva lo manterrà per sempre.

Provate i casi che contano: il peer sparisce mentre il processo resta attivo, il processo esce, un nuovo tentativo richiede credenziali fresche, e il tunnel torna mentre l’applicazione resta rotta. Osservate quale componente reagisce e quale stato lascia dietro di sé.

La domanda giusta non è con che frequenza riavviare, ma cosa dovrebbe notare il guasto per primo.