Un tunnel che muore ogni quindici minuti, o ogni ora allo stesso minuto, vi dice che è scaduto un timer, non che la rete è instabile. La mossa utile è annotare l'intervallo e confrontarlo con i quattro timer che producono questo schema. Cambiare i timeout prima di quel confronto di solito sposta il guasto senza spiegarlo, il che rende l'occorrenza successiva più difficile da leggere della prima. La misurazione costa dieci minuti e sostituisce una settimana di congetture.

Trasforma l'intervallo in un numero

Raccogli cinque o sei occorrenze e calcola lo scarto tra loro, non lo scarto dall'inizio della giornata. Una caduta alle 09:12, 10:12 e 11:12 è un confine orario; una caduta alle 09:12, 09:27 e 09:42 è di quindici minuti dall'ultima connessione riuscita. Arrotonda il risultato al timer più plausibile, non al minuto più vicino.

Registra due momenti per evento: quando il traffico si è mosso l'ultima volta e quando il client ha segnalato la disconnessione. Differiscono quando un tunnel muore in silenzio e il client se ne accorge solo all'invio successivo, ed è quella differenza a separare un timeout di inattività da un guasto netto. Un client che se ne accorge tardi gonfia la finestra di inattività che misurate.

Nota se la riconnessione è automatica. Un client che si riconnette in pochi secondi mantiene l'intervallo visibile nel registro e fuori dal rapporto utente, ed è per questo che questi guasti sono spesso descritti come occasionali anziché periodici. Nasconde anche l'evento alla persona che usa il portatile.

Quattro timer che sembrano uguali

Quasi ogni caduta ripetuta del tunnel proviene da uno di questi: un rinnovo delle chiavi del protocollo, una scadenza di mappatura inattiva, un evento DHCP o di interfaccia, o una policy dell'account. Differiscono per se il traffico era in corso e per ciò che il registro dice al confine.

Le firme qui sotto vale la pena impararle, perché permettono di scartare tre spiegazioni con una sola riga di registro:

TimerTypical triggerWhat the log shows at the boundary
Protocol rekeyTraffic present, fixed intervalNegotiation lines, sometimes a failure
NAT or firewall idleNo traffic for minutesSilence, then a timeout on send
DHCP lease or link changeHalf the lease, or a radio eventAddress or interface churn
Account session limitWall-clock hours since loginClean disconnect, server-side reason

La prima riga è un meccanismo di sicurezza che fa il suo lavoro, e la seconda è un dispositivo intermedio che dimentica lo stato. Confonderli porta a indebolire il rinnovo o a inseguire una regola del firewall che non è mai stata coinvolta.

Occupato contro inattivo vi dice quale metà

Fate un confronto controllato con traffico continuo, come un flusso lungo verso un host dentro il tunnel, e osservate se l'intervallo cambia. Se la caduta scompare mentre i dati scorrono, il timer è basato sull'inattività.

Se sopravvive al traffico continuo, la causa appartiene al rinnovo, al lease o alla policy. Quell'unico test elimina metà dei candidati in circa un'ora di osservazione, e non costa altro che attenzione.

Mantenete la rete di accesso invariata durante il test. Passare tra Wi-Fi ed Ethernet a metà confronto introduce esattamente l'evento di interfaccia che state cercando di distinguere da un timer.

Allinea la riga di registro al confine

Leggete i registri del client e del server intorno al momento annotato, non l'intero file. Un rinnovo mostra una negoziazione; una scadenza di inattività non mostra nulla fino al pacchetto successivo; un cambio di lease mostra lavoro sugli indirizzi; un limite di policy di solito mostra una disconnessione amministrativa pulita.

Questi comandi estraggono la finestra pertinente da ciascuna fonte:

grep -iE "reneg|TLS Error|Inactivity" /var/log/openvpn.log | tail -20
journalctl -u NetworkManager --since "-90 min" | grep -iE "dhcp|link"
wg show

Se le tre fonti concordano sul timestamp, avete il proprietario del timer. Se solo il registro del client contiene qualcosa, probabilmente il server non è quello che termina la sessione.

Ripara la fase, non l'icona

Ogni proprietario ha una sola riparazione supportata. Un guasto di rinnovo richiede proposte compatibili a entrambe le estremità. Una scadenza di inattività richiede un keepalive o un'attesa di inattività più breve, entro ciò che il percorso consente. Un evento di lease richiede di sistemare l'interfaccia o le impostazioni di alimentazione. Un limite di account è una decisione di policy, non un bug.

Disattivare il rinnovo o l'autenticazione per mantenere l'icona verde scambia una caduta visibile con una debolezza invisibile, e vi lascia incapaci di dire quando il tunnel ha negoziato nuove chiavi l'ultima volta. Ritestate la durata originale dopo e conservate i timestamp, così il prossimo evento potrà essere confrontato con questo invece di ricominciare da zero.

Articoli correlati