Come testare la velocità di una VPN perché i numeri significhino qualcosa

Un test di velocità non misura mai la VPN. Misura un percorso, e accendere il tunnel sostituisce parte di quel percorso prima che si muova il primo byte. Per questo un portatile mostra una cifra sana verso un sito e una scadente verso un altro senza che sia cambiato nulla da nessuna delle due parti. Leggi il risultato come prova su una rotta, non come punteggio di un prodotto.

Tre cose decidono se il confronto vale qualcosa: se le due esecuzioni hanno colpito lo stesso obiettivo, se la rete di accesso è rimasta ferma e se hai annotato il ritardo accanto al volume.

Che cosa riscrive il tunnel prima del primo byte

Il client avvolge ogni pacchetto in un’altra intestazione, quindi il carico utile per pacchetto si riduce. Il costo è per pacchetto e non per trasferimento, il che significa che un file grande richiede più pacchetti dello stesso file inviato senza tunnel. Un sovraccarico così si vede come numero di pacchetti, non come impostazione visibile.

Ne derivano due conseguenze. Un test fatto di blocchi grandi sente il costo per pacchetto, mentre un test di molte richieste piccole sente invece gli andirivieni. E se la scoperta dell’MTU del percorso è bloccata da qualche parte, il tunnel si assesta su una dimensione di pacchetto più piccola e la portata cala per un motivo che non ha nulla a che vedere con i cifrari.

Puoi osservare il tetto direttamente. Su Linux chiedi il carico più grande che passa senza frammentazione, poi ripeti con il tunnel attivo:

ping -M do -s 1472 -c 3 203.0.113.10

Se fallisce, scendi a 1,400 e riprova. Un tunnel che trasporta solo 1,380 byte ti sta dicendo che qualcosa stringe più in basso lungo il percorso, e nessun ritocco sul client lo solleverà.

Perché il server di prova si sposta quando sale il tunnel

La maggior parte degli strumenti sceglie un server vicino in base all’indirizzo pubblico che vede. Con il tunnel attivo quell’indirizzo appartiene al nodo di uscita, quindi lo strumento può scegliere un host in un’altra città o paese. Allora confronti due destinazioni, e il divario tra loro include la distanza dall’uscita all’host di prova.

Fissa il server per nome o ID prima della prima esecuzione e tienilo per ogni esecuzione successiva. Se lo strumento non lo trattiene, scegli un obiettivo che controlli e guidalo tu stesso: iperf3 -c test.example.net -R -t 20 tiene ferma la destinazione e ti dà un numero che puoi confrontare con quello di ieri.

Cambia una variabile, e lo strato sottostante non è uno solo

Il senza fili è il cambiamento nascosto abituale. La potenza del segnale si sposta quando il portatile si muove e l’occupazione del canale si sposta quando un vicino avvia una chiamata, quindi due esecuzioni a dieci minuti di distanza in Wi-Fi non sono ripetizioni dello stesso test. Il cavo, o una posizione fissa con il livello del segnale annotato, elimina gran parte di quel rumore. Una nota del livello del segnale all’inizio e alla fine di ogni esecuzione di solito basta a mostrare se due esecuzioni stanno insieme.

Il carico del dispositivo rientra nello stesso cesto. Un client che cifra su un solo core raggiunge il proprio tetto molto prima del collegamento, e una sincronizzazione in background lo raggiunge prima. Guarda la CPU durante l’esecuzione e annota cos’altro era aperto. Anche le impostazioni di energia possono mordere qui, perché un portatile a batteria può limitare il processore molto prima che il collegamento sia vicino a essere occupato.

Tieni fermo lo strato sottostante invece di farne una media. Tre esecuzioni che concordano dicono più di dieci prese in stanze diverse.

Ritardo, perdita e ICMP rispondono a domande diverse

Ping invia una piccola sonda a un indirizzo fisso, e molte reti rispondono all’ICMP con bassa priorità o lo ignorano del tutto. Le risposte mancanti descrivono la sonda, non i pacchetti dell’applicazione. Un tempo di andata e ritorno che sale sotto carico di solito significa che una coda si sta riempiendo, non che la rotta si è allungata.

Per sapere se il tunnel aggiunge ritardo, confronta un obiettivo con e senza di esso, o confronta due uscite raggiungibili dalla stessa rete di accesso. Esegui la sonda più volte e guarda la dispersione, perché la media nasconde proprio la variazione che rende inutilizzabile una chiamata.

Torna al compito che sembrava lento

Una misura che migliora mentre la chiamata ancora si spezza ha risposto a qualcos’altro. Riesegui il compito che ha avviato l’indagine, che fosse una riunione, una condivisione di file o una sessione di desktop remoto. Se la cifra è migliorata e il compito no, il collo di bottiglia era dove il test non è mai arrivato, come il server dietro il tunnel o il tuo collegamento in salita.

Registra ogni esecuzione con dispositivo, rete di accesso, endpoint, protocollo, obiettivo e ora. Un’esecuzione che non si è mai connessa è un risultato di raggiungibilità e non una portata zero, quindi archiviala sotto quell’etichetta invece di cancellarla.

Una lista breve prima del prossimo confronto

Fissa l’obiettivo e scrivi perché l’hai scelto. Annota la dimensione di pacchetto che il percorso consente, così un calo successivo ha una spiegazione. Tieni identica la rete di accesso, annota il carico di CPU e fai tre esecuzioni prima di credere a una differenza.

Poi cambia esattamente una cosa e ripeti. Il confronto che sai spiegare vale più di quello con il numero più grande.