La durata della sessione VPN e il token di autenticazione scadono separatamente

Una caduta della VPN può avvenire per motivi che dal client sembrano identici e non hanno nulla in comune sotto la superficie: la sessione del tunnel è terminata, è scattato un timer di inattività oppure una credenziale che il client riutilizzava è diventata obsoleta. Ognuno ha un proprietario diverso e una correzione diversa. È la sequenza di errori nel momento della caduta a distinguerli, e di solito è una sola riga.

Tre orologi corrono contro un solo tunnel, e solo uno di essi è il tunnel.

Tre orologi diversi su un solo tunnel

L'orologio della sessione appartiene al gateway: una durata massima di connessione, un timeout di inattività o entrambi, e chiude il tunnel quando si raggiunge uno dei due. L'orologio del token appartiene al sistema di autenticazione e decide per quanto tempo una credenziale può essere presentata di nuovo senza una persona. L'orologio del percorso appartiene a qualunque NAT o firewall si trovi tra client e gateway, e fa scadere le mappature dei flussi che considera conclusi. Tutti e tre producono una disconnessione, e nessuno produce la stessa riga di registro.

Solo il primo è un concetto della VPN. Gli altri due sono presi in prestito dall'identità e dalle reti, e vengono regolarmente confusi con esso.

Come viene davvero riutilizzato il token

I server OpenVPN possono emettere un token di autenticazione dopo l'accesso iniziale, così una rinegoziazione del canale di controllo non chiede di nuovo le credenziali all'utente. Il client continua a presentare quel token e il server decide per quanto tempo resta accettabile. Quando la durata del token è più breve dell'intervallo di rinegoziazione, la rinegoziazione successiva fallisce e il client segnala un errore di autenticazione invece di un timeout. Per questo lo stesso profilo funziona per un'ora e poi fallisce in un punto fisso.

L'intervallo di rinegoziazione è un'impostazione separata. Modificarlo sposta quando il token viene presentato, non per quanto tempo vive.

Che aspetto ha ogni scadenza dal client

Un timeout di sessione di solito arriva come una disconnessione pulita con un motivo lato server, spesso dopo una durata prevedibile e senza alcun errore di autenticazione. Un timeout di inattività sembra silenzio: il tunnel smette di trasportare traffico, poi il keepalive si arrende. Una scadenza del token arriva come AUTH_FAILED nel mezzo di una sessione che funzionava un secondo prima.

Leggi la riga, poi guarda l'orologio. Una durata che corrisponde a un valore configurato non è una coincidenza.

Perché una password salvata non aiuta

Una password in cache risponde a una richiesta di password. Non prolunga la vita di un token e non soddisfa una richiesta di un secondo fattore o un controllo dello stato del dispositivo. Aumentare la frequenza dei tentativi, ridurre i timeout di connessione o reimportare il profilo non cambia nulla su quanto a lungo il sistema di identità accetterà la credenziale.

Le correzioni durature sono la durata giusta sull'oggetto giusto, oppure un flusso client che riesca a completare la richiesta necessaria senza una persona.

Cosa documentare e testare

Annota tutti e tre i valori: i limiti di sessione e di inattività del gateway, la durata del token e il timeout di mappatura rilevante più breve sul percorso. Poi prova ogni scadenza di proposito accorciando un valore, osservando cosa segnala il client e ripristinandolo. Conferma cosa deve fare l'utente a ogni confine, perché richiedere un accesso completo ogni ora è una decisione di policy che qualcuno avrebbe dovuto prendere di proposito.

Una caduta che arriva senza alcun evento di autenticazione appartiene al percorso o al timer di inattività, e questa è un'altra indagine con altre prove.