Miért nem jósolja meg a router Wi-Fi minősítése a VPN átbocsátóképességét
A hirdetett Wi-Fi sebesség és a mért VPN sebesség különböző rétegeket ír le. Járja végig ezt a rendezett ellenőrzést, mielőtt gyorsabb routert vásárol.
Egy 3,000 Mbps-os Wi-Fi jelzéssel ellátott router még mindig csak e szám töredékével képes továbbítani a titkosított forgalmat, és egyik szám sem tisztességtelen. A rádióminősítés a chipkészlet által támogatott vezeték nélküli kapcsolat legjobb esetben elérhető modulációját írja le; a VPN-szám azt írja le, milyen gyorsan tud egyetlen eszköz titkosított csomagokat átnyomni a router processzorán és ki a hozzáférési körén. Ezek különböző rétegek, különböző csomagméretek és különböző mérési módszerek. A dobozon lévő számot olyan plafonnak tekintse, amelyet senki nem ér el, nem pedig az alagút sebességének előrejelzésének.
Lépés 1: Térképezze fel a számot korlátozó négy réteget
Szinte minden lassú routerről szóló panasz, amellyel dolgoztam, négy szint valamelyikébe esik: a vezeték nélküli kapcsolat, a WAN-hozzáférési sebesség, a továbbítási útvonal (NAT, tűzfal, kapcsolatkövetés) vagy a VPN kripto útvonala. Ezek egymásra rakódnak, és a leglassabb szint határozza meg az eredményt. A hirdetett Wi-Fi sebesség csak az első szintről beszél, és bőkezűen beszél róla.
Ez a szám a streamek számából, a csatornaszélességből és a chipkészlet által kialkudható legmagasabb modulációból adódik. Az 5 GHz-en, 80 MHz-en, 1024-QAM-mal működő 2x2 rádiót 1,200 Mbps körül hirdetik, de a Wi-Fi megosztott, félduplex médium: az ügyfelek váltják egymást, az újraküldések és a kezelési forgalom elégeti a légi időt, és a TCP hozzáadja a saját többletét. Egy ügyfél, amely ideális körülmények között a legmagasabb sebességet alkudja ki, általában jóval a fele alatt mér, és még kevesebbet, amint szomszédos hálózatok jelennek meg.
| Symptom | Tier to suspect first |
|---|---|
| Wired clients are slow too | WAN access or forwarding path |
| Only Wi-Fi clients are slow | Radio, airtime, or channel width |
| One stream is slow, four parallel streams add up | Per-connection CPU path, not the link |
| Every stream is slow and one core sits at 100% | Crypto path |
| Fast to LAN hosts, slow to the internet | WAN, not the tunnel |
Ha a táblázat a rádióra mutat, először a vezeték nélküli oldalt javítsa: sáv, csatornaszélesség, távolság. Ha a rádió alá mutat, a következő négy lépés számít, és semmilyen antenna-vásárlás nem változtat rajta.
Lépés 2: Vegyen vezetékes alapvonalat, mielőtt a rádióhoz nyúlna
Tegye a laptopot Ethernetre, és először mérje meg az útvonalat az alagút nélkül, mert ez adja a nevezőt. Futtassa az átbocsátóképesség-eszközt a túloldalon, a VPN-t lezáró VPS-en vagy otthoni szerveren, és irányítsa az ügyfelet annak nyilvános címére, hogy a forgalom átmenjen a routerén és a hozzáférési körén.
# on the far host (VPN endpoint)
iperf3 -s
# wired client, direct to the endpoint's public address
iperf3 -c 203.0.113.10 -t 30
# same client, four parallel streams
iperf3 -c 203.0.113.10 -t 30 -P 4
Két szám válaszol ebből a blokkból különböző kérdésekre. Egy stream a kapcsolatonkénti plafont mutatja, amely magában foglalja a TCP-ablak viselkedését és az útvonalon alkalmazott folyamonkénti formálást. Négy stream mutatja, hogy a kapcsolatnak van-e kihasználatlan kapacitása, mert a párhuzamos folyamok meg tudnak tölteni egy csövet, amelyet egy folyam nem.
Tartsa tisztességesen: ugyanaz a hoszt, napszak és időtartam, és semmi más nem streamel a házban. A harminc másodperces tömeges átvitel a helyes egység itt, és az RFC 6349, a TCP átbocsátóképesség tesztelésének keretrendszere, pontosan ezen az érvelésen alapul, mert a rövid löketek és a kis kérések hízelegnek a kapcsolatnak. Írja fel az alapvonalat, mielőtt bármit megváltoztat.
Lépés 3: Futtassa ugyanezt a tesztet az alagúton keresztül
Most ismételje meg a végpont alagútcímével szemben, ugyanazzal az ügyféllel, időtartammal és streamszámmal, az alagút fent, és más forgalom nélkül. A két eredmény aránya megmondja, mennyibe kerül a titkosítás és a beágyazás ezen a hardveren; az abszolút szám megmondja, hogy elegendő-e a feladathoz.
Figyelje a számlálókat, miközben az átvitel fut. WireGuardon a wg show a partnereként átvitt bájtokat jelenti; az OpenVPN-en egy rendszeres időközönként írt állapotfájl ugyanezt a képet adja.
watch -n 1 'wg show wg0 transfer'
# OpenVPN: add --status /run/openvpn/server.status 10 to the server config
tail -f /run/openvpn/server.status
Ha az alagút száma közel van a vezetékes alapvonalhoz, a VPN nem a szűk keresztmetszet, és abbahagyhatja a hibáztatását. Ha csak töredéke az alapvonalnak, a veszteség a router titkosítási és továbbítási útvonalán belül történt, és a következő lépés megmondja, melyik részén.
Egy figyelmeztetés: amint a kimenő IP megváltozik, egyes sebességteszt-szolgáltatások csendben másik mérőszervert választanak, így végül két különböző célt hasonlít össze. Rögzítse maga a szerver címét.
Lépés 4: A processzort útvonalként olvassa, ne átlagként
Egy router, amely 30 százalék teljes processzorterhelést mutat, még mindig telített lehet: egy alagút munkája általában egy magra, egy megszakítási sorra vagy egy kernelszálra kerül, így az átlag elrejti a plafont. Nézze a magonkénti és softirq-számokat a műszerfal mutatója helyett.
mpstat -P ALL 1
top -H -p $(pgrep -f 'openvpn')
grep -o -m1 aes /proc/cpuinfoHárom dolog számít ebben a kimenetben. Egyetlen mag, amely 100 százalék közelében rögzült, miközben a többi tétlen, kapcsolatonkénti korlátra utal. A nagy %soft vagy egy foglalt ksoftirqd egy processzoron olyan fogadási oldali csomagfeldolgozásra utal, amely nem oszlik el a sorok között. A hiányzó aes jelző pedig azt jelenti, hogy a processzornak nincsenek AES utasításai, így a szimmetrikus titkosítás szoftverben fut, és csomagonként sokkal többe kerül.
A megvalósítás is számít. A hagyományos felhasználói térben futó OpenVPN-példány egy alagút csomagjait nagyrészt egy helyen dolgozza fel, így egy gyors többmagos doboz azon alagút számára egymagosként viselkedhet. A kernelben futó WireGuard a processzorok között osztja el a munkát, és az OpenVPN adatcsatorna-kiterhelése is a kernelbe helyezi a csomagkezelést, de csak az ezt támogató buildeken és platformokon. A marketingoldalon szereplő hardveres gyorsítási állítás nem bizonyíték arra, hogy a futtatott kódútvonal használja.
Lépés 5: Döntse el, mit változtat, ebben a sorrendben
Menjen végig a listán, és álljon meg az első igaz sornál, mert az alatta lévő bárminek a megváltoztatása nem mozdítja a számot.
1. A vezetékes közvetlen átbocsátóképesség alacsonyabb annál, amit fizet: beszéljen a szolgáltatóval, mert az alagút nem tud olyan kapacitást teremteni, amelyet a hozzáférési kör nem ad. 2. A vezetékes közvetlen rendben van, de a teszt alatt egy mag rögzül: a router kripto útvonala a határ. 3. A processzor tétlen, de az alagút lassú: ellenőrizze az MTU-t és a töredezettséget, majd a távoli végpont saját kapacitását. 4. Csak a Wi-Fi ügyfelek lassúak: váltson sávot vagy csatornaszélességet, és fogadja el, hogy a hirdetett sebesség soha nem volt VPN-szám.
Amikor a router valóban a határ, a tisztességes lehetőségek: AES utasításokkal és gyorsabb továbbítási útvonallal rendelkező eszköz, kernelszoldali alagút, például WireGuard a felhasználói téri helyett, vagy az ügyfél átvitele magára az eszközre, hogy a router abbahagyja a titkosítást. A hitelesített titkosítás kikapcsolása egy benchmark megnyeréséért nem tartozik közéjük; biztonsági tulajdonságot cserél olyan számra, amely így sem fog a dobozhoz illeszkedni.
Mielőtt bármit vásárolna, futtassa újra a 2 és 3 lépést az új eszközön ugyanazzal a szerverrel és időtartammal, majd arányokat hasonlítson össze, ne csúcsokat.