Il tunnel torna, il client dice connesso, e il browser continua a girare su una pagina che stava caricando prima dell’interruzione. Una riconnessione VPN ripristina un percorso e non ripristina lo stato di connessione che le applicazioni e il lato remoto hanno accumulato sul vecchio. Sono due cose diverse da riparare, e confonderle vi riporta nelle impostazioni VPN senza motivo.

Un test le separa in modo pulito, e richiede dieci secondi. Inviate una nuova richiesta alla stessa destinazione mentre la vecchia è ancora bloccata.

Cosa sopravvive a una riconnessione e cosa no

Un tunnel è un insieme di rotte, chiavi e indirizzi, e una riconnessione può ripristinare tutti e tre mentre ogni flusso stabilito resta morto. Il sistema operativo tiene un socket aperto perché l’applicazione l’ha chiesto, e il timeout di quel socket può essere a minuti o ore di distanza. Sotto, il peer ha dimenticato il flusso, una voce di traduzione è scaduta, oppure il percorso passa ora per un endpoint che non ha mai visto lo handshake. Nulla nella sequenza di riconnessione percorre i socket dell’applicazione e li ripara.

Alcuni client aggiungono un hook che scarta le connessioni obsolete alla riconnessione, e la maggior parte no. Il comportamento qui varia per client, piattaforma e versione.

Anche il lato remoto vi ha dimenticato

L’estremità remota conserva stato proprio: una sessione TLS, un blocco di controllo TCP e forse una voce di mappatura che lega indirizzo e porta al flusso. Un dispositivo di traduzione lungo il percorso può far scadere quella mappatura durante il vuoto anche quando il tunnel si ristabilisce in fretta. Una volta sparita la mappatura, arrivano pacchetti per un flusso che il server non riconosce più, e la risposta può essere un reset che il client non mostra mai. Le applicazioni lo segnalano come blocco e non come errore, perché stanno ancora aspettando un socket che non risponderà mai.

I timeout di inattività lato server fanno lo stesso secondo il loro calendario, ed è per questo che una sessione può morire senza alcun evento di rete. Una connessione rimasta inattiva più a lungo di quanto il server si aspetti è già sparita prima che notiate che il tunnel si è spostato.

Una richiesta nuova è il test che le separa

Inviate una nuova richiesta allo stesso host mentre la vecchia è ancora bloccata, e osservate entrambe. Se la nuova richiesta riesce, allora tunnel, rotta e risoluzione dei nomi funzionano, e il guasto è confinato al flusso obsoleto. Se fallisce anche la nuova richiesta, avete un problema di percorso e lo stato di sessione dell’applicazione è una pista falsa.

Lasciate in posizione qualsiasi blocco del traffico diretto durante il test. Una richiesta che riesce attraverso un percorso di riserva accidentale non dimostra nulla sul tunnel.

Confermate con una connessione nuova, non con quella vecchia

I comandi sotto mostrano i socket ancora aperti, avviano una nuova richiesta e verificano se la tabella delle sessioni contiene ancora una voce per il flusso. Eseguite il primo prima e dopo la riconnessione perché la differenza sia visibile. Sostituite host e porta con il vostro servizio.

ss -tanp | grep -E ':(443|8443)'
curl -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 https://intranet.example.com/
conntrack -L 2>/dev/null | grep 8443
dig +short intranet.example.com

Un socket stabilito senza traffico in movimento è la firma da cercare, e una nuova richiesta che restituisce un codice di stato mostra che il percorso è vivo. La tabella delle connessioni risponde se qualcosa mappa ancora il flusso, ed è la parte che il client non può vedere. La query al resolver copre l’altra metà del caricamento di una pagina, dato che un guasto di nome e una connessione bloccata sembrano identici in un browser. Insieme, questi quattro output separano una sessione obsoleta da un tunnel rotto.

Annotate l’ora dell’interruzione, l’ora della riconnessione e la differenza fra la richiesta vecchia e quella nuova. Quella nota trasforma un lamento vago in un rapporto su cui qualcuno può agire.

Articoli correlati