keepalive di OpenVPN o riavvio di systemd: quale recupera?

Tre cose diverse possono andare storte con un tunnel, e richiedono tre reazioni diverse. Il peer smette di rispondere, il processo del demone muore o l'applicazione dietro il tunnel smette di servire. Una configurazione che riavvia il servizio su uno qualsiasi di questi non è una supervisione accurata; è un'azione brusca applicata a guasti non correlati. Confrontare ciò che ogni meccanismo può davvero osservare rende evidente la divisione del lavoro.

Tre guasti che sembrano uno

Il silenzio del peer significa che l'altro estremo ha smesso di inviare, e OpenVPN può rilevarlo da solo perché possiede il battito. La morte del processo significa che il demone è uscito, cosa che il gestore dei servizi nota e OpenVPN non può. Il guasto dell'applicazione significa che il tunnel va bene e qualcosa dietro no, e nessuno degli altri due meccanismi ha modo di saperlo. Ognuno richiede una reazione diversa, e nessuno è la stessa cosa che accorgersi che il tunnel è attivo.

Sono segnali diversi da livelli diversi, e ciascuno ha un proprietario che può agire senza indovinare. Mescolarli produce un sistema che si riavvia su sintomi che non sa interpretare.

Scrivete i tre casi prima di cambiare qualsiasi timer. L'elenco stesso di solito mostra che a un meccanismo viene chiesto di coprirli tutti e tre.

A cosa si espande davvero keepalive

La direttiva keepalive è una scorciatoia, e l'espansione varia con la modalità. Su un server, keepalive 10 60 diventa un ping locale ogni dieci secondi, un timeout di riavvio locale di 120 secondi e valori 10 e 60 inviati ai client. Il timeout del server è volutamente raddoppiato perché un client abbia la possibilità di riavviarsi prima che il server si arrenda. Leggete la forma espansa nella configurazione in esecuzione, non la scorciatoia nel profilo.

Quel raddoppio è il motivo per cui qualsiasi descrizione che affermi che entrambi gli estremi si riavviano dopo sessanta secondi è sbagliata. Spiega anche perché i due estremi non oscillano all'unisono quando un percorso peggiora.

Il battito è traffico dei peer OpenVPN, non una sonda ICMP verso un host pubblico. Una risposta prova solo che l'estremo lontano del tunnel è vivo. Non dice nulla sul database o sul servizio web di cui l'utente ha davvero bisogno.

Ciò che Restart=on-failure non sorveglia

Leggete l'unità installata prima di aggiungere una sovrascrittura. Restart=on-failure risponde a condizioni documentate di guasto del processo, che non è lo stesso che sorvegliare lo stato della connessione. Non scatta perché è iniziata una riconnessione interna, e un'uscita pulita ha una semantica diversa da un crash.

Questa distinzione conta perché un riavvio interno mantiene vivo lo stesso processo. L'unità non vede nulla, il tunnel si riprende da solo, e questo è il risultato corretto.

Impostate RestartSec e i limiti di avvio deliberatamente, altrimenti un ciclo di crash martellerà il gateway e seppellirà il vero errore sotto i messaggi di riavvio. Un limite di riavvio che scatta lascia l'unità in errore, il che è visibile, mentre un ciclo illimitato non lo è.

ping-restart e ping-exit non sono intercambiabili

ping-restart attiva il riavvio interno di OpenVPN e conserva il processo. ping-exit termina il processo sullo stesso tipo di timeout, il che consegna la decisione al gestore dei servizi. Sono mutuamente esclusivi, e scegliere il secondo cambia chi possiede il recupero. La differenza è chi decide di riprovare e quanto stato sopravvive al tentativo.

Se scegliete l'uscita al timeout, l'unità ha bisogno di una politica di riavvio e di una gestione dello stato di uscita che corrispondano, altrimenti un guasto di vitalità sembra un arresto permanente. Le opzioni di persistenza possono anche preservare interfacce e rotte attraverso un riavvio interno, ma non attraverso un'uscita del processo.

Scegliete un ciclo di vita per distribuzione e scrivete perché. Un profilo che porta entrambe le direttive è un profilo che non ha deciso.

Provate ogni guasto come caso a sé

Simulate un peer silenzioso, un demone ucciso e un'applicazione non disponibile in una finestra approvata, poi verificate quale recupero è scattato. Un peer silenzioso dovrebbe produrre una riconnessione interna, un processo ucciso un riavvio dell'unità, e un'interruzione dell'applicazione nessuno dei due. Quando due casi producono la stessa azione, la proprietà è ancora mescolata.

Il recupero ripetuto non è nemmeno una riparazione. Credenziali rifiutate o due client che condividono un nome effettivo continueranno a sostituirsi, e timer più rapidi rendono solo più rapida quell'oscillazione.