Perché la tua VPN impiega più tempo a riprendersi dell’interruzione

Il Wi-Fi è tornato trenta secondi fa e la VPN è ancora giù, quindi il client sembra guasto. Spesso sta solo seguendo il proprio calendario di tentativi, e quel calendario non sa che la rete è appena tornata. Quel divario è tutta la storia: il tempo di ripresa è l’interruzione più qualsiasi attesa che il client ha già accettato. Ridurre ogni timer è una risposta, capire quale timer conta è l’altra.

Tre condizioni decidono se la regolazione aiuta: quale fase è lenta, se l’errore è ripetibile, e come il client apprende che la rete è tornata.

Tre attese che sembrano una

La risoluzione dell’endpoint, la negoziazione IKE o TLS, la ritrasmissione dei pacchetti e l’avvio di un nuovo tentativo sono eventi separati con timer separati. strongSwan documenta il backoff di ritrasmissione per IKE, e OpenVPN ha i propri controlli dei tentativi con una semantica diversa. Copiare un numero da uno all’altro presuppone che i meccanismi coincidano, e non coincidono. Leggi la sequenza del log prima di decidere quale intervallo stai guardando.

Un minuto di silenzio nel log non è necessariamente un processo bloccato. Può essere un backoff esponenziale che fa esattamente ciò per cui è configurato.

Quale fase è davvero lenta?

Se il log mostra tentativi che falliscono con un errore di autenticazione, nessun cambio di timer aiuta, perché la credenziale è sbagliata. Se non viene fatto alcun tentativo, il client è dentro la sua finestra di attesa e il calendario è la soluzione. Se i tentativi vengono fatti e scadono, il problema è la raggiungibilità o un listener mancante, e riprovare più in fretta riempie solo il log. Ognuno di questi tre stati ha un proprietario diverso, e solo uno è un problema di temporizzazione.

Classifica l’errore prima di toccare un numero.

Quando ridurre un timer aiuta e quando no

Abbassa il tetto dei tentativi quando il costo dominante è l’attesa dopo un’interruzione breve e frequente, come un portatile che passa tra punti di accesso. Lascialo stare quando gli errori sono lunghi o rari, perché riprovare in modo aggressivo aggiunge carico proprio nel momento in cui il concentratore è meno in grado di rispondere. In entrambi i casi, cambia un parametro, registralo e misura la ripresa successiva invece di dare per scontato che sia migliorata.

Un timeout molto basso copiato in ogni profilo è lo stato finale abituale della regolazione senza misura.

Verifica la disponibilità prima di incolpare il client

Spesso il client non può vedere che la rete è utilizzabile finché qualcosa non ci prova. Un portale captive, un rinnovo DHCP o un cambio di rotta possono lasciarlo in attesa di un calendario fissato prima che tutto ciò accadesse. Osserva il cambio di stato di rete del sistema operativo e il tentativo successivo del client sullo stesso orologio, e vedrai di chi è l’attesa. La versione rapida è annotare il timestamp dell’evento rete pronta e il timestamp del primo tentativo successivo.

Conferma anche che il traffico diretto sia ancora bloccato durante l’attesa, perché una riconnessione più rapida che perde traffico non è un miglioramento.

Che cosa registrare

Annota quale timer è cambiato, da quale valore a quale, e com’era la ripresa dopo. Annota anche la versione del client, perché i valori predefiniti si spostano tra le release e un timeout molto basso non documentato confonderà la prossima persona che leggerà il profilo.

Quella registrazione trasforma il prossimo aggiornamento software in un confronto invece che in un esperimento.