Per què la qualificació Wi-Fi del router no prediu el cabal de la VPN
Una velocitat Wi-Fi anunciada i una velocitat VPN mesurada descriuen capes diferents. Seguiu aquesta comprovació ordenada abans de comprar un router més ràpid.
Un router amb una etiqueta Wi-Fi de 3,000 Mbps encara pot moure trànsit xifrat a una fracció d'aquest número, i cap de les dues xifres és deshonesta. La qualificació de ràdio descriu la millor modulació possible de l'enllaç sense fil que admet el xip; la xifra de VPN descriu amb quina rapidesa un sol dispositiu pot empènyer paquets xifrats a través de la CPU del router i fora del circuit d'accés. Són capes diferents, mides de paquet diferents i mètodes de mesura diferents. Tracteu el número de la caixa com un sostre que ningú no assoleix, no com una previsió de la velocitat del túnel.
Pas 1: Mapeu les quatre capes que limiten la xifra
Gairebé tota queixa de router lent amb què he treballat cau en un de quatre nivells: l'enllaç sense fil, la velocitat d'accés WAN, el camí de reenviament (NAT, tallafoc, seguiment de connexions) o el camí criptogràfic de la VPN. S'apilen, i el nivell més lent fixa el resultat. Una velocitat Wi-Fi anunciada només parla del primer nivell, i en parla amb generositat.
Aquesta xifra surt dels fluxos multiplicats per l'amplada de canal i per la modulació més alta que el xip pot negociar. Una ràdio 2x2 a 5 GHz amb 80 MHz i 1024-QAM s'anuncia prop de 1,200 Mbps, però el Wi-Fi és un medi compartit i semidúplex: els clients s'alternen, les retransmissions i el trànsit de gestió cremen temps d'aire, i TCP hi afegeix la seva pròpia sobrecàrrega. Un client que negocia la velocitat màxima en condicions ideals sol mesurar força menys de la meitat, i encara menys quan apareixen xarxes veïnes.
| 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 |
Si la taula apunta a la ràdio, arregleu primer la banda sense fil: banda, amplada de canal, distància. Si apunta per sota de la ràdio, els quatre passos següents són els que importen, i cap compra d'antenes no ho canviarà.
Pas 2: Preneu una línia base per cable abans de tocar la ràdio
Poseu l'ordinador portàtil a Ethernet i mesureu primer el camí sense el túnel, perquè això us dona un denominador. Executeu l'eina de cabal a l'altre costat, al VPS o servidor de casa que acaba la VPN, i apunteu el client a la seva adreça pública perquè el trànsit travessi el router i el circuit d'accés.
# 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
Dues xifres d'aquest bloc responen preguntes diferents. Un sol flux mostra el sostre per connexió, que inclou el comportament de la finestra TCP i qualsevol modelatge per flux al camí. Quatre fluxos mostren si l'enllaç té capacitat que no aprofiteu, perquè els fluxos paral·lels poden omplir una canonada que un de sol no pot.
Manteniu-ho honest: mateix amfitrió, hora del dia i durada, sense res més fent streaming a casa. Una transferència massiva de trenta segons és la unitat correcta aquí, i RFC 6349, el marc per provar el cabal TCP, es basa en aquest raonament, perquè les ràfegues curtes i les peticions petites afalaguen un enllaç. Anoteu la línia base abans de canviar res.
Pas 3: Executeu la mateixa prova a través del túnel
Ara repetiu-ho contra l'adreça del túnel del punt final, amb el mateix client, durada i nombre de fluxos, amb el túnel aixecat i sense cap altre trànsit. La ràtio entre els dos resultats us diu què costen el xifratge i l'encapsulament en aquest maquinari; la xifra absoluta us diu si n'hi ha prou per a la feina.
Mireu els comptadors mentre la transferència s'executa. A WireGuard, wg show informa dels bytes transferits per parell; a OpenVPN, un fitxer d'estat escrit a intervals us dona la mateixa vista.
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
Si la xifra del túnel és a prop de la línia base per cable, la VPN no és el coll d'ampolla i podeu deixar de culpar-la. Si és una fracció de la base, la pèrdua ha passat dins del camí de xifratge i reenviament del router, i el pas següent us diu quina part.
Un advertiment: quan canvia la IP de sortida, alguns serveis de prova de velocitat trien en silenci un altre servidor de mesura, així que acabeu comparant dues destinacions. Fixeu vosaltres mateixos l'adreça del servidor.
Pas 4: Llegiu la CPU com un camí, no com una mitjana
Un router que mostra un 30 per cent de CPU total encara pot estar saturat: la feina d'un túnel sol caure en un nucli, una cua d'interrupcions o un fil del nucli, així que la mitjana amaga el sostre. Mireu les xifres per nucli i de softirq en lloc del mesurador del tauler.
mpstat -P ALL 1
top -H -p $(pgrep -f 'openvpn')
grep -o -m1 aes /proc/cpuinfoTres coses importen en aquesta sortida. Un sol nucli clavat a prop del 100 per cent mentre els altres estan inactius assenyala un límit per connexió. Un %soft alt o un ksoftirqd ocupat en una CPU assenyala processament de paquets al costat de recepció que no es reparteix entre cues. I que falti el senyalador aes vol dir que la CPU no té instruccions AES, així que el xifratge simètric va en programari i costa molt més per paquet.
La implementació també importa. Una instància tradicional d'OpenVPN en espai d'usuari processa els paquets d'un túnel en gran part en un sol lloc, així que una caixa ràpida multinucli es pot comportar com una d'un sol nucli per a aquest túnel. WireGuard al nucli reparteix la feina entre CPU, i la descàrrega del canal de dades d'OpenVPN també mou el maneig de paquets al nucli, però només en compilacions i plataformes que ho admeten. Una afirmació d'acceleració per maquinari a la pàgina de màrqueting no és prova que el camí de codi que executeu la faci servir.
Pas 5: Decidiu què canviar, en aquest ordre
Baixeu per aquesta llista i atureu-vos a la primera línia que sigui certa, perquè canviar qualsevol cosa per sota no mourà la xifra.
1. El cabal directe per cable és inferior al que pagueu: parleu amb el proveïdor, perquè el túnel no pot crear capacitat que el circuit d'accés no lliura. 2. El directe per cable va bé però un nucli es clava durant la prova del túnel: el camí criptogràfic del router és el límit. 3. La CPU està inactiva però el túnel és lent: reviseu l'MTU i la fragmentació, i després la capacitat del punt final remot. 4. Només són lents els clients Wi-Fi: canvieu de banda o d'amplada de canal, i accepteu que la velocitat anunciada mai no va ser una xifra de VPN.
Quan el router és realment el límit, les opcions honestes són un aparell amb instruccions AES i un camí de reenviament més ràpid, un túnel al nucli com WireGuard en lloc d'un a l'espai d'usuari, o traslladar el client al mateix aparell perquè el router deixi de xifrar. Apagar el xifratge autenticat per guanyar una prova de rendiment no és una d'elles; intercanvia una propietat de seguretat per una xifra que encara no coincidirà amb la caixa.
Abans de comprar res, torneu a executar els passos 2 i 3 al dispositiu nou amb el mateix servidor i durada, i després compareu ràtios en lloc de pics.