Miért ilyen lassú a VPN-em? Tesztelje ezt a négy szakaszt

Az akadozó hívás, a vánszorgó letöltés és a félúton megfagyó feltöltés három különböző panasz egyetlen címke alatt. Ha még bármit mérne, eldönti, melyiket kergeti, az megspórolja a nyomozás többi részét. Ezután egyszerre csak az útvonal egy szakaszát változtassa meg, és utána ismételje meg ugyanazt a feladatot.

Az alábbi sorrend a feladattól kifelé halad, mert az alagút nem tud olyan sávszélességet adni, amely alatta hiányzik.

Döntse el, mit jelent a lassú, mielőtt mér

Az alacsony, egyenletes sebesség, az éles csúcsokkal járó magas késleltetés és az az átvitel, amely egy rögzített méretnél teljesen megáll, nem egyetlen hiba változatai. Mindegyik más szakaszra mutat: az átbocsátóképességre, magára az útvonalra vagy a csomagméret korlátjára. Válassza azt a feladatot, amely valóban zavarja, és használja referenciaként, mert a sebességteszt egy tömeges átvitelt mér, amely teljesen másképp viselkedhet, mint egy videóhívás. Jegyezze fel a végpontot, a protokollt, a napszakot és azt a számot, amely Önnek számít.

E feljegyzés nélkül minden későbbi összehasonlítás benyomásokról szóló vitává válik.

Először a hozzáférési hálózatot ellenőrizze

Szüneteltesse a saját nagy átviteleit, majd mérje meg a helyi kapcsolatot, mielőtt az alagút bekerül a képbe. Hasonlítsa össze egy ártalmatlan feladattal, és kövesse az ügyfél kill switch eljárását ahelyett, hogy egyszerre több védelmet kapcsolna ki, és mindkét futásnál tartsa meg ugyanazt a célt. A sebességteszt-szolgáltató más mérőszervert adhat Önnek, amint a látható helyzete megváltozik, ami az összehasonlítást két különböző szerver tesztjévé teszi.

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

Ha az alapvonal már rossz, a munka a Wi-Fi-re, a router terhelésére vagy a hozzáférési szolgáltatásra tartozik. A vezetékes teszt vagy a hozzáférési pont közelében felvett mozdulatlan helyzet elválasztja a gyenge rádiókapcsolatot a túlterhelt feltöltési vonaltól. Semmi, amit az alagút tesz, nem ad hozzá olyan kapacitást, amelyet a hozzáférési vonal nem szállít.

Cserélje a kimenetet, majd a szállítást

Tartsa rögzítve az eszközt, a hálózatot és a protokollt, és teszteljen egy második végpontot. Válasszon hihető várost a helyszínlistáról, de ne feltételezze, hogy a legközelebbi címke a legjobb útvonalat jelenti. Ha az egyik kijárat lassú, a többi pedig rendben van, a gazdagépe vagy az útvonala megérdemli a vizsgálatot; ha egy eszközön minden kijárat lassú, miközben egy másik eszköz rendben van, az ügyfél a jobb gyanúsított.

Ahol a szolgáltatás mindkét profilt kínálja, hasonlítsa össze az OpenVPN UDP-n keresztüli változatát az OpenVPN TCP-n keresztüli változatával. Az UDP az interaktív munka szokásos kiindulópontja, míg a TCP segíthet olyan hozzáférési hálózaton, amely egyáltalán nem engedi át az UDP-forgalmat. A TCP-alagút az adatfolyamon belüli újraküldéssel pótolja a veszteséget, ezért tűnhet lassabbnak egy csomagokat eldobó vonalon, és az OpenVPN teljesítményproblémák elhárításáról szóló jegyzetek ugyanezt a kompromisszumot tárgyalják, mielőtt bármi mást hangolna. Ha egy profilban az "udp" szót "tcp"-re cseréli, az nem hozhat létre olyan figyelőt, amelyet a szerver soha nem nyitott meg.

Mentse el a segítő profilt, mielőtt a következő változtatást kipróbálja. Különben egy későbbi visszaesés magára hagyja a találgatással, melyik módosítás hozta a javulást.

Az eszközt és a tünetet együtt olvassa

Átvitel közben figyelje a processzor terhelését, ne utána, mert a titkosítás költsége a forgalommal nő, és egy háztartást kiszolgáló kis router más gép, mint egy saját ügyfelet futtató laptop. Egy másik VPN, egy virtuális gép vagy egy hálózati szűrő ugyanazon az útvonalon ülhet, és elveheti a forgalom egy részét. Tartsa naprakészen a szoftvert anélkül, hogy eltávolítaná a hitelesítési ellenőrzéseket vagy egy kill switch-et, hogy jobban nézzen ki egy benchmark. Ha a kis kérések sikerülnek, a nagy feltöltések pedig egy állandó méretnél elakadnak, a következő állomás az MTU-ellenőrzés.

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

Ha az alagút ismételten visszaáll, javítsa ki a szakadásokat, mielőtt bármilyen átbocsátási számot értelmezne, mert az újracsatlakozó alagút a kézfogást méri, nem az útvonalat. Minden változtatás után ismételje meg az eredeti feladatot, és őrizze meg az eredményt. Egy gyorsabb sebességteszt, amely még mindig megszakítja a hívást, nem oldotta meg a panaszt, amellyel elkezdte.