Come testare la stabilità di una VPN senza registrare la tua navigazione

Vuoi sapere se il tunnel sopravvive alla sospensione di un portatile, a una passeggiata tra punti di accesso, o a un'ora di chiamate, e preferisci non consegnare a nessuno un registro di tutto ciò che leggi mentre lo scopri. Tre cose lo rispondono: una sonda fissa, gli stessi quattro fatti campionati secondo un programma e l'evento che li ha cambiati, annotato. Dieci minuti di questo battono un pomeriggio passato a guardare una pagina che non si carica. Il registro che ti ritrovi è anche abbastanza breve da allegarlo a un ticket senza oscurarne metà.

Decidi cosa deve significare stabile

«La VPN è caduta» sono quattro guasti diversi in una sola parola. Il peer può perdere l'handshake, la rotta può ricadere sul gateway locale, la risoluzione dei nomi può andare a un server che non risponde mai attraverso il tunnel, oppure tutto questo può essere sano mentre un'applicazione continua a fallire. Decidi quale corrisponde al tuo sintomo prima di raccogliere qualsiasi cosa, perché ognuno richiede una sonda diversa. Poi scegli un intervallo che riesci a mantenere: un campione ogni trenta secondi per dieci minuti coglie un roaming senza trasformare il test in carico di lavoro.

Se la lamentela è una chiamata che si blocca quando vai in cucina, la proprietà che ti serve è se una richiesta nuova si completa dopo il roaming. Si verifica in una riga e non registra alcuna navigazione.

Fissa una sonda innocua

Scegli una destinazione che ti è consentito interrogare e che non sia legata ai tuoi account: un host di documentazione, un endpoint di stato interno o il gateway stesso del tunnel. Rendi l'operazione ripetibile, per esempio curl -s -o /dev/null -w "%{http_code} %{time_total}\n" https://example.com/, che stampa una riga per tentativo. Mantieni quel formato di output fisso per tutta l'esecuzione. Un codice di stato e una durata raccolti allo stesso modo due volte sono ciò che rende confrontabili due esecuzioni.

Resisti al sito su cui conti davvero. Una pagina di banca o di webmail trascina tracker, reindirizzamenti e contenuti personali nella misurazione, e stampa identificatori di sessione in tutto ciò che incolli poi in un ticket. Usa la stessa destinazione per tutta l'indagine e annotala accanto all'intervallo.

Campiona i quattro fatti

Lo stato del peer, la rotta, il resolver e una richiesta nuova sono le quattro osservazioni, e ognuna ha una fonte economica. Su WireGuard, wg show wg0 latest-handshakes dà la marca temporale del peer e ip route get 1.1.1.1 mostra quale interfaccia userebbe il kernel. Su OpenVPN lo stesso stato sta nel file di stato scritto da --status /run/openvpn/status 10 o dietro state sull'interfaccia di gestione. Un client Windows resta in PowerShell con Get-NetAdapter e Resolve-DnsName.

Mettili in ciclo in un solo terminale perché ogni riga porti una marca temporale: for i in $(seq 1 20); do date -Is; wg show wg0 latest-handshakes; ip route get 1.1.1.1; sleep 30; done. Quel ciclo copre tre dei sei campi del registro; la versione del client va inserita una volta in cima, e la marca temporale dell'evento si aggiunge quando l'evento accade.

Il resolver è il fatto che la gente salta, e dig +short lo nasconde, perché quella forma stampa solo la risposta. Chiedi il server esplicitamente con dig example.com | grep SERVER:, oppure usa nslookup example.com dove dig non è installato, che stampa l'indirizzo del server a cui è andata la query. Un handshake vecchio su un tunnel inattivo non è automaticamente un guasto, dato che WireGuard rinnova le chiavi solo quando c'è traffico da proteggere.

Provoca l'evento, non una fuga

Prendi cinque minuti tranquilli come linea di base prima dell'evento che ti interessa, che sia chiudere il coperchio, camminare verso un altro punto di accesso o passare all'hotspot di un telefono. Annota l'ora in cui l'hai provocato, così i campioni sui due lati si possono allineare.

Senza quella marca temporale il registro mostra un vuoto e nessuno può dire se l'ha chiuso il client o la rete. Due esecuzioni con l'evento in punti diversi valgono più di dieci senza. Usa i controlli di disconnessione e riconnessione del client stesso. Non disattivare il kill switch e non spingere traffico fuori dal tunnel per vedere cosa succede, perché su un portatile gestito è una violazione di policy e sulla tua macchina crea esattamente l'esposizione che stavi testando.

Tieni un registro abbastanza piccolo da finirlo

Sei campi per campione: ora, versione del client, endpoint, rete di accesso, evento, risultato. Lascia fuori indirizzi web, payload, token e qualsiasi cosa che porti un identificatore di sessione, perché il registro è prova sul tunnel e nient'altro. Tienilo accanto al ciclo così la persona successiva può rieseguirlo senza chiedere cosa significano le colonne.

Dopo un cambiamento, ripeti il test con la stessa sonda e lo stesso intervallo; se scambi la destinazione e la versione del client insieme, il risultato non appartiene a nessuna delle due. Un'esecuzione pulita di dieci minuti è prova per quelle condizioni e quella destinazione, non una promessa sulla rete dell'hotel il mese prossimo. Conserva lo script e il modello di registro dove li troverai. I limiti documentati di WireGuard meritano una lettura prima di attribuire un'interruzione al protocollo.