L’envoi via VPN plus lent que la réception ? Déterminez la limite atteinte

La plupart des lignes d’accès sont asymétriques, donc un tunnel envoie généralement plus lentement qu’il ne reçoit, et c’est la réponse attendue, pas une panne. La question intéressante est de savoir si votre envoi est limité par la ligne, par autre chose qui l’utilise déjà, ou par un flux qui se bloque au lieu de progresser régulièrement. Ces trois produisent la même plainte et demandent un travail différent.

Trois limites qui semblent identiques depuis la barre de progression

La capacité est la première, et c’est une propriété du produit d’accès, pas du tunnel. Un canal montant de quelques mégabits est normal sur la fibre grand public et sur de nombreux forfaits mobiles, et le coût du chiffrement est faible devant cet écart. L’encapsulation ajoute aussi des octets par paquet, ce qui réduit le débit utile dans les deux sens et pas seulement dans un, elle ne peut donc pas expliquer à elle seule une forte asymétrie.

La contention est la deuxième. La synchronisation cloud, les photothèques et les agents de mise à jour envoient pendant que la machine semble inactive, et un second appareil sur la même ligne fait de même. La file d’attente est la troisième : un canal montant saturé pousse le trafic interactif derrière les données massives, si bien que les appels se coupent pendant que le transfert lui-même annonce une progression saine.

Mesurez un sens à la fois

Utilisez le même appareil, le même profil et la même destination, et ne lancez jamais les deux sens en même temps, sauf si c’est précisément la contention que vous voulez observer. Mettez vos propres transferts facultatifs en pause avant le premier essai. Deux essais avec un indicateur entre eux règlent l’essentiel.

iperf3 envoie depuis le client par défaut, l’essai simple mesure donc votre chemin montant ; -R inverse le sens et mesure la réception. Lancez-les à quelques minutes d’intervalle et notez les deux chiffres au lieu d’en faire la moyenne :

iperf3 -c speed.example.net -t 30 -P 4
iperf3 -c speed.example.net -t 30 -P 4 -R

Si le chiffre d’envoi est une petite fraction de celui de réception et reste stable d’un essai à l’autre, la forme correspond à une ligne d’accès asymétrique et le tunnel n’est pas l’histoire. Si l’envoi varie d’un essai à l’autre ou s’effondre au bout de dix secondes, continuez la lecture.

Décidez selon l’endroit où l’envoi change

Changez une variable à la fois et regardez quel sens bouge. Un second point de terminaison VPN qui envoie mieux désigne ce point ou la route qui y mène. Le même envoi lent depuis un second appareil sur la même ligne désigne la ligne. Un autre appareil sur une autre ligne, lui aussi lent, désigne la politique d’entrée de la destination, que vous ne pouvez pas corriger localement.

Notez les octets par seconde et le temps écoulé pour la même charge, pas une seule note de vitesse. Un client de sauvegarde et un test de vitesse utilisent des destinations et une concurrence différentes, donc comparer leurs chiffres ne répond à rien. Si les petites requêtes vont bien et que seuls les gros transferts traînent, la limite n’est probablement pas du tout la bande passante.

Pour un usage quotidien, plafonner un envoi en arrière-plan ou le programmer hors des heures de réunion aide souvent plus que n’importe quel réglage du tunnel. Jugez ce changement à la charge combinée : une sauvegarde qui finit plus tard mais ne gâche plus les appels est généralement le meilleur compromis.

Quand le blocage l’emporte sur la lenteur

Un transfert qui se fige à un point reproductible puis reprend se comporte comme un problème de MTU du chemin, pas comme une limite de débit. Le tunnel réduit la charge utile par paquet, et un appareil qui ignore le message ICMP résultant laisse l’expéditeur deviner. Ce schéma mérite son propre test, car la réparation diffère du réglage d’un débit. Un chiffre bas et stable désigne la capacité, tandis qu’une rafale suivie de silence désigne une charge que le chemin ne peut pas porter.

Testez le chemin avec une charge qui ne doit pas être fragmentée, puis comparez la MTU de l’interface du tunnel avec la valeur qui passe :

ping -M do -s 1400 -c 3 203.0.113.10
ip link show dev tun0 | grep -o "mtu [0-9]*"

Si la grande sonde disparaît alors qu’une plus petite réussit, resserrez le TCP MSS sur le tunnel au lieu d’abaisser la MTU de l’interface pour chaque protocole. Les blocages persistants après ce point relèvent du stockage ou du rythme de l’application réceptrice, pas du chemin réseau.

Ce qu’il faut changer et ce qu’il faut laisser

Changez ce que vous contrôlez : les horaires des transferts en arrière-plan, le choix du point de terminaison et la MSS pour un chemin qui se bloque. Gardez chaque changement réversible et limité à une charge. Laissez tranquilles les éléments que la mesure dit corrects, y compris un débit de réception qui correspond déjà à la ligne.

Notez les chiffres avant et après avec le profil, le point de terminaison et l’heure, car un problème d’envoi qui suit le point de terminaison est une question de routage, et un problème qui suit l’appareil est local. C’est cette trace qui transforme une plainte vague en décision, et elle coûte deux exécutions de la même commande.