La VPN UDP si blocca in inattività: il firewall ha dimenticato il tuo flusso

La VPN si connette, funziona per un po' e poi smette di far passare traffico mentre il client mostra ancora una sessione. Riconnettersi risolve, e questo lo fa sembrare un bug del client. Di solito è un firewall o un dispositivo NAT che ha scartato una mappatura UDP inattiva e non ha idea che il tunnel esista ancora.

Il sintomo è abbastanza costante da poter essere diagnosticato: compare dopo l'inattività, non sotto carico.

Come si presenta un blocco da inattività

Misuralo invece di descriverlo. Annota quanto resta inattivo il tunnel prima che il traffico si fermi, se un nuovo pacchetto in uscita lo riattiva e se l'interfaccia del client conserva ancora il suo indirizzo. Se una richiesta nuova dal client funziona ma una risposta a un flusso esistente no, la mappatura è il sospetto. Se non funziona nulla finché non ti riconnetti, anche lo stato di sessione del client è perso.

Entrambi sono legati all'inattività e richiedono correzioni diverse.

Annota i tempi prima di cambiare qualsiasi cosa. Un rapporto che dice che si ferma dopo circa dieci minuti di inattività è verificabile, mentre un rapporto che dice che cade a caso non lo è. Questa differenza decide se stai inseguendo un timer o un cambio di routing.

Trova il dispositivo che ha dimenticato

Diversi dispositivi possono mantenere lo stato per lo stesso flusso: il router locale, un traduttore a monte, un confine cloud e il firewall dell'host. Ognuno ha il proprio timer, e vince il più breve. Un'interruzione di cinque minuti di solito significa che un dispositivo è configurato molto al di sotto degli altri.

Non dare per scontato che il valore predefinito documentato sia il timeout sul tuo percorso. È il valore predefinito di un solo dispositivo.

• Router domestico: spesso minuti, a volte molto meno.
• NAT cloud o bilanciatore di carico: cerca il timeout di inattività documentato specificamente per UDP.
• Firewall dell'host: i timer di tracciamento di netfilter valgono per flusso.

Controlla i timer sul percorso reale

Su Linux, i timer di tracciamento di netfilter sono visibili e regolabili: sysctl net.netfilter.nf_conntrack_udp_timeout e net.netfilter.nf_conntrack_udp_timeout_stream. Il secondo vale quando il traffico è stato visto in entrambe le direzioni, ed è per questo che un tunnel stabilito può sopravvivere a una sonda semplice.

RFC 4787 definisce il comportamento di UDP NAT e i minimi raccomandati. È il riferimento da citare quando un valore predefinito di un fornitore sembra insolitamente breve.

Keepalive e riconnessione sono strumenti diversi

Un keepalive mantiene viva una mappatura; una riconnessione ricostruisce una sessione morta. Risolvono guasti diversi e non sono impostazioni di velocità intercambiabili. L'opzione PersistentKeepalive di WireGuard invia un pacchetto a intervallo fisso per tenere aperta l'associazione NAT. L'opzione keepalive di OpenVPN fa lo stesso lavoro a modo suo. Nessuna delle due aiuta se il dispositivo in mezzo ha già dimenticato il flusso e scarta entrambe le direzioni.

Sonde estremamente frequenti aggiungono lavoro senza correggere il confine sbagliato.

Verifica con una richiesta nuova, non con un ricaricamento di pagina

Dopo aver cambiato un timer o aggiunto un keepalive, ripeti lo scenario di inattività esattamente come prima. Poi fai una richiesta davvero nuova dall'applicazione coperta. Una scheda del browser già caricata può essere renderizzata dalla cache e non dirti nulla.

Se il blocco persiste, spostati di un salto verso l'esterno e controlla la tabella degli stati di quel dispositivo.