Perché la valutazione Wi-Fi del router non predice il throughput della VPN

Un router con un'etichetta Wi-Fi da 3,000 Mbps può comunque muovere traffico cifrato a una frazione di quel numero, e nessuno dei due numeri è disonesto. La valutazione radio descrive la migliore modulazione possibile del collegamento senza fili supportata dal chipset; il numero VPN descrive quanto velocemente un solo dispositivo può spingere pacchetti cifrati attraverso la CPU del router e fuori dal tuo circuito di accesso. Sono livelli diversi, dimensioni di pacchetto diverse e metodi di misura diversi. Tratta il numero sulla scatola come un tetto che nessuno raggiunge, non come una previsione della velocità del tuo tunnel.

Passo 1: Mappa i quattro livelli che limitano il numero

Quasi ogni lamentela su un router lento che ho trattato finisce in uno di quattro livelli: il collegamento senza fili, la velocità di accesso WAN, il percorso di inoltro (NAT, firewall, tracciamento delle connessioni) o il percorso crittografico della VPN. Si sovrappongono, e il livello più lento fissa il risultato. Una velocità Wi-Fi dichiarata parla solo del primo livello, e ne parla con generosità.

Quel numero deriva dai flussi moltiplicati per la larghezza di canale e per la modulazione più alta che il chipset può negoziare. Una radio 2x2 a 5 GHz su 80 MHz con 1024-QAM è dichiarata vicino a 1,200 Mbps, ma il Wi-Fi è un mezzo condiviso e semiduplex: i client si alternano, le ritrasmissioni e il traffico di gestione bruciano tempo d'aria, e TCP aggiunge il proprio sovraccarico. Un client che negozia la velocità massima in condizioni ideali misura di solito molto sotto la metà, e ancora meno appena compaiono reti vicine.

Se la tabella punta alla radio, sistema prima il lato senza fili: banda, larghezza di canale, distanza. Se punta sotto la radio, contano i quattro passi successivi, e nessun acquisto di antenne lo cambierà.

Passo 2: Prendi una base via cavo prima di toccare la radio

Metti il portatile su Ethernet e misura prima il percorso senza il tunnel, perché questo ti dà un denominatore. Esegui lo strumento di throughput dall'altra parte, sul VPS o sul server domestico che termina la VPN, e punta il client al suo indirizzo pubblico perché il traffico attraversi il router e il circuito di accesso.

# on the far host (VPN endpoint)
iperf3 -s

# wired client, direct to the endpoint's public address
iperf3 -c 203.0.113.10 -t 30

# same client, four parallel streams
iperf3 -c 203.0.113.10 -t 30 -P 4

Due numeri di quel blocco rispondono a domande diverse. Un solo flusso mostra il tetto per connessione, che include il comportamento della finestra TCP e qualsiasi sagomatura per flusso sul percorso. Quattro flussi mostrano se il collegamento ha capacità che non sfrutti, perché flussi paralleli possono riempire un tubo che un solo flusso non riempie.

Mantienilo onesto: stesso host, ora del giorno e durata, senza nient'altro in streaming in casa. Un trasferimento massivo di trenta secondi è l'unità giusta qui, e RFC 6349, il quadro per testare il throughput TCP, si basa proprio su questo ragionamento, perché raffiche brevi e richieste piccole lusingano un collegamento. Annota la base prima di cambiare qualsiasi cosa.

Passo 3: Esegui lo stesso test attraverso il tunnel

Ora ripetilo verso l'indirizzo del tunnel dell'estremità remota, con lo stesso client, durata e numero di flussi, tunnel attivo e senza altro traffico. Il rapporto tra i due risultati ti dice quanto costano cifratura e incapsulamento su quell'hardware; il numero assoluto ti dice se basta per il lavoro.

Guarda i contatori mentre il trasferimento è in corso. Su WireGuard, wg show riporta i byte trasferiti per peer; su OpenVPN, un file di stato scritto a intervalli ti dà la stessa vista.

watch -n 1 'wg show wg0 transfer'
# OpenVPN: add --status /run/openvpn/server.status 10 to the server config
tail -f /run/openvpn/server.status

Se il numero del tunnel è vicino alla base via cavo, la VPN non è il tuo collo di bottiglia e puoi smettere di incolparla. Se è una frazione della base, la perdita è avvenuta dentro il percorso di cifratura e inoltro del router, e il passo successivo ti dice quale parte.

Un avvertimento: appena cambia l'IP di uscita, alcuni servizi di test di velocità scelgono in silenzio un altro server di misura, così finisci per confrontare due destinazioni. Fissa tu stesso l'indirizzo del server.

Passo 4: Leggi la CPU come un percorso, non come una media

Un router che mostra il 30 per cento di CPU totale può essere comunque saturo: il lavoro di un tunnel tende a finire su un core, una coda di interrupt o un thread del kernel, quindi la media nasconde il tetto. Guarda i numeri per core e i softirq invece dell'indicatore sulla dashboard.

mpstat -P ALL 1
top -H -p $(pgrep -f 'openvpn')
grep -o -m1 aes /proc/cpuinfo

Tre cose contano in quell'output. Un solo core inchiodato vicino al 100 per cento mentre gli altri sono inattivi indica un limite per connessione. Un %soft elevato o un ksoftirqd occupato su una CPU indica elaborazione dei pacchetti lato ricezione che non si distribuisce tra le code. E un flag aes assente significa che la CPU non ha istruzioni AES, quindi la cifratura simmetrica gira in software e costa molto di più per pacchetto.

Anche l'implementazione conta. Un'istanza OpenVPN tradizionale nello spazio utente elabora i pacchetti di un tunnel in gran parte in un solo punto, quindi una macchina multicore veloce può comportarsi come monocore per quel tunnel. WireGuard nel kernel distribuisce il lavoro tra le CPU, e l'offload del canale dati di OpenVPN sposta anch'esso la gestione dei pacchetti nel kernel, ma solo su build e piattaforme che lo supportano. Un'affermazione di accelerazione hardware sulla pagina marketing non è prova che il percorso di codice che esegui la usi.

Passo 5: Decidi cosa cambiare, in quest'ordine

Scendi lungo questo elenco e fermati alla prima riga vera, perché cambiare qualsiasi cosa sotto non muoverà il numero.

1. Il throughput diretto via cavo è sotto quello che paghi: parla con il fornitore, perché il tunnel non può creare capacità che il circuito di accesso non fornisce. 2. Il diretto via cavo va bene ma un core si inchioda durante il test del tunnel: il percorso crittografico del router è il limite. 3. La CPU è inattiva ma il tunnel è lento: controlla MTU e frammentazione, poi la capacità dell'estremità remota stessa. 4. Solo i client Wi-Fi sono lenti: cambia banda o larghezza di canale, e accetta che la velocità dichiarata non sia mai stata un numero VPN.

Quando il router è davvero il limite, le opzioni oneste sono un dispositivo con istruzioni AES e un percorso di inoltro più veloce, un tunnel lato kernel come WireGuard invece di uno nello spazio utente, o spostare il client sul dispositivo stesso perché il router smetta di cifrare. Spegnere la cifratura autenticata per vincere un benchmark non è una di queste; scambia una proprietà di sicurezza con un numero che comunque non corrisponderà alla scatola.

Prima di comprare qualsiasi cosa, riesegui i passi 2 e 3 sul nuovo dispositivo con lo stesso server e la stessa durata, poi confronta rapporti invece di picchi.