Un reset TCP non dimostra che la tua VPN sia bloccata

«Connessione reimpostata, riavvio» compare nel log del client, e la conclusione arriva prima della prova. Qualcuno decide che la rete blocca la VPN, o che il certificato è sbagliato, o che un certo paese interferisce. Un reset è un pacchetto TCP che termina una connessione, e la riga di log registra che il tuo client ne ha ricevuto uno. Non nomina il dispositivo che lo ha inviato né il motivo.

Un reset è un pacchetto, non un verdetto

TCP definisce la gestione del reset: un segmento con il flag RST termina la connessione immediatamente. Il ricevente non negozia, non riprova e non chiede perché. Segnala il reset e va avanti.

Questo è tutto ciò che il client sa. L’RST può essere arrivato dal server, da un proxy, da un firewall o da un bilanciatore di carico che ha perso lo stato.

L’attribuzione è un esercizio separato. Un indirizzo di origine apparente in una cattura non è prova dell’origine fisica e non dice nulla sulla decisione di policy che vi sta dietro. I dispositivi intermedi possono falsificare gli indirizzi, e i dispositivi con stato possono reimpostare per timeout anziché per intenzione. Trattare il reset come un verdetto salta la parte in cui lo scopri.

Conferma quale connessione è stata reimpostata

Controlla prima che il profilo attivo usi davvero TCP. Un reset su un tunnel UDP non ha senso, e un log di un proxy HTTP può riguardare una gamba TCP diversa dalla VPN stessa.

Annota la destinazione, la porta, l’ora del tentativo e la fase raggiunta dal client.

La fase è il campo più utile. Un reset durante l’handshake TLS indica un insieme di sospetti; un reset dopo l’autenticazione ne indica un altro. Senza la fase, ogni teoria si adatta.

Confronta entrambe le estremità del percorso

Se amministri il server, confronta i suoi eventi per lo stesso tentativo. Ha accettato la connessione? L’ha chiusa di proposito? Una risposta ha lasciato un confine e non è mai arrivata al successivo?

Cattura sul client e sul server se puoi. Un reset che appare sul client ma non sul server non è nato sul server.

Osserva i segmenti RST in entrambe le direzioni:

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

Restringi con un confronto controllato

Una seconda rete approvata può dirti se il guasto segue il client o il percorso. Se lo stesso profilo funziona altrove, la configurazione del client è probabilmente a posto e la variabile è il percorso.

Questo non identifica ancora un dispositivo intermedio preciso. Restringe l’ambito a una rotta, che è un risultato utile e onesto.

Mantieni la distinzione tra «questo percorso fallisce» e «questo attore nominato lo ha causato». Il primo è verificabile; il secondo di solito non lo è da un singolo client.

Verifica la correzione senza cambiare le impostazioni di fiducia

Non disattivare la verifica TLS, non rigenerare le credenziali e non annunciare una politica di blocco da una singola riga di reset. Ognuno di questi cambiamenti modifica il sistema in prova e rende privo di senso il confronto successivo.

Correggi il componente identificato tramite il suo proprietario, poi ripeti lo stesso profilo e la stessa osservazione:

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

Il risultato utile è un guasto localizzato meglio, non una storia più sicura. Se il reset scompare dopo una correzione del proxy, hai una causa. Se si sposta su un’altra fase, hai imparato qualcosa sul percorso. In ogni caso, la prova dovrebbe sopravvivere alla lettura di una seconda persona. Scrivi ciò che hai osservato, non ciò che hai concluso.