Test del kill switch: misurate il vuoto, non solo la riconnessione

Una riconnessione che termina in un secondo vi dice che il client è veloce. Non vi dice se qualcosa è uscito mentre il tunnel era abbassato. Una riconnessione che richiede un minuto vi dice che il client è lento, e ancora non vi dice se nel vuoto era consentito il traffico diretto. Sono due misure, e un test del kill switch che riporta solo la prima non ha testato l’interruttore.

Due osservazioni, due verdetti separati

La domanda sulla disponibilità è semplice: quando il tunnel è tornato utilizzabile e se l’applicazione protetta ha avuto bisogno di una nuova connessione per arrivarci. La domanda sull’applicazione è diversa: quali pacchetti hanno lasciato la macchina tra il momento in cui la protezione è caduta e il momento in cui è tornata.

Rispondete con registrazioni separate. Una riga dice che il vuoto è durato un certo numero di secondi. Un’altra riga dice se una richiesta non protetta è riuscita durante quel vuoto. Fonderle in un unico superato o fallito nasconde il caso che conta di più: una riconnessione rapida con una fuga.

Costruite una sonda che possiate cronometrare

Usate una richiesta innocua, economica e indipendente dal canale di controllo del tunnel stesso. Il ciclo qui sotto stampa un timestamp, uno stato HTTP e il tempo trascorso una volta al secondo, e fallisce rumorosamente invece di bloccarsi:

while true; do
  printf '%s ' "$(date +%H:%M:%S)"
  curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 2 https://example.com || echo "curl-exit-$?"
  sleep 1
done

Leggete i codici di uscita di curl, non solo lo stato. Un 28 significa che la richiesta è scaduta, ecco come appare un percorso bloccato. Un 6 significa che la risoluzione dei nomi è fallita, un altro tipo di riscontro e spesso il più interessante. Un 200 con poco tempo trascorso durante il vuoto significa che il traffico è stato lasciato uscire.

Scrivete l’output in un file e conservatelo. La cronologia del terminale non è una prova, e la parte interessante di solito sono tre righe nel mezzo.

Provocate un guasto reale, non uno ordinato

Disconnettersi dal menu del client prova il percorso cooperativo, in cui il client ha il tempo di installare le sue regole di blocco. Uccidete invece il processo, o fate cadere il collegamento sottostante, e provate il percorso che segue un guasto reale.

Ogni trigger esercita un percorso di codice diverso. Un guasto lato server, una perdita di collegamento locale e un crash del client possono lasciare stati diversi, e uno di essi è probabilmente il caso che finirete per incontrare. Eseguite la sonda con almeno due trigger ed etichettate i risultati per trigger.

Leggete il registro per vedere com’è il traffico consentito

Un 200 o un rapido fallimento di connessione durante il vuoto è una fuga, in qualunque direzione punti. I timeout per tutto il vuoto sono la forma attesa di una politica di blocco. Una risoluzione dei nomi che riesce mentre le connessioni falliscono suggerisce che il resolver è ancora raggiungibile, il che è una fuga di altro tipo.

I socket esistenti richiedono attenzione. Un programma può continuare a usare una connessione aperta prima della disconnessione, quindi il traffico apparentemente vivo potrebbe non provare che sia stato consentito un nuovo percorso. L’elenco dei socket mostra se una connessione precede l’evento:

ss -tunp | grep -E 'ESTAB|SYN-SENT'
ip route get 198.51.100.7
resolvectl status | sed -n '1,20p'

Confrontate l’ora di inizio del socket con il timestamp della disconnessione. Una connessione più vecchia del guasto è prova di riutilizzo del socket, non di una fuga, e segnalarla come guasto manda la persona successiva a caccia di un bug che non esiste.

Registrate il risultato in una forma che sopravviva a un aggiornamento

Annotate il trigger, il vuoto in secondi, se una richiesta non bloccata è riuscita, se la risoluzione dei nomi è riuscita e le versioni del client e del sistema operativo. Quell’insieme di cinque fatti si può confrontare tra versioni, cosa che un paragrafo di prosa non può.

Rieseguite lo stesso test dopo un aggiornamento del client o un cambio di profilo, perché il comportamento di blocco è un dettaglio implementativo e si sposta. Lo scopo della registrazione è notare lo spostamento prima che diventi un incidente, non certificare il client una volta.