Waarom is mijn VPN zo langzaam? Test deze vier segmenten
Bepaal welk soort traagheid je hebt en test daarna de toegangslijn, de uitgang, het transport en het apparaat in die volgorde, met één wijziging tegelijk.
Een gesprek dat hapert, een download die kruipt en een upload die halverwege bevriest zijn drie verschillende klachten onder één label. Bepalen welke je achtervolgt voordat je iets meet, bespaart de rest van het onderzoek. Wijzig daarna één segment van het pad per keer en herhaal dezelfde taak daarna.
De volgorde hieronder beweegt van de taak naar buiten, omdat de tunnel geen bandbreedte kan leveren die eronder ontbreekt.
Bepaal wat langzaam betekent voordat je meet
Een lage gelijkmatige snelheid, een hoge latentie met scherpe pieken en een overdracht die bij een vaste grootte abrupt stopt zijn geen variaties van één storing. Elk wijst op een ander segment: de doorvoer, het pad zelf of een limiet op de pakketgrootte. Kies de taak die je echt stoort en gebruik die als referentie, want een snelheidstest meet een bulkoverdracht die zich heel anders kan gedragen dan een videogesprek. Noteer het eindpunt, het protocol, het tijdstip van de dag en het getal dat voor jou telt.
Zonder die registratie wordt elke latere vergelijking een discussie over indrukken.
Controleer eerst het toegangsnetwerk
Pauzeer je eigen grote overdrachten en meet daarna de lokale verbinding voordat de tunnel in beeld komt. Vergelijk met een onschuldige taak en volg de kill switch-procedure van de client in plaats van meerdere beschermingen tegelijk uit te schakelen, en houd dezelfde bestemming aan voor beide runs. Een aanbieder van snelheidstests kan je een andere meetserver geven zodra je zichtbare locatie verandert, waardoor de vergelijking een test van twee verschillende servers wordt.
ping -c 20 192.168.50.1
ping -c 20 198.51.100.7
curl -o /dev/null -w "%{time_starttransfer} %{speed_download}\n" https://speed.example.net/10mb.bin
Als de basislijn al slecht is, hoort het werk bij Wi-Fi, routerbelasting of de toegangsdienst. Een bedrade test of een vaste positie bij het toegangspunt scheidt een zwakke radiolink van een overbelaste uplink. Niets wat de tunnel doet voegt capaciteit toe die de toegangslijn niet levert.
Wissel de uitgang, dan het transport
Houd het apparaat, het netwerk en het protocol vast en test een tweede eindpunt. Kies een plausibele stad uit de locatielijst, maar ga er niet van uit dat het dichtstbijzijnde label de beste route betekent. Als één uitgang traag is en andere zijn in orde, verdient de host of het pad ervan het onderzoek; als alle uitgangen traag zijn op één apparaat terwijl een ander apparaat in orde is, is de client de betere verdachte.
Waar de dienst beide profielen levert, vergelijk OpenVPN over UDP met OpenVPN over TCP. UDP is het gebruikelijke startpunt voor interactief werk, terwijl TCP kan helpen op een toegangsnetwerk dat UDP-verkeer helemaal niet doorlaat. Een TCP-tunnel herstelt verlies door binnen de stream opnieuw te verzenden, waardoor hij trager kan aanvoelen op een verbinding die pakketten laat vallen, en de OpenVPN-notities over het oplossen van prestatieproblemen behandelen dezelfde afweging voordat je iets anders afstelt. Het woord "udp" in een profiel naar "tcp" veranderen kan geen luisteraar maken die de server nooit heeft geopend.
Bewaar het profiel dat helpt voordat je de volgende wijziging probeert. Anders laat een latere terugval je raden welke bewerking de verbetering opleverde.
Lees het apparaat en het symptoom samen
Let tijdens de overdracht op de processorbelasting in plaats van erna, want de kosten van versleuteling schalen met het verkeer en een kleine router die een huishouden bedient is een andere machine dan een laptop met zijn eigen client. Een andere VPN, een virtuele machine of een netwerkfilter kan in hetzelfde pad zitten en een deel van het verkeer opeisen. Houd de software actueel zonder authenticatiecontroles of een kill switch te verwijderen om een benchmark er beter uit te laten zien. Als kleine verzoeken slagen en grote uploads bij een gelijkblijvende grootte vastlopen, is de MTU-controle de volgende stop.
ping -M do -s 1400 -c 3 198.51.100.7
ip link show dev tun0 | grep -o "mtu [0-9]*"
Als de tunnel herhaaldelijk reset, los dan de onderbrekingen op voordat je enig doorvoergetal interpreteert, want een tunnel die opnieuw verbindt meet de handdruk en niet het pad. Herhaal de oorspronkelijke taak na elke wijziging en bewaar het resultaat. Een snellere snelheidstest die het gesprek nog steeds breekt heeft de klacht waarmee je begon niet opgelost.