VPN-upload langzamer dan download? Bepaal welke limiet u raakt

De meeste toegangslijnen zijn asymmetrisch, dus een tunnel uploadt meestal langzamer dan hij downloadt, en dat is het verwachte antwoord en geen fout. De interessante vraag is of uw upload wordt beperkt door de lijn, door iets anders dat hem al gebruikt, of door een stroom die stokt in plaats van gelijkmatig te lopen. Die drie veroorzaken dezelfde klacht en vragen ander werk.

Drie limieten die er vanaf de voortgangsbalk hetzelfde uitzien

Capaciteit is de eerste, en die is een eigenschap van het toegangsproduct, niet van de tunnel. Een uplink van een paar megabit is normaal op glasvezel voor consumenten en op veel mobiele abonnementen, en de kosten van versleuteling zijn klein vergeleken met dat gat. Encapsulatie voegt ook bytes per pakket toe, wat de nuttige doorvoer in beide richtingen verlaagt en niet slechts in één, dus kan het alleen geen grote asymmetrie verklaren.

Concurrentie is de tweede. Cloudsynchronisatie, fotobibliotheken en update-agents uploaden terwijl de machine inactief lijkt, en een tweede apparaat op dezelfde lijn doet hetzelfde. Wachtrijvorming is de derde: een verzadigde uplink duwt interactief verkeer achter bulkdata, waardoor gesprekken wegvallen terwijl de overdracht zelf gezonde voortgang meldt.

Meet één richting tegelijk

Gebruik hetzelfde apparaat, hetzelfde profiel en dezelfde bestemming, en laat nooit beide richtingen tegelijk lopen, tenzij concurrentie precies is wat u wilt observeren. Pauzeer uw eigen optionele overdrachten voor de eerste run. Twee runs met één vlag ertussen beslechten het meeste.

iperf3 stuurt standaard vanaf de client, dus de gewone run meet uw uploadpad; -R keert de richting om en meet de download. Voer ze met een paar minuten ertussen uit en noteer beide getallen in plaats van ze te middelen:

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

Als het uploadgetal een kleine fractie is van het downloadgetal en stabiel blijft tussen runs, past de vorm bij een asymmetrische toegangslijn en is de tunnel niet het verhaal. Als de upload tussen runs schommelt of na tien seconden instort, lees dan verder.

Bepaal aan de hand van waar de upload verandert

Wijzig één variabele tegelijk en kijk welke richting beweegt. Een tweede VPN-eindpunt dat beter uploadt, wijst op dat eindpunt of de route ernaartoe. Dezelfde langzame upload vanaf een tweede apparaat op dezelfde lijn wijst op de lijn. Een ander apparaat op een andere lijn dat ook langzaam is, wijst op het inkomende beleid van de bestemming, dat u lokaal niet kunt oplossen.

Noteer bytes per seconde en verstreken tijd voor dezelfde werklast, niet één snelheidsscore. Een back-upclient en een snelheidstest gebruiken verschillende bestemmingen en verschillende gelijktijdigheid, dus hun getallen vergelijken beantwoordt niets. Als kleine verzoeken goed gaan en alleen grote overdrachten kruipen, is de limiet waarschijnlijk helemaal niet de bandbreedte.

Voor dagelijks gebruik helpt het vaak meer dan welke tunnelinstelling dan ook om een upload op de achtergrond te beperken of buiten vergadertijden te plannen. Beoordeel die verandering aan de gecombineerde werklast: een back-up die later klaar is maar geen gesprekken meer verpest, is meestal de betere ruil.

Wanneer stokken het wint van traagheid

Een overdracht die op een herhaalbaar punt bevriest en daarna verdergaat, gedraagt zich als een MTU-probleem van het pad en niet als een snelheidslimiet. De tunnel verkleint de bruikbare payload per pakket, en een apparaat dat het resulterende ICMP-bericht laat vallen, laat de afzender gissen. Dat patroon verdient zijn eigen test, want de reparatie verschilt van het afstellen van een snelheid. Een stabiel laag getal wijst op capaciteit, terwijl een uitbarsting gevolgd door stilte wijst op een payload die het pad niet kan dragen.

Test het pad met een payload die niet gefragmenteerd mag worden, en vergelijk daarna de MTU van de tunnelinterface met de waarde die erdoor komt:

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

Als de grote probe verdwijnt terwijl een kleinere slaagt, knijp dan de TCP MSS op de tunnel in plaats van de interface-MTU voor elk protocol te verlagen. Aanhoudende stagnatie na dat punt hoort bij de opslag of het tempo van de ontvangende toepassing, niet bij het netwerkpad.

Wat u moet veranderen en wat u moet laten

Verander de dingen die u beheert: schema's voor achtergrondoverdrachten, de keuze van het eindpunt en de MSS voor een stagnerend pad. Houd elke wijziging omkeerbaar en beperkt tot één werklast. Laat de dingen met rust waarvan de meting zegt dat ze in orde zijn, inclusief een downloadsnelheid die al bij de lijn past.

Schrijf de getallen voor en na op samen met het profiel, het eindpunt en het tijdstip van de dag, want een uploadprobleem dat met het eindpunt meebeweegt is een routeringsvraag, en een dat met het apparaat meebeweegt is lokaal. Die registratie is wat een vage klacht in een beslissing verandert, en het kost twee runs van hetzelfde commando.