Il keepalive non è una riconnessione: scegli in base al guasto che hai

I keepalive e le riconnessioni si configurano nello stesso momento ma risolvono problemi diversi, per questo regolare l'uno raramente corregge l'altro. Un keepalive invia traffico ridotto per mantenere viva una voce di stato o per accorgersi che un peer ha smesso di rispondere. Una riconnessione abbatte ciò che è rotto e ricostruisce la relazione, comprese chiavi, indirizzi e rotte. Scegli il meccanismo che corrisponde al guasto, non quello di cui conosci già la manopola. Due domande lo decidono: il percorso è morto o qualcosa tra i peer lo sta dimenticando?

Quando la mappatura è il problema

Un tunnel che muore solo dopo minuti di silenzio di solito perde una voce di traduzione e non un peer. L'opzione PersistentKeepalive di WireGuard esiste per lo stato NAT e firewall, e le note del progetto la presentano proprio così, non come un controllo di salute. Un intervallo di alcune decine di secondi mantiene calda la voce, mentre un pacchetto ogni secondo è una decisione sulla batteria e non sull'affidabilità. OpenVPN arriva allo stesso punto tramite ping e ping-restart , che notano prima il silenzio e poi agiscono di conseguenza.

Queste impostazioni non sono nemmeno intercambiabili tra protocolli. Una politica di peer morto di IKEv2, un timer ping di OpenVPN e un keepalive di WireGuard rispondono alla stessa domanda con tre sintassi e tre valori predefiniti diversi, quindi copiare un numero tra loro è un'indovinella vestita da regolazione.

Quando la relazione è sparita

Se il peer cambia indirizzo, la credenziale scade o l'estremo remoto si riavvia, i pacchetti piccoli non sono la riparazione. La riconnessione deve ricostruire lo stato : ottenere un indirizzo, reinstallare le rotte, rinegoziare le chiavi e in alcune distribuzioni riautenticare un utente.

I client che si riconnettono senza sorveglianza conservano un certificato o un segreto salvato. Un client che chiederebbe a una persona fallisce proprio quando non c'è nessuno, ed è lo scenario in cui la riconnessione contava. È una scelta di progetto fatta mesi prima, non un'impostazione che puoi cambiare durante un'interruzione.

Cosa non dimostra nessuno dei due

Un tunnel può essere riconnesso, con chiavi e rotte, mentre il servizio dietro è inattivo, e un keepalive può tenere aperta una mappatura per una sessione il cui server è sparito da ore. Entrambi i meccanismi possono riportare successo mentre ciò che ti interessa davvero non è disponibile.

Per questo il test termina con una richiesta reale. Invia qualcosa attraverso il tunnel dopo l'intervallo che ti interessa, poi provoca separatamente il guasto per cui hai progettato: un periodo di inattività per il caso della mappatura, un riavvio o un cambio di indirizzo per il caso della riconnessione.

Bloccare il traffico diretto è una decisione separata

Un ciclo di riconnessione può essere del tutto sano mentre un'applicazione usa silenziosamente la rotta ordinaria, e questa è una fuga, non un guasto. Se il requisito è che nulla esca fuori dal tunnel, dillo esplicitamente nella configurazione del client e dimostralo abbassando il tunnel e guardando cosa si connette ancora. Nessuno dei due meccanismi implica quel comportamento, e nessuna disciplina di tentativi lo stabilisce.

Annota quale meccanismo è stato eseguito e se dopo una nuova richiesta ha funzionato. Questi due fatti sono ciò che serve al prossimo ingegnere, e nessuno dei due è visibile in un'icona di stato. Una riga di log che dice che il client si è riconnesso non è la stessa cosa di una richiesta che ha funzionato.

Scrivi la politica, non solo il numero

Metti la coppia in una frase: l'intervallo di inattività, la soglia di vitalità, cosa innesca una ricostruzione , e cosa fa il client mentre riprova. Senza quella frase, ogni incidente futuro riapre la stessa discussione se il keepalive sia troppo corto o la riconnessione troppo lenta.

Le note di WireGuard sui limiti sono un promemoria utile che il keepalive è una soluzione tampone per i middlebox e non un progetto generale di vitalità. Leggi quel limite prima di alzare la frequenza in risposta a un problema che non può risolvere.