Waarom de Wi-Fi-score van je router de VPN-doorvoer niet voorspelt

Een router met een Wi-Fi-badge van 3,000 Mbps kan versleuteld verkeer nog steeds met een fractie van dat getal verplaatsen, en geen van beide getallen is oneerlijk. De radiobeoordeling beschrijft de best mogelijke modulatie van de draadloze verbinding die de chipset ondersteunt; het VPN-getal beschrijft hoe snel één apparaat versleutelde pakketten door de cpu van de router en uit je toegangslijn kan duwen. Dat zijn verschillende lagen, verschillende pakketgroottes en verschillende meetmethoden. Behandel het getal op de doos als een plafond dat niemand haalt, niet als een voorspelling van je tunnelsnelheid.

Stap 1: Breng de vier lagen in kaart die het getal begrenzen

Bijna elke klacht over een trage router die ik heb behandeld, valt in een van vier niveaus: de draadloze verbinding, de WAN-toegangssnelheid, het doorstuurpad (NAT, firewall, verbindingstracking) of het VPN-cryptopad. Ze stapelen, en het traagste niveau bepaalt het resultaat. Een geadverteerde Wi-Fi-snelheid gaat alleen over het eerste niveau, en ze gaat er royaal over.

Dat getal komt van streams maal kanaalbreedte maal de hoogste modulatie die de chipset kan onderhandelen. Een 2x2-radio op 5 GHz bij 80 MHz met 1024-QAM wordt bijna 1,200 Mbps geadverteerd, maar Wi-Fi is een gedeeld half-duplexmedium: clients wisselen elkaar af, hertransmissies en beheerverkeer verbranden zendtijd, en TCP voegt zijn eigen overhead toe. Een client die onder ideale omstandigheden de topsnelheid onderhandelt, meet meestal ruim onder de helft daarvan, en minder zodra buurnetwerken opduiken.

Als de tabel naar de radio wijst, repareer dan eerst de draadloze kant: band, kanaalbreedte, afstand. Als ze onder de radio wijst, tellen de volgende vier stappen, en geen enkele antenneaankoop zal dat veranderen.

Stap 2: Neem een bekabelde basislijn voordat je de radio aanraakt

Zet de laptop op Ethernet en meet eerst het pad zonder de tunnel, want dat geeft je een noemer. Draai de doorvoertool aan de andere kant, op de VPS of thuisserver die de VPN beëindigt, en richt de client op het publieke adres zodat het verkeer via je router en toegangslijn loopt.

# 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

Twee getallen uit dat blok beantwoorden verschillende vragen. Eén stream toont het plafond per verbinding, inclusief het gedrag van het TCP-venster en elke vormgeving per flow op het pad. Vier streams tonen of de verbinding capaciteit heeft die je niet gebruikt, omdat parallelle flows een pijp kunnen vullen die één flow niet vult.

Houd het eerlijk: dezelfde host, tijd van de dag en duur, en niets anders streamt in huis. Een overdracht van dertig seconden is hier de juiste eenheid, en RFC 6349, het kader voor het testen van TCP-doorvoer, is precies op die redenering gebouwd, omdat korte bursts en kleine verzoeken een verbinding vleien. Schrijf de basislijn op voordat je iets verandert.

Stap 3: Draai dezelfde test door de tunnel

Herhaal het nu tegen het tunneladres van het eindpunt, met dezelfde client, duur en aantal streams, met de tunnel omhoog en zonder ander verkeer. De verhouding tussen de twee resultaten vertelt wat versleuteling en inkapseling op die hardware kosten; het absolute getal vertelt of het genoeg is voor het werk.

Let op de tellers terwijl de overdracht loopt. Op WireGuard meldt wg show overgedragen bytes per peer; op OpenVPN geeft een statusbestand dat met tussenpozen wordt geschreven je hetzelfde beeld.

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

Als het tunnelgetal dicht bij de bekabelde basislijn ligt, is de VPN niet je flessenhals en kun je ophouden hem de schuld te geven. Is het een fractie van de basislijn, dan trad het verlies op binnen het crypto- en doorstuurpad van de router, en de volgende stap vertelt welk deel.

Eén waarschuwing: zodra het uitgaande IP verandert, kiezen sommige snelheidstestdiensten stilletjes een andere meetserver, zodat je uiteindelijk twee verschillende bestemmingen vergelijkt. Zet het serveradres zelf vast.

Stap 4: Lees de cpu als een pad, niet als een gemiddelde

Een router die 30 procent totale cpu toont, kan nog steeds verzadigd zijn: het werk van één tunnel landt meestal op één kern, één interruptwachtrij of één kernelthread, dus het gemiddelde verbergt het plafond. Kijk naar cijfers per kern en softirq in plaats van de meter op het dashboard.

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

Drie dingen doen ertoe in die uitvoer. Eén kern die bijna 100 procent vastzit terwijl de andere niets doen, wijst op een limiet per verbinding. Zware %soft of een drukke ksoftirqd op één cpu wijst op pakketverwerking aan de ontvangstkant die niet over de wachtrijen wordt verdeeld. En een ontbrekende aes-vlag betekent dat de cpu geen AES-instructies heeft, dus symmetrische versleuteling draait in software en kost veel meer per pakket.

De implementatie doet er ook toe. Een traditionele OpenVPN-instantie in de gebruikersruimte verwerkt de pakketten van één tunnel grotendeels op één plek, dus een snelle multicorebox kan zich voor die tunnel als singlecore gedragen. WireGuard in de kernel verdeelt het werk over cpu's, en de datakanaal-offload van OpenVPN verplaatst de pakketafhandeling ook naar de kernel, maar alleen op builds en platforms die dat ondersteunen. Een claim over hardwareversnelling op de marketingpagina is geen bewijs dat het codepad dat je draait die gebruikt.

Stap 5: Bepaal wat je verandert, in die volgorde

Werk deze lijst af en stop bij de eerste regel die waar is, want iets eronder veranderen verplaatst het getal niet.

1. Bekabelde directe doorvoer is lager dan wat je betaalt: praat met de provider, want de tunnel kan geen capaciteit maken die de toegangslijn niet levert. 2. Bekabeld direct is prima, maar één kern pint vast tijdens de tunneltest: het cryptopad van de router is de grens. 3. De cpu is inactief, maar de tunnel is traag: controleer MTU en fragmentatie, en dan de eigen capaciteit van het verre eindpunt. 4. Alleen Wi-Fi-clients zijn traag: verander band of kanaalbreedte, en accepteer dat de geadverteerde snelheid nooit een VPN-getal was.

Als de router echt de grens is, zijn de eerlijke opties een apparaat met AES-instructies en een sneller doorstuurpad, een tunnel aan de kernelkant zoals WireGuard in plaats van een in de gebruikersruimte, of de client naar het apparaat zelf verplaatsen zodat de router stopt met versleutelen. Geauthenticeerde versleuteling uitschakelen om een benchmark te winnen is er daar geen van; het ruilt een beveiligingseigenschap voor een getal dat nog steeds niet bij de doos past.

Voordat je iets koopt, draai stap 2 en 3 opnieuw op het nieuwe apparaat met dezelfde server en duur, en vergelijk dan verhoudingen in plaats van pieken.