La pujada del VPN és més lenta que la baixada? Decidiu quin límit trobeu

La majoria de línies d’accés són asimètriques, així que un túnel normalment puja més lentament del que baixa, i aquesta és la resposta esperada, no un defecte. La pregunta interessant és si la pujada està limitada per la línia, per una altra cosa que ja la fa servir, o per un flux que s’encalla en lloc d’anar estable. Aquests tres produeixen la mateixa queixa i necessiten feines diferents.

Tres límits que des de la barra de progrés semblen idèntics

La capacitat és el primer, i és una propietat del producte d’accés, no del túnel. Un enllaç ascendent de pocs megabits és normal en fibra de consum i en molts plans mòbils, i el cost del xifratge és petit comparat amb aquesta diferència. L’encapsulament també afegeix bytes per paquet, cosa que retalla el rendiment útil en tots dos sentits i no només en un, així que no pot explicar per si sol una asimetria gran.

La competència és el segon. La sincronització al núvol, les fototeques i els agents d’actualització pugen mentre l’equip sembla inactiu, i un segon dispositiu a la mateixa línia fa el mateix. La cua és el tercer: un enllaç ascendent saturat empeny el trànsit interactiu darrere de les dades massives, de manera que les trucades es tallen mentre la transferència mateixa informa d’un progrés saludable.

Mesureu un sentit alhora

Feu servir el mateix dispositiu, el mateix perfil i la mateixa destinació, i no executeu mai els dos sentits alhora tret que vulgueu observar precisament la competència. Atureu les vostres transferències opcionals abans de la primera execució. Dues execucions amb una bandera entremig resolen la major part del problema.

iperf3 envia des del client per defecte, així que l’execució simple mesura el camí de pujada; -R inverteix el sentit i mesura la baixada. Executeu-les amb uns minuts de diferència i anoteu tots dos números en lloc de fer-ne la mitjana:

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

Si la xifra de pujada és una fracció petita de la de baixada i es manté estable entre execucions, la forma correspon a una línia d’accés asimètrica i el túnel no hi té res a veure. Si la pujada oscil·la entre execucions o s’enfonsa al cap de deu segons, continueu llegint.

Decidiu per on canvia la pujada

Canvieu una variable alhora i observeu quin sentit es mou. Un segon punt final de VPN que puja millor assenyala aquell punt final o la ruta fins a ell. La mateixa pujada lenta des d’un segon dispositiu a la mateixa línia assenyala la línia. Un dispositiu diferent en una línia diferent que també és lent assenyala la política d’entrada de la destinació, que no podeu arreglar localment.

Anoteu bytes per segon i temps transcorregut per a la mateixa càrrega, no una única puntuació de velocitat. Un client de còpies de seguretat i una prova de velocitat fan servir destinacions i concurrències diferents, així que comparar-ne les xifres no respon res. Si les peticions petites van bé i només arrosseguen les transferències grans, el límit probablement no és l’amplada de banda.

Per a l’ús diari, limitar una pujada en segon pla o programar-la fora de les hores de reunió sovint ajuda més que qualsevol ajust del túnel. Jutgeu aquest canvi per la càrrega combinada: una còpia de seguretat que acaba més tard però ja no espatlla les trucades sol ser el millor intercanvi.

Quan encallar-se guanya la lentitud

Una transferència que es congela en un punt repetible i després es reprèn es comporta com un problema d’MTU del camí, no com un límit de velocitat. El túnel redueix la càrrega útil per paquet, i un dispositiu que descarta el missatge ICMP resultant deixa el remitent endevinant. Aquest patró mereix una prova pròpia, perquè la reparació és diferent d’ajustar una velocitat. Una xifra baixa i estable assenyala capacitat, mentre que un esclat seguit de silenci assenyala una càrrega que el camí no pot portar.

Proveu el camí amb una càrrega que no s’hagi de fragmentar i compareu després l’MTU de la interfície del túnel amb el valor que passa:

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

Si la sonda gran desapareix mentre una de petita té èxit, estrènyeu el TCP MSS al túnel en lloc de baixar l’MTU de la interfície per a cada protocol. Les aturades persistents després d’aquest punt pertanyen a l’emmagatzematge o al ritme de l’aplicació receptora, no al camí de xarxa.

Què cal canviar i què cal deixar

Canvieu les coses que controleu: els horaris de transferència en segon pla, l’elecció de punt final i l’MSS per a un camí que s’encalla. Mantingueu cada canvi reversible i limitat a una càrrega. Deixeu tranquil·les les coses que el mesurament diu que van bé, inclosa una velocitat de baixada que ja coincideix amb la línia.

Anoteu les xifres d’abans i de després amb el perfil, el punt final i l’hora del dia, perquè un problema de pujada que es mou amb el punt final és una qüestió d’encaminament i un que es mou amb el dispositiu és local. Aquest registre és el que converteix una queixa vaga en una decisió, i costa dues execucions de la mateixa ordre.