Comment tester le débit d’un VPN pour que les chiffres veuillent dire quelque chose

Un test de débit ne mesure jamais le VPN. Il mesure un chemin, et activer le tunnel remplace une partie de ce chemin avant que le premier octet ne bouge. C’est pourquoi un portable affiche un chiffre sain face à un site et médiocre face à un autre sans que rien n’ait changé d’un côté ni de l’autre. Lisez le résultat comme une preuve sur une route, pas comme une note pour un produit.

Trois choses décident si la comparaison vaut quelque chose : si les deux passes ont visé la même cible, si le réseau d’accès est resté immobile et si vous avez noté le délai à côté du volume.

Ce que le tunnel réécrit avant le premier octet

Le client enveloppe chaque paquet dans un en-tête supplémentaire, donc la charge utile par paquet diminue. Le coût est par paquet et non par transfert, ce qui veut dire qu’un gros fichier a besoin de plus de paquets que le même fichier envoyé sans tunnel. Une telle surcharge se voit en nombre de paquets, pas en réglage visible.

Deux conséquences en découlent. Un test fait de gros blocs ressent le coût par paquet, tandis qu’un test fait de nombreuses petites requêtes ressent à la place les allers-retours. Et si la découverte du MTU du chemin est bloquée quelque part, le tunnel se cale sur une taille de paquet plus petite et le débit chute pour une raison qui n’a rien à voir avec les chiffrements.

Vous pouvez observer le plafond directement. Sous Linux, demandez la plus grosse charge utile qui passe sans fragmentation, puis répétez avec le tunnel activé :

ping -M do -s 1472 -c 3 203.0.113.10

Si cela échoue, descendez à 1,400 et réessayez. Un tunnel qui ne transporte que 1,380 octets vous dit que quelque chose serre plus bas sur le chemin, et aucun réglage côté client ne le relèvera.

Pourquoi le serveur de test se déplace quand le tunnel monte

La plupart des outils choisissent un serveur proche d’après l’adresse publique qu’ils voient. Le tunnel activé, cette adresse appartient au nœud de sortie, donc l’outil peut choisir un hôte dans une autre ville ou un autre pays. Vous comparez alors deux destinations, et l’écart entre elles inclut la distance de la sortie jusqu’à l’hôte de test.

Épinglez le serveur par nom ou ID avant la première passe et gardez-le à chaque passe suivante. Si l’outil ne le retient pas, choisissez une cible que vous contrôlez et pilotez-la vous-même : iperf3 -c test.example.net -R -t 20 garde la destination fixe et vous donne un nombre que vous pouvez comparer à celui d’hier.

Changez une variable, et la couche sous-jacente n’en est pas une

Le sans-fil est le changement caché habituel. La puissance du signal bouge quand le portable bouge et l’occupation du canal bouge quand un voisin commence un appel, donc deux passes à dix minutes d’intervalle en Wi-Fi ne sont pas des répétitions du même test. Le câble, ou une position fixe avec le niveau de signal noté, élimine l’essentiel de ce bruit. Une note du niveau de signal au début et à la fin de chaque passe suffit généralement à montrer si deux passes vont ensemble.

La charge de l’appareil relève du même panier. Un client qui chiffre sur un seul cœur atteint son propre plafond bien avant le lien, et une synchronisation en arrière-plan l’atteint plus tôt. Surveillez le CPU pendant la passe et notez ce qui d’autre était ouvert. Les réglages d’énergie peuvent mordre ici aussi, car un portable sur batterie peut brider le processeur bien avant que le lien ne soit près d’être saturé.

Gardez la couche sous-jacente immobile au lieu d’en faire une moyenne. Trois passes qui concordent disent plus que dix prises dans des pièces différentes.

Délai, perte et ICMP répondent à des questions différentes

Ping envoie une petite sonde vers une adresse fixe, et beaucoup de réseaux répondent à l’ICMP avec une priorité basse ou l’ignorent complètement. Les réponses manquantes décrivent la sonde, pas les paquets de l’application. Un temps d’aller-retour qui grimpe sous charge signifie généralement qu’une file se remplit, non que la route s’est allongée.

Pour savoir si le tunnel ajoute du délai, comparez une cible avec et sans lui, ou comparez deux sorties joignables depuis le même réseau d’accès. Lancez la sonde plusieurs fois et regardez la dispersion, car une moyenne cache précisément la variation qui rend un appel inutilisable.

Revenez à la tâche qui semblait lente

Une mesure qui s’améliore alors que l’appel saccade encore a répondu à autre chose. Relancez la tâche qui a déclenché l’enquête, qu’il s’agisse d’une réunion, d’un partage de fichiers ou d’une session de bureau à distance. Si le chiffre s’est amélioré et pas la tâche, le goulot se trouvait là où le test n’est jamais arrivé, comme le serveur derrière le tunnel ou votre liaison montante.

Journalisez chaque passe avec l’appareil, le réseau d’accès, le point de sortie, le protocole, la cible et l’heure. Une passe qui ne s’est jamais connectée est un résultat d’accessibilité et non un débit nul, donc classez-la sous cette étiquette au lieu de la supprimer.

Une courte liste avant la prochaine comparaison

Figez la cible et notez pourquoi vous l’avez choisie. Relevez la taille de paquet que le chemin autorise, pour qu’une baisse ultérieure ait une explication. Gardez le réseau d’accès identique, notez la charge CPU et faites trois passes avant de croire à une différence.

Changez ensuite exactement une chose et répétez. La comparaison que vous savez expliquer vaut mieux que celle avec le plus grand nombre.