Laster VPN opp tregere enn det laster ned? Avgjør hvilken grense du treffer

De fleste aksesslinjer er asymmetriske, så en tunnel laster vanligvis opp langsommere enn den laster ned, og det er det forventede svaret, ikke en feil. Det interessante spørsmålet er om opplastingen begrenses av linjen, av noe annet som allerede bruker den, eller av en flyt som stopper i stedet for å gå jevnt. Disse tre gir samme klage og krever forskjellig arbeid.

Tre grenser som ser like ut fra fremdriftslinjen

Kapasitet er den første, og den er en egenskap ved aksessproduktet, ikke ved tunnelen. En oppstrømsforbindelse på noen få megabit er normal på forbrukerfiber og på mange mobilabonnementer, og kostnaden ved kryptering er liten sammenlignet med det gapet. Innkapsling legger også til bytes per pakke, noe som reduserer den nyttige gjennomstrømningen i begge retninger og ikke bare én, så den kan ikke alene forklare en stor asymmetri.

Konkurranse er den andre. Skysynkronisering, fotobiblioteker og oppdateringsagenter laster opp mens maskinen ser ledig ut, og en annen enhet på samme linje gjør det samme. Kø er den tredje: en mettet oppstrømsforbindelse skyver interaktiv trafikk bak bulkdata, så samtaler brytes mens selve overføringen rapporterer sunn fremgang.

Mål én retning om gangen

Bruk samme enhet, samme profil og samme destinasjon, og kjør aldri begge retninger samtidig med mindre konkurranse er nettopp det du vil observere. Sett dine egne valgfrie overføringer på pause før første kjøring. To kjøringer med ett flagg mellom avgjør det meste.

iperf3 sender fra klienten som standard, så den vanlige kjøringen måler oppstrømsveien din; -R snur retningen og måler nedlasting. Kjør dem med noen minutters mellomrom og noter begge tallene i stedet for å gjennomsnittsberegne:

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

Hvis opplastingstallet er en liten brøkdel av nedlastingstallet og holder seg stabilt mellom kjøringer, passer formen med en asymmetrisk aksesslinje og tunnelen er ikke historien. Hvis opplastingen svinger mellom kjøringer eller kollapser etter ti sekunder, les videre.

Avgjør etter hvor opplastingen endrer seg

Endre én variabel om gangen og se hvilken retning som beveger seg. Et annet VPN-endepunkt som laster opp bedre peker på det endepunktet eller ruten dit. Den samme langsomme opplastingen fra en annen enhet på samme linje peker på linjen. En annen enhet på en annen linje som også er langsom peker på destinasjonens inngangspolicy, som du ikke kan rette lokalt.

Noter bytes per sekund og medgått tid for samme arbeidsbelastning, ikke én enkelt hastighetsscore. En sikkerhetskopiklient og en hastighetstest bruker forskjellige destinasjoner og forskjellig samtidighet, så sammenligning av tallene deres svarer ikke på noe. Hvis små forespørsler er fine og bare store overføringer kryper, er grensen sannsynligvis ikke båndbredde i det hele tatt.

Til daglig bruk hjelper det ofte mer enn noen tunnelinnstilling å begrense en bakgrunnsopplasting eller planlegge den utenfor møtetimene. Vurder den endringen etter den samlede arbeidsbelastningen: en sikkerhetskopi som blir ferdig senere men ikke lenger ødelegger samtaler er vanligvis den bedre handelen.

Når stopping slår langsomhet

En overføring som fryser på et repeterbart punkt og deretter fortsetter, oppfører seg som et MTU-problem på ruten og ikke som en hastighetsgrense. Tunnelen reduserer den brukbare nyttelasten per pakke, og en enhet som slipper den resulterende ICMP-meldingen, lar senderen gjette. Det mønsteret fortjener sin egen test, fordi reparasjonen er forskjellig fra å justere en hastighet. Et stabilt lavt tall peker på kapasitet, mens et utbrudd etterfulgt av stillhet peker på en nyttelast som ruten ikke kan bære.

Test ruten med en nyttelast som ikke må fragmenteres, og sammenlign deretter tunnelgrensensnittets MTU med verdien som 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 sonden forsvinner mens en mindre lykkes, skal du klemme TCP MSS på tunnelen i stedet for å senke grensesnittets MTU for hver protokoll. Vedvarende stopp etter det punktet tilhører det mottakende programmets lagring eller takt, ikke nettverksruten.

Hva du bør endre, og hva du bør la være

Endre tingene du kontrollerer: tidsplaner for bakgrunnsoverføringer, valg av endepunkt og MSS for en rute som stopper. Hold hver endring reversibel og begrenset til én arbeidsbelastning. La tingene som målingen sier er fine være, inkludert en nedlastingshastighet som allerede passer til linjen.

Skriv ned tallene før og etter sammen med profil, endepunkt og tid på dagen, fordi et opplastingsproblem som flytter seg med endepunktet er et rutingspørsmål, og ett som flytter seg med enheten er lokalt. Den registreringen er det som gjør en vag klage til en beslutning, og den koster to kjøringer av samme kommando.