Wêrom't de Wi-Fi-skoaring fan dyn router de faasje fan in VPN net foarsizget
In oankundige Wi-Fi-snelheid en in metten VPN-snelheid beskriuwe ferskate lagen. Wurkje dizze oardere kontrôle troch foardatsto in flugger router keapst.
In router mei in Wi-Fi-badge fan 3,000 Mbps kin fersifere ferkear noch altyd mei in fraksje fan dat getal ferplakke, en gjin fan beide getallen is ûnearlik. De radioskoaring beskriuwt de bêst mooglike modulaasje fan 'e triedleaze ferbining dy't de chipset stipet; it VPN-getal beskriuwt hoe fluch ien apparaat fersifere pakketten troch de prosessor fan 'e router en út dyn tagongsliny skowe kin. Dat binne ferskate lagen, ferskate pakketgrutten en ferskate mjitmetoaden. Behannel it getal op 'e doaze as in plafond dat nimmen berikt, net as in foarsizzing fan 'e faasje fan dyn tunnel.
Stap 1: Yn kaart bringe fan 'e fjouwer lagen dy't it getal beheine
Hast elke klacht oer in stadige router dêr't ik mei wurke haw, falt yn ien fan fjouwer nivo's: de triedleaze ferbining, de WAN-tagongsfaasje, it trochstjoerpaad (NAT, firewall, ferbiningstracking) of it VPN-kryptopaad. Se steapelje, en it stadichste nivo bepaalt it resultaat. In oankundige Wi-Fi-snelheid praat allinnich oer it earste nivo, en it praat der royaal oer.
Dat getal komt fan streamen kear kanaalbreedte kear de heechste modulaasje dy't de chipset úthannelje kin. In 2x2-radio op 5 GHz by 80 MHz mei 1024-QAM wurdt tichtby 1,200 Mbps oankundige, mar Wi-Fi is in dield, healdupleks medium: klanten wikselje, werhellings en behearderferkear ferbaarne lofttiid, en TCP foeget syn eigen oerheid ta. In klant dy't de topsnelheid ûnder ideale omstannichheden úthannelet, mjit meastentiids rom ûnder de helte dêrfan, en minder sadree't buornetwurken ferskine.
| 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 |
As de tabel nei de radio wiist, meitsje dan earst de triedleaze kant goed: bân, kanaalbreedte, ôfstân. As it ûnder de radio wiist, jouwe de folgjende fjouwer stappen, en gjin hoemannichte antennes keapje sil dat feroarje.
Stap 2: Nim in bekabelde basisline foardatsto de radio oanrekest
Set de laptop op Ethernet en mjit earst it paad sûnder de tunnel, want dat jout dy in neamer. Rin it trochfier-ark oan 'e oare kant, op 'e VPS of thússerver dy't de VPN beëiniget, en rjochtsje de klant op syn iepenbiere adres sadat ferkear troch dyn router en tagongsliny giet.
# 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
Twa getallen út dat blok beantwurdzje ferskate fragen. Ien stream lit it plafond per ferbining sjen, dat it hâlden en dragen fan it TCP-finster en elke foarmjouwing per stream op it paad omfettet. Fjouwer streamen litte sjen oft de ferbining kapasiteit hat dy'tst net brûkst, want parallelle streamen kinne in buis folje dy't ien stream net folje kin.
Hâld it earlik: deselde host, tiid fan 'e dei en doer, sûnder dat der wat oars yn 'e hûs streamt. In oerdracht fan tritich sekonden is hjir de juste ienheid, en RFC 6349, it ramt foar it testen fan TCP-trochfier, is op krekt dy redenearring boud, want koarte útbarstings en lytse oanfragen flaaie in ferbining. Skriuw de basisline op foardatsto wat feroarest.
Stap 3: Rin deselde test troch de tunnel
Werhelje it no tsjin it tunneladres fan it einpunt, mei deselde klant, doer en oantal streamen, mei de tunnel omheech en gjin oar ferkear. De ferhâlding tusken beide resultaten fertelt dy wat fersifering en ynkapseling op dy hardware kostet; it absolute getal fertelt dy oft it genôch is foar it wurk.
Hâld de tellers yn 'e gaten wylst de oerdracht rint. Op WireGuard rapportearret wg show oerdroegen bytes per partner; op OpenVPN jout in statusbestân dat op in ynterval skreaun wurdt dy itselde byld.
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
As it tunnelgetal tichtby de bekabelde basisline leit, is de VPN net dyn knelpunt en kinst ophâlde it de skuld te jaan. As it in fraksje fan 'e basisline is, barde it ferlies binnen it fersiferings- en trochstjoerpaad fan 'e router, en de folgjende stap fertelt dy hokker part.
Ien warskôging: sadree't it útgongs-IP feroaret, kieze guon faasjetestsjinsten stil in oare mjitserver, datst einigest mei twa ferskate bestimmingen te fergelykjen. Pin it serveradres sels fêst.
Stap 4: Lês de prosessor as in paad, net as in gemiddelde
In router dy't 30 persint totale prosessorbelesting sjen lit, kin noch hieltyd fersêde wêze: it wurk fan ien tunnel lânet meast op ien kearn, ien ûnderbrekkingwachtrige of ien kernthread, dat it gemiddelde ferberget it plafond. Sjoch nei getallen per kearn en softirq ynstee fan 'e meter op it dashboard.
mpstat -P ALL 1
top -H -p $(pgrep -f 'openvpn')
grep -o -m1 aes /proc/cpuinfoTrije dingen binne fan belang yn dy útfier. Ien kearn dy't tichtby 100 persint fêstset is wylst de oaren ledich steane, wiist op in limyt per ferbining. Swiere %soft of in drokke ksoftirqd op ien prosessor wiist op pakketferwurking oan 'e ûntfangstkant dy't him net oer de wachtrigen ferspriedt. En in ûntbrekkende aes-flagge betsjut dat de prosessor gjin AES-ynstruksjes hat, dat symmetryske fersifering yn software rint en folle mear per pakket kostet.
De ymplemintaasje is ek fan belang. In tradisjonele OpenVPN-eksimplaar yn 'e brûkersromte ferwurket de pakketten fan ien tunnel foar it grutste part op ien plak, dat in flugge mearkearn-doaze kin foar dy tunnel as in ienkearn-ding hâlde en dragen. WireGuard yn 'e kearn ferspriedt it wurk oer prosessors, en de data-kanaal-offload fan OpenVPN ferpleatst pakketferwurking ek nei de kearn, mar allinnich yn builds en op platfoarmen dy't dat stypje. In bewearing fan hardwarefersnelling op 'e marketing-side is gjin bewiis dat it kodepaad datst rinst dat brûkt.
Stap 5: Beslis watsto feroarje silst, yn dy folchoarder
Wurkje dizze list del en stop by de earste rigel dy't wier is, want wat derûnder feroarje sil it getal net ferplakke.
1. Bekabelde direkte trochfier is leger as watst betelst: praat mei de provider, want de tunnel kin gjin kapasiteit meitsje dy't de tagongsliny net leveret. 2. Bekabeld direkt is goed, mar ien kearn pinnt fêst by de tunneltest: it kryptopaad fan 'e router is de limyt. 3. De prosessor is ledich, mar de tunnel is stadich: kontrolearje MTU en fragmintaasje, en dan de eigen kapasiteit fan it fiere einpunt. 4. Allinnich Wi-Fi-klanten binne stadich: feroarje bân of kanaalbreedte, en akseptearje dat de oankundige faasje nea in VPN-getal wie.
As de router wier de limyt is, binne de earlike opsjes in apparaat mei AES-ynstruksjes en in flugger trochstjoerpaad, in tunnel oan 'e kearnkant lykas WireGuard ynstee fan ien yn 'e brûkersromte, of de klant nei it apparaat sels te ferpleatsen sadat de router ophâldt mei fersiferjen. Ferifiearre fersifering útsette om in benchmark te winnen is net ien fan har; it ruilet in feiligenssigenskip foar in getal dat noch hieltyd net by de doaze passe sil.
Foardatsto wat keapst, rin stap 2 en 3 opnij op it nije apparaat mei deselde server en doer, en fergelykje dan ferhâldingen ynstee fan toppen.