Hvorfor din routers Wi-Fi-bedømmelse ikke forudsiger VPN-gennemstrømning

En router med et Wi-Fi-mærke på 3,000 Mbps kan stadig flytte krypteret trafik med en brøkdel af det tal, og ingen af de to tal er uærlige. Radio-bedømmelsen beskriver en bedste-tilfælde-modulering af det trådløse link, som chipsettet understøtter; VPN-tallet beskriver, hvor hurtigt én enhed kan presse krypterede pakker gennem routerens CPU og ud af din adgangslinje. Det er forskellige lag, forskellige pakkestørrelser og forskellige målemetoder. Behandl tallet på æsken som et loft, ingen når, ikke som en prognose for din tunnelhastighed.

Trin 1: Kortlæg de fire lag, der begrænser tallet

Næsten enhver klage over en langsom router, jeg har arbejdet med, lander i et af fire niveauer: det trådløse link, WAN-adgangshastigheden, videresendelsesvejen (NAT, firewall, forbindelsessporing) eller VPN-kryptovejen. De stabler, og det langsomste niveau bestemmer resultatet. En annonceret Wi-Fi-hastighed taler kun om det første niveau, og det taler generøst om det.

Det tal kommer fra strømme gange kanalbredde gange den højeste modulering, chipsettet kan forhandle. En 2x2-radio på 5 GHz ved 80 MHz med 1024-QAM annonceres nær 1,200 Mbps, men Wi-Fi er et delt, halvdupleksmedium: klienter skiftes, genforsøg og styretrafik brænder sendetid, og TCP lægger sin egen overhead oveni. En klient, der forhandler top-hastigheden under ideelle forhold, måler normalt langt under halvdelen, og mindre når nabonetværk dukker op.

Hvis tabellen peger på radioen, så ret den trådløse side først: bånd, kanalbredde, afstand. Hvis den peger under radioen, er de næste fire trin vigtige, og ingen mængde antenneindkøb vil ændre det.

Trin 2: Tag en kablet baseline, før du rører radioen

Sæt bærbaren på Ethernet og mål først vejen uden tunnelen, for det giver dig en nævner. Kør gennemstrømningsværktøjet på den anden side, på VPS'en eller hjemmeserveren, der terminerer VPN'en, og peg klienten mod dens offentlige adresse, så trafikken går gennem din router og adgangslinje.

# 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

To tal fra den blok besvarer forskellige spørgsmål. Én strøm viser loftet pr. forbindelse, som omfatter TCP-vinduets adfærd og enhver pr.-flow-formning på vejen. Fire strømme viser, om linket har kapacitet, du ikke udnytter, fordi parallelle flows kan fylde et rør, som et enkelt flow ikke kan.

Hold det ærligt: samme vært, tid på dagen og varighed, uden at noget andet streamer i huset. En overførsel på tredive sekunder er den rigtige enhed her, og RFC 6349, rammen for test af TCP-gennemstrømning, er bygget på netop den tankegang, fordi korte bursts og små anmodninger smigrer et link. Skriv baseline ned, før du ændrer noget.

Trin 3: Kør den samme test gennem tunnelen

Gentag det nu mod slutpunktets tunneladresse, med samme klient, varighed og antal strømme, med tunnelen oppe og ingen anden trafik. Forholdet mellem de to resultater fortæller, hvad kryptering og indkapsling koster på den hardware; det absolutte tal fortæller, om det er nok til opgaven.

Hold øje med tællerne, mens overførslen kører. På WireGuard rapporterer wg show overførte bytes pr. peer; på OpenVPN giver en statusfil, der skrives med intervaller, dig samme visning.

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

Hvis tunnel-tallet er tæt på den kablede baseline, er VPN'en ikke din flaskehals, og du kan holde op med at give den skylden. Hvis det er en brøkdel af baselinen, skete tabet inde i routerens krypterings- og videresendelsesvej, og næste trin fortæller hvilken del.

Én advarsel: når exit-IP'et skifter, vælger nogle hastighedstesttjenester stille en anden måleserver, så du ender med at sammenligne to forskellige destinationer. Fastlås selv serveradressen.

Trin 4: Læs CPU'en som en vej, ikke som et gennemsnit

En router, der viser 30 procent samlet CPU, kan stadig være mættet: én tunnels arbejde lander typisk på én kerne, én interruptkø eller én kerneltråd, så gennemsnittet skjuler loftet. Se på tal pr. kerne og softirq i stedet for måleren på dashboardsiden.

mpstat -P ALL 1
top -H -p $(pgrep -f 'openvpn')
grep -o -m1 aes /proc/cpuinfo

Tre ting betyder noget i det output. Én kerne fastlåst nær 100 procent, mens de andre står stille, peger på en grænse pr. forbindelse. Tung %soft eller en travl ksoftirqd på én CPU peger på pakkebehandling på modtagesiden, som ikke spredes over køerne. Og et manglende aes-flag betyder, at CPU'en ikke har AES-instruktioner, så symmetrisk kryptering kører i software og koster langt mere pr. pakke.

Implementeringen betyder også noget. En traditionel OpenVPN-instans i brugerrummet behandler én tunnels pakker for det meste ét sted, så en hurtig flerkernemaskine kan opføre sig som en enkeltkerne for den tunnel. WireGuard i kernen spreder arbejdet over CPU'er, og OpenVPN's data channel offload flytter også pakkehåndtering ind i kernen, men kun på builds og platforme, der understøtter det. En påstand om hardwareacceleration på marketingsiden er ikke bevis for, at den kodesti, du kører, bruger den.

Trin 5: Beslut, hvad der skal ændres, i den rækkefølge

Gå ned ad listen og stop ved den første linje, der er sand, for at ændre noget under den flytter ikke tallet.

1. Kablet direkte gennemstrømning er under det, du betaler for: tal med udbyderen, for tunnelen kan ikke skabe kapacitet, som adgangslinjen ikke leverer. 2. Kablet direkte er fint, men én kerne låser under tunneltesten: routerens kryptovej er grænsen. 3. CPU'en er ledig, men tunnelen er langsom: tjek MTU og fragmentering, derefter det fjerne slutpunkts egen kapacitet. 4. Kun Wi-Fi-klienter er langsomme: skift bånd eller kanalbredde, og accepter, at den annoncerede hastighed aldrig var et VPN-tal.

Når routeren virkelig er grænsen, er de ærlige muligheder en enhed med AES-instruktioner og en hurtigere videresendelsesvej, en tunnel på kernelsiden som WireGuard i stedet for en i brugerrummet, eller at flytte klienten ind på enheden selv, så routeren holder op med at kryptere. At slå autentificeret kryptering fra for at vinde en benchmark er ikke en af dem; det bytter en sikkerhedsegenskab for et tal, der stadig ikke vil matche æsken.

Før du køber noget, skal du køre trin 2 og 3 igen på den nye enhed med samme server og varighed og derefter sammenligne forhold i stedet for toppe.