Un blocco di due secondi che si risolve da solo appare identico sia che il tunnel abbia rinegoziato sia che la radio abbia singhiozzato. È anche possibile che non sia caduto nulla, e questa possibilità va testata per prima. Una breve raffica di perdite, una rinegoziazione e uno stallo dell’applicazione si percepiscono allo stesso modo per chi sta digitando. Solo uno dei tre casi si risolve modificando la configurazione del tunnel.

Due registrazioni, non una

Annota cosa è successo alla connessione sottostante e, separatamente, cosa ha fatto il tunnel stesso. Poi metti la pausa dell’applicazione accanto a entrambe le registrazioni. Sono serie di eventi indipendenti che a volte coincidono, e chiamare tutte e tre disconnessione presuppone la risposta fin dall’inizio.

Un monitor che sonda una volta al minuto non può vedere un’interruzione di due secondi. Riportare quella giornata come sana è tecnicamente corretto e praticamente inutile. Metti l’intervallo di campionamento accanto a ogni risultato che citi.

Cosa ha fatto il collegamento di accesso mentre l’applicazione si bloccava

L’intervallo di campionamento e il timeout definiscono cosa il monitor avrebbe potuto osservare, quindi annota entrambi accanto al risultato. Un’assenza di interruzioni registrata vale poco quando lo strumento campiona ogni sessanta secondi. Poi sonda tre punti con marche temporali: il router locale, un host esterno approvato raggiunto tramite il percorso semplice e una risorsa dietro il tunnel.

Conferma prima le rotte, perché un obiettivo pubblico può essere esso stesso instradato attraverso il tunnel e quindi misura il tunnel invece del percorso di accesso. Le prove che datano davvero l’interruzione stanno uno strato più in basso: eventi di collegamento sul router, record di risincronizzazione sul modem e un indirizzo WAN cambiato. Un contatore cumulativo di errori dice che qualcosa è andato storto, mai quando. Correla quei record con la finestra dell’incidente invece di leggerli isolatamente.

ping -i 0.5 -c 40 192.168.60.1
mtr -rwc 40 203.0.113.25
ip -brief address show

Un contatore cresciuto ieri non spiega nulla di un blocco di questa mattina. Limita la correlazione alla finestra segnalata dall’utente.

Cerca il record di riavvio

Un datagramma UDP perso non basta, da solo, a far avviare a Community OpenVPN una nuova negoziazione TLS. Il comportamento di riavvio segue ping-restart, e il valore in vigore può essere stato imposto dal server; il manuale della 2.6 definisce quei timer. La consegna si interrompe per un istante, la soglia non viene mai superata e il registro resta vuoto. Cerca quindi nel registro intorno alla pausa una riga di riavvio, una connessione nuova o un identificatore di sessione cambiato. Se nessuno dei tre compare, il tunnel probabilmente non ha fatto nulla e il timer non è mai stato il problema.

Accorciare ogni keepalive fa sembrare il rilevamento più rapido e sposta la linea in cui un singhiozzo diventa riconnessione. Ogni riconnessione costa un giro di autenticazione e la reinstallazione delle rotte. Allungare il timer non compra nulla tranne una finestra più lunga in cui un percorso morto sembra ancora vivo. Entrambe sono decisioni di regolazione con un prezzo, non miglioramenti gratuiti.

Anche un evento assente è una prova, ed è proprio il tipo che si salta perché nulla nel registro vi richiama l’attenzione. Annota la ricerca che hai eseguito, non solo il risultato.

Lascia che sia il confronto a decidere cosa correggere

Con entrambe le registrazioni affiancate, l’attribuzione di solito si scrive da sola. Un evento di collegamento del router su entrambi i percorsi significa che il soggetto è la connessione di accesso. Un tunnel silenzioso e un percorso semplice utilizzabile significano che lo è la negoziazione.

What you observedTunnel log at that secondWhere to look next
two-second pause, plain path answers throughoutnothingthe monitor's resolution, then a loss burst
pause plus a router link event, plain path stops and returnsno restart linethe access link, not the tunnel timer
pause, then a new session identifierrestart linethe restart threshold and what triggered it
one application freezes while both paths answernothingthat application and its server-side work

Ogni riga è un indizio, non un verdetto: gli estremi abbassano la priorità di ICMP, e due destinazioni non condividono necessariamente un percorso. Tieni allineati gli orologi di client, gateway e applicazione perché il confronto sia anche solo possibile. Una riga che entra in due colonne richiede un’altra osservazione, non una decisione.

Un rapporto che supera la revisione risponde a quattro cose: quanto è durato il blocco, quali percorsi hanno continuato a rispondere, cosa ha registrato il tunnel in quel secondo e con che frequenza campiona il monitor. Questi quattro fatti permettono al lettore successivo di riprodurre l’osservazione invece di fidarsi di un riassunto. Una percentuale di disponibilità nasconde esattamente l’intervallo che ti interessa, e così la frase "la VPN è caduta".

Articoli correlati