VPN che cade durante i grandi caricamenti: prima leggi la coda

Il tunnel è stabile tutto il giorno e poi cade ogni volta che inizia un caricamento grande. Le richieste interattive si bloccano per prime, il client segnala un timeout e la connessione torna quando il trasferimento finisce. Questo schema indica accodamento ed elaborazione, non un server remoto caduto, perché al server non è mai stata data la possibilità di rispondere in tempo. Il lavoro consiste nel riprodurlo sotto un carico controllato e nel leggere i contatori giusti.

Cambia una variabile per esecuzione e mantieni fisso l’endpoint.

Costruisci un confronto di carico ripetibile

Registra una linea di base con il collegamento a riposo: tempo di andata e ritorno, alcune richieste applicative e il registro eventi del tunnel stesso. Poi avvia un caricamento di dimensione nota e ripeti esattamente quelle misurazioni mentre è in corso. Mantieni invariati l’endpoint, il client e la destinazione del test, perché cambiare due di essi insieme non ti dice nulla.

Nota quale evento compare per primo. Un tempo di andata e ritorno crescente prima di qualsiasi errore suggerisce accodamento; un timeout netto con latenza stabile suggerisce altro, come una rotazione delle chiavi o un’azione sull’account. I due schemi portano a passi successivi diversi. Scrivi l’osservazione prima di cambiare qualcosa.

Salva l’output con marche temporali così le esecuzioni sotto carico e a riposo si possono confrontare riga per riga.

Leggi la coda, non la velocità

I collegamenti consumer memorizzano i pacchetti nelle apparecchiature del provider, e una coda in uscita piena ritarda tutto, compresi i piccoli pacchetti di controllo che tengono vivo un tunnel. Un test di velocità che riporta una cifra alta dice poco su quel ritardo, ed è per questo che un test a riposo passa mentre un collegamento saturo fallisce.

ping -c 20 -i 0.2 203.0.113.10
mtr -rwc 20 203.0.113.10
tc -s qdisc show dev eth0
ss -ti dst 203.0.113.10
nstat -az | grep -E 'Retrans|Timeout'

Confronta le cifre di latenza sotto carico con quelle a riposo. Un salto da decine di millisecondi a centinaia, senza perdita di pacchetti, è accodamento; la perdita con latenza stabile indica un altro guasto.

Controlla il dispositivo e il percorso di controllo

Cifratura e inoltro costano tempo di processore, e un piccolo router o un portatile limitato termicamente può scartare pacchetti mentre è occupato. Osserva il carico complessivo e non la percentuale di un processo, perché l’inoltro nel kernel e la gestione degli interrupt non compaiono dove la gente guarda di solito.

uptime
mpstat -P ALL 1 3
dmesg | grep -i -E 'thermal|throttl'
journalctl -u openvpn-server@server --since '10 min ago' | tail -20

Un timeout del client può anche coincidere con una rotazione di chiavi programmata o con un evento di policy di sessione. Leggi il registro del client stesso per l’ordine degli eventi, non solo il messaggio di errore dell’applicazione.

Cambia una cosa e ripeti

Dove la piattaforma lo consente, limita la velocità di caricamento o classifica il traffico massivo sotto quello interattivo così che la coda non si riempia mai. Poi ripeti lo stesso carico di lavoro e confronta le stesse tre cifre di prima. Un cambiamento che migliora un test di velocità ma lascia il timeout non ha riparato nulla.

Alzare i timeout ovunque e indebolire la cifratura sono i due cambiamenti che fanno sparire il sintomo senza identificare quale confine ha ceduto. Nessuno dei due è una riparazione. Entrambi spostano il guasto più avanti, dove è più difficile attribuirlo.

Chiudi provando una richiesta nuova e il comportamento di riconnessione su cui l’utente conta davvero. La stabilità sotto il carico che ha provocato la lamentela è l’unico risultato che vale la pena registrare.