Uploade i VPN langsommere end downloade? Afgør hvilken grænse du rammer

De fleste adgangslinjer er asymmetriske, så en tunnel vil normalt uploade langsommere, end den downloader, og det er det forventede svar frem for en fejl. Det interessante spørgsmål er, om din upload begrænses af linjen, af noget andet, der allerede bruger den, eller af et flow, der går i stå i stedet for at køre jævnt. De tre giver samme klage og kræver forskelligt arbejde.

Tre grænser, der ser ens ud fra statuslinjen

Kapacitet er den første, og den er en egenskab ved adgangsproduktet snarere end ved tunnelen. En opstrømsforbindelse på nogle få megabit er normal på fiber til private og på mange mobilabonnementer, og omkostningen ved kryptering er lille sammenlignet med det gab. Indkapsling tilføjer også bytes per pakke, hvilket skærer den nyttige gennemstrømning i begge retninger og ikke kun i én, så den kan ikke alene forklare en stor asymmetri.

Konkurrence er den anden. Cloudsynkronisering, fotobiblioteker og opdateringsagenter uploader, mens maskinen ser ledig ud, og en anden enhed på samme linje gør det samme. Kødannelse er den tredje: en mættet opstrømsforbindelse skubber interaktiv trafik bag bulkdata, så opkald går i stykker, mens selve overførslen rapporterer sund fremgang.

Mål én retning ad gangen

Brug samme enhed, samme profil og samme destination, og kør aldrig begge retninger samtidig, medmindre konkurrence er det, du vil observere. Sæt dine egne valgfrie overførsler på pause før første kørsel. To kørsler med et flag imellem dem afgør det meste.

iperf3 sender fra klienten som standard, så den almindelige kørsel måler din opstrømsvej; -R vender retningen og måler download. Kør dem med minutters mellemrum og notér begge tal i stedet for at gennemsnitlige dem:

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

Hvis uploadtallet er en lille brøkdel af downloadtallet og forbliver stabilt på tværs af kørsler, svarer formen til en asymmetrisk adgangslinje, og tunnelen er ikke historien. Hvis upload svinger mellem kørsler eller falder sammen efter ti sekunder, så læs videre.

Afgør ud fra hvor uploaden ændrer sig

Ændr én variabel ad gangen og se, hvilken retning der flytter sig. Et andet VPN-endepunkt, der uploader bedre, peger på det endepunkt eller ruten dertil. Den samme langsomme upload fra en anden enhed på samme linje peger på linjen. En anden enhed på en anden linje, som også er langsom, peger på destinationens indgangspolitik, som du ikke kan rette lokalt.

Notér bytes per sekund og forløbet tid for samme arbejdsbyrde, ikke en enkelt hastighedsscore. En backupklient og en hastighedstest bruger forskellige destinationer og forskellig samtidighed, så en sammenligning af deres tal svarer ikke på noget. Hvis små forespørgsler er fine, og kun store overførsler kravler, er grænsen sandsynligvis slet ikke båndbredde.

Til daglig brug hjælper det ofte mere end nogen tunnelindstilling at begrænse en baggrundsupload eller planlægge den uden for mødetimer. Bedøm den ændring ud fra den samlede arbejdsbyrde: en backup, der slutter senere, men ikke længere ødelægger opkald, er normalt den bedre handel.

Når stop slår langsomhed

En overførsel, der fryser på et gentageligt punkt og derefter genoptages, opfører sig som et MTU-problem på ruten snarere end en hastighedsgrænse. Tunnelen reducerer den brugbare nyttelast pr. pakke, og en enhed, der dropper den resulterende ICMP-meddelelse, lader afsenderen gætte. Det mønster fortjener sin egen test, fordi reparationen er anderledes end at justere en hastighed. Et stabilt lavt tal peger på kapacitet, mens et udbrud efterfulgt af tavshed peger på en nyttelast, som ruten ikke kan bære.

Test ruten med en nyttelast, der ikke må fragmenteres, og sammenlign derefter tunnelinterfacens MTU med den værdi, der passerer:

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

Hvis den store sonde forsvinder, mens en mindre lykkes, skal du klemme TCP MSS på tunnelen i stedet for at sænke interface-MTU’en for hver protokol. Vedvarende stop efter det punkt hører til det modtagende programs lager eller pacing, ikke til netværksruten.

Hvad du skal ændre, og hvad du skal lade være

Ændr de ting, du styrer: tidsplaner for baggrundsoverførsler, valg af endepunkt og MSS for en rute, der går i stå. Hold hver ændring reversibel og afgrænset til én arbejdsbyrde. Lad de ting være, som målingen siger er fine, inklusive en downloadhastighed, der allerede matcher linjen.

Skriv tallene før og efter ned sammen med profil, endepunkt og tidspunkt på dagen, fordi et uploadproblem, der flytter sig med endepunktet, er et routingspørgsmål, og et, der flytter sig med enheden, er lokalt. Den registrering er det, der gør en vag klage til en beslutning, og den koster to kørsler af samme kommando.