Caricamento VPN più lento del download? Capite quale limite incontrate

La maggior parte delle linee di accesso è asimmetrica, quindi un tunnel di solito carica più lentamente di quanto scarichi, e questa è la risposta attesa, non un guasto. La domanda interessante è se il vostro caricamento è limitato dalla linea, da qualcos’altro che la usa già, o da un flusso che si blocca invece di procedere in modo costante. Questi tre producono la stessa lamentela e richiedono un lavoro diverso.

Tre limiti che dalla barra di avanzamento sembrano identici

La capacità è il primo, ed è una proprietà del prodotto di accesso, non del tunnel. Un uplink di pochi megabit è normale su fibra residenziale e su molti piani mobili, e il costo della cifratura è piccolo rispetto a quel divario. L’incapsulamento aggiunge anche byte per pacchetto, il che riduce il throughput utile in entrambe le direzioni e non solo in una, quindi da solo non può spiegare un’asimmetria ampia.

La contesa è il secondo. La sincronizzazione cloud, le librerie fotografiche e gli agenti di aggiornamento caricano mentre la macchina sembra inattiva, e un secondo dispositivo sulla stessa linea fa lo stesso. La coda è il terzo: un uplink saturo spinge il traffico interattivo dietro i dati di massa, così le chiamate si interrompono mentre il trasferimento stesso riporta un avanzamento sano.

Misurate una direzione alla volta

Usate lo stesso dispositivo, lo stesso profilo e la stessa destinazione, e non eseguite mai entrambe le direzioni insieme, a meno che la contesa sia proprio ciò che volete osservare. Mettete in pausa i vostri trasferimenti facoltativi prima della prima esecuzione. Due esecuzioni con un flag tra loro risolvono la maggior parte.

iperf3 invia dal client per impostazione predefinita, quindi l’esecuzione semplice misura il percorso di caricamento; -R inverte la direzione e misura il download. Eseguitele a qualche minuto di distanza e registrate entrambi i numeri invece di fare la media:

iperf3 -c speed.example.net -t 30 -P 4
iperf3 -c speed.example.net -t 30 -P 4 -R

Se la cifra di caricamento è una piccola frazione di quella di download e resta stabile tra le esecuzioni, la forma corrisponde a una linea di accesso asimmetrica e il tunnel non è la storia. Se il caricamento oscilla tra le esecuzioni o crolla dopo dieci secondi, continuate a leggere.

Decidete da dove cambia il caricamento

Cambiate una variabile alla volta e osservate quale direzione si muove. Un secondo endpoint VPN che carica meglio indica quell’endpoint o la rotta verso di esso. Lo stesso caricamento lento da un secondo dispositivo sulla stessa linea indica la linea. Un dispositivo diverso su una linea diversa, anch’esso lento, indica la politica di ingresso della destinazione, che non potete correggere localmente.

Registrate byte al secondo e tempo trascorso per lo stesso carico, non un unico punteggio di velocità. Un client di backup e un test di velocità usano destinazioni e concorrenza diverse, quindi confrontare i loro numeri non risponde a nulla. Se le richieste piccole vanno bene e strisciano solo i trasferimenti grandi, il limite probabilmente non è affatto la larghezza di banda.

Per l’uso quotidiano, limitare un caricamento in background o programmarlo fuori dagli orari delle riunioni aiuta spesso più di qualsiasi impostazione del tunnel. Valutate quel cambiamento sul carico combinato: un backup che finisce più tardi ma non rovina più le chiamate è di solito lo scambio migliore.

Quando il blocco vince la lentezza

Un trasferimento che si congela in un punto ripetibile e poi riprende si comporta come un problema di MTU del percorso, non come un limite di velocità. Il tunnel riduce il carico utile per pacchetto, e un dispositivo che scarta il messaggio ICMP risultante lascia il mittente a indovinare. Quel modello merita un test proprio, perché la riparazione è diversa dal regolare una velocità. Un numero basso e stabile indica la capacità, mentre un picco seguito dal silenzio indica un carico che il percorso non riesce a portare.

Provate il percorso con un carico che non deve essere frammentato, poi confrontate la MTU dell’interfaccia del tunnel con il valore che passa:

ping -M do -s 1400 -c 3 203.0.113.10
ip link show dev tun0 | grep -o "mtu [0-9]*"

Se la sonda grande scompare mentre una più piccola riesce, stringete il TCP MSS sul tunnel invece di abbassare la MTU dell’interfaccia per ogni protocollo. I blocchi persistenti dopo quel punto appartengono all’archiviazione o al ritmo dell’applicazione ricevente, non al percorso di rete.

Cosa cambiare e cosa lasciare

Cambiate le cose che controllate: le pianificazioni dei trasferimenti in background, la scelta dell’endpoint e la MSS per un percorso che si blocca. Mantenete ogni cambiamento reversibile e limitato a un carico. Lasciate in pace le cose che la misura dice essere a posto, inclusa una velocità di download che già corrisponde alla linea.

Annotate i numeri prima e dopo insieme al profilo, all’endpoint e all’ora del giorno, perché un problema di caricamento che si sposta con l’endpoint è una questione di routing, e uno che si sposta con il dispositivo è locale. È quel registro che trasforma una lamentela vaga in una decisione, e costa due esecuzioni dello stesso comando.