Pourquoi la note Wi-Fi de votre routeur ne prédit pas le débit du VPN

Un routeur arborant un badge Wi-Fi de 3,000 Mbps peut toujours déplacer du trafic chiffré à une fraction de ce chiffre, et aucun des deux chiffres n’est malhonnête. La note radio décrit la meilleure modulation possible de la liaison sans fil que le chipset prend en charge ; le chiffre VPN décrit la vitesse à laquelle un seul appareil peut pousser des paquets chiffrés à travers le processeur du routeur et hors de votre circuit d’accès. Ce sont des couches différentes, des tailles de paquets différentes et des méthodes de mesure différentes. Traitez le nombre sur la boîte comme un plafond que personne n’atteint, pas comme une prévision du débit de votre tunnel.

Étape 1 : Cartographiez les quatre couches qui plafonnent le nombre

Presque toutes les plaintes de routeur lent sur lesquelles j’ai travaillé tombent dans l’un des quatre niveaux : la liaison sans fil, le débit d’accès WAN, le chemin de transfert (NAT, pare-feu, suivi des connexions) ou le chemin cryptographique du VPN. Ils s’empilent, et le niveau le plus lent fixe le résultat. Un débit Wi-Fi annoncé ne parle que du premier niveau, et il en parle généreusement.

Ce nombre vient des flux multipliés par la largeur de canal et par la modulation la plus élevée que le chipset peut négocier. Une radio 2x2 à 5 GHz sur 80 MHz avec 1024-QAM est annoncée près de 1,200 Mbps, mais le Wi-Fi est un support partagé et semi-duplex : les clients alternent, les retransmissions et le trafic de gestion brûlent du temps d’antenne, et TCP ajoute sa propre surcharge. Un client qui négocie le débit maximal dans des conditions idéales mesure généralement bien moins de la moitié, et encore moins dès que des réseaux voisins apparaissent.

Si le tableau pointe vers la radio, corrigez d’abord le côté sans fil : bande, largeur de canal, distance. S’il pointe sous la radio, les quatre étapes suivantes comptent, et aucun achat d’antenne n’y changera rien.

Étape 2 : Prenez une base filaire avant de toucher à la radio

Mettez le portable sur Ethernet et mesurez d’abord le chemin sans le tunnel, car cela vous donne un dénominateur. Lancez l’outil de débit de l’autre côté, sur le VPS ou le serveur domestique qui termine le VPN, et pointez le client vers son adresse publique pour que le trafic traverse votre routeur et votre 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

Deux nombres de ce bloc répondent à des questions différentes. Un seul flux montre le plafond par connexion, qui inclut le comportement de la fenêtre TCP et toute mise en forme par flux sur le chemin. Quatre flux montrent si la liaison a une capacité que vous n’exploitez pas, car des flux parallèles peuvent remplir un tuyau qu’un seul flux ne remplit pas.

Restez honnête : même hôte, heure de la journée et durée, sans rien d’autre qui diffuse à la maison. Un transfert massif de trente secondes est la bonne unité ici, et RFC 6349, le cadre de test du débit TCP, repose sur ce raisonnement, car les courtes rafales et les petites requêtes flattent une liaison. Notez la base avant de changer quoi que ce soit.

Étape 3 : Lancez le même test à travers le tunnel

Répétez-le maintenant contre l’adresse tunnel du point de terminaison, avec le même client, la même durée et le même nombre de flux, tunnel actif et sans autre trafic. Le rapport entre les deux résultats vous dit ce que coûtent le chiffrement et l’encapsulation sur ce matériel ; le chiffre absolu vous dit si cela suffit pour la tâche.

Surveillez les compteurs pendant le transfert. Sur WireGuard, wg show rapporte les octets transférés par pair ; sur OpenVPN, un fichier d’état écrit à intervalle vous donne la même vue.

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 le chiffre du tunnel est proche de la base filaire, le VPN n’est pas votre goulot d’étranglement et vous pouvez cesser de l’accuser. S’il n’est qu’une fraction de la base, la perte s’est produite dans le chemin de chiffrement et de transfert du routeur, et l’étape suivante vous dit quelle partie.

Un avertissement : dès que l’IP de sortie change, certains services de test de débit choisissent discrètement un autre serveur de mesure, si bien que vous finissez par comparer deux destinations. Épinglez vous-même l’adresse du serveur.

Étape 4 : Lisez le processeur comme un chemin, pas comme une moyenne

Un routeur affichant 30 pour cent de processeur total peut encore être saturé : le travail d’un tunnel atterrit généralement sur un cœur, une file d’interruptions ou un thread du noyau, si bien que la moyenne cache le plafond. Regardez les chiffres par cœur et les softirq plutôt que la jauge du tableau de bord.

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

Trois choses comptent dans cette sortie. Un seul cœur épinglé près de 100 pour cent pendant que les autres tournent à vide indique une limite par connexion. Un %soft élevé ou un ksoftirqd occupé sur un processeur indique un traitement de paquets côté réception qui ne se répartit pas entre les files. Et un indicateur aes absent signifie que le processeur n’a pas d’instructions AES, donc le chiffrement symétrique tourne en logiciel et coûte bien plus par paquet.

L’implémentation compte aussi. Une instance OpenVPN traditionnelle en espace utilisateur traite les paquets d’un tunnel en grande partie au même endroit, si bien qu’une machine multicoeur rapide peut se comporter comme une monocœur pour ce tunnel. WireGuard dans le noyau répartit le travail entre les processeurs, et le déchargement du canal de données d’OpenVPN déplace aussi le traitement des paquets dans le noyau, mais seulement sur les versions et plateformes qui le prennent en charge. Une affirmation d’accélération matérielle sur la page marketing ne prouve pas que le chemin de code que vous exécutez l’utilise.

Étape 5 : Décidez quoi changer, dans cet ordre

Descendez cette liste et arrêtez-vous à la première ligne qui est vraie, car changer quoi que ce soit en dessous ne fera pas bouger le chiffre.

1. Le débit direct en filaire est inférieur à ce que vous payez : parlez au fournisseur, car le tunnel ne peut pas créer une capacité que le circuit d’accès ne fournit pas. 2. Le filaire direct est correct mais un cœur s’épingle pendant le test du tunnel : le chemin cryptographique du routeur est la limite. 3. Le processeur est au repos mais le tunnel est lent : vérifiez la MTU et la fragmentation, puis la capacité du point de terminaison distant lui-même. 4. Seuls les clients Wi-Fi sont lents : changez de bande ou de largeur de canal, et acceptez que le débit annoncé n’ait jamais été un chiffre VPN.

Quand le routeur est vraiment la limite, les options honnêtes sont un appareil avec instructions AES et un chemin de transfert plus rapide, un tunnel côté noyau comme WireGuard au lieu d’un tunnel en espace utilisateur, ou déplacer le client sur l’appareil lui-même pour que le routeur cesse de chiffrer. Désactiver le chiffrement authentifié pour gagner un benchmark n’en fait pas partie ; cela échange une propriété de sécurité contre un chiffre qui ne correspondra toujours pas à la boîte.

Avant d’acheter quoi que ce soit, relancez les étapes 2 et 3 sur le nouvel appareil avec le même serveur et la même durée, puis comparez des rapports plutôt que des pics.