VPN plus lent que prévu : diagnostiquer CPU du routeur, chiffrement et clamp MSS méthodiquement

janvier 7, 2026 • février 3, 2026 • Lecture : 29 min • Views: 13

Cet article vous a aidé ?

Votre lien VPN est « up », le ping a l’air correct, et pourtant les copies de fichiers rampent comme en 2003 quand quelqu’un décroche un combiné téléphonique.
Bienvenue dans le mode d’échec VPN le plus fréquent en production : pas « down », juste gênant de lenteur par rapport à la bande passante payée.

La réparation est rarement mystique. Il s’agit généralement d’un goulot mesurable : CPU du routeur saturé par le chiffrement, un démon mono-thread,
la découverte de MTU (PMTUD) qui est en échec, ou un MSS clamping fait « presque correctement » (le pire des corrects).
Voici comment le diagnostiquer sans appliquer des réglages au hasard jusqu’à ce que « ça semble mieux ».

Mode opératoire de diagnostic rapide (10 premières minutes)

C’est la séquence qui trouve rapidement le goulot. L’objectif n’est pas de « collecter des données » pour l’archive.
L’objectif est de prendre une décision après chaque étape : CPU ? MTU ? pertes/bufferbloat ? shaping ? mono-thread ? offload désactivé ? Avancez seulement quand vous pouvez dire « ce n’est pas ça ».

1) Prouvez si le tunnel est limité par les endpoints ou par le chemin

Lancez iperf3 à travers le VPN dans les deux sens. Utilisez plusieurs flux parallèles (1 et 4).
Si 1 flux est lent mais que 4 flux sont bien plus rapides, vous avez un problème TCP/congestion/MTU/pertes, pas une limitation brute du lien.
Comparez avec un test iperf en dehors du VPN (si possible). Si la vitesse WAN est correcte mais pas celle du VPN, c’est la surcharge du tunnel ou la puissance de calcul des endpoints.

2) Vérifiez le CPU du routeur (et spécifiquement le chemin crypto)

Recherchez un cœur unique bloqué à 100 % (classique d’OpenVPN) ou un fort softirq / ksoftirqd (traitement des paquets).
Confirmez si le chiffrement matériel / l’offload est actif. Il se désactive souvent quand NAT, routing par politique ou une fonctionnalité « utile » est activée.

3) Vérifiez MTU/PMTUD/MSS avant de « tuner TCP »

Faites une recherche binaire avec ping DF (do not fragment). Trouvez le vrai path MTU à travers le tunnel.
Si les ICMP frag-needed sont bloqués quelque part, PMTUD casse et TCP s’enlise ou retransmet. Le MSS clamping peut masquer ça, mais seulement s’il est correctement configuré.

4) Mesurez pertes, réordonnancements et bufferbloat

Utilisez mtr et iperf3 en mode UDP avec précaution. Si vous observez des pertes sous charge, corrigez le queueing/shaping, pas les réglages d’encryption.

5) Ensuite seulement : traquez les spécificités de configuration (suites de chiffrement, mode du tunnel, fragmentation)

Ne commencez pas par remplacer AES-256 par ChaCha20 « parce que Reddit ». Si le CPU est au repos et le MTU correct, le choix du cipher n’est probablement pas votre goulot.

Un modèle mental pour éviter les suppositions stupides

La performance VPN est le produit de trois systèmes séparés qui tombent souvent en panne indépendamment :

Calcul : votre endpoint peut-il chiffrer/déchiffrer les paquets au débit de la ligne ? Cela inclut CPU, accélération crypto, noyau vs userspace,
et si vous avez accidentellement forcé tous les paquets sur le chemin lent.
Taille des paquets : l’encapsulation ajoute de l’overhead. Si votre MTU effectif est incorrect, vous obtenez fragmentation, pertes et comportements TCP étranges.
PMTUD est censé gérer ça, jusqu’à ce que quelqu’un bloque ICMP pour « sécurité ».
Dynamiques de transport : le débit TCP dépend du RTT, des pertes et du queueing. Les VPN augmentent souvent légèrement le RTT et peuvent amplifier le bufferbloat,
ce qui tue le débit bien avant que le lien soit saturé.

Le piège : les ingénieurs traitent le « VPN » comme un seul bouton. Ce n’est pas un bouton. C’est une chaîne. Votre travail est de trouver l’étape qui limite,
puis de réparer cette étape sans casser les autres.

Une citation à garder sur un post-it, elle s’applique ici avec insistance :
« L’espoir n’est pas une stratégie. » — Gordon R. Sullivan

Faits intéressants et brève histoire (parce que ça explique les bizarreries)

IPsec précède les préoccupations « internet moderne ». Les RFC IPsec datent du milieu des années 1990 ; il a été conçu pour sécuriser IP lui-même,
bien avant que « zero trust » devienne un slide template.
L’architecture par défaut d’OpenVPN est historiquement hostile au CPU. OpenVPN classique tourne en userspace et (souvent) pousse la plupart du trafic sur
un seul thread, d’où un cœur occupé qui bride le débit même si huit autres sont au repos.
WireGuard est volontairement compact. Sa base de code est célèbre pour être plus compacte que les piles VPN typiques, réduisant la surface d’attaque et améliorant souvent
les performances via l’intégration noyau et des choix crypto modernes.
PMTUD était censé éliminer la fragmentation. La découverte de path MTU (concept fin années 1980, implémenté plus tard) repose sur des retours ICMP.
Bloquez ICMP et vous revenez aux « arrêts mystérieux ».
Le MSS clamping est un vieux contournement qui refuse de disparaître. Il est utilisé depuis des décennies pour éviter la fragmentation quand PMTUD casse,
surtout à travers PPPoE et tunnels.
AES-NI a changé l’économie des VPN. Quand les CPU x86 ont eu l’accélération AES, « le chiffrement est lent » n’a plus été universellement vrai.
Sur les petits routeurs et SoC ARM, c’est encore souvent vrai.
GCM vs CBC n’est pas qu’académique. Les modes AEAD comme AES-GCM peuvent être plus rapides et plus sûrs dans les implémentations modernes, mais seulement si le matériel et les pilotes
les gèrent bien ; sinon vous pouvez être plus lent que prévu.
L’overhead d’encapsulation n’est pas une négociation physique. Vous payez des octets pour les en-têtes, tags d’authentification, et parfois l’encapsulation UDP.
Cela réduit l’efficacité du payload et peut vous pousser au-dessus des limites MTU.

Blague #1 : le dépannage VPN, c’est comme l’archéologie — vous brossez des couches de « correctifs temporaires » jusqu’à trouver un MTU fossile de 2014.

Symptômes importants (et ceux qui induisent en erreur)

Symptômes qui réduisent vraiment le champ des recherches

Débit plafonne à un chiffre suspect (comme 80–200 Mbps) indépendamment de la vitesse WAN : souvent CPU/crypto ou limitations mono-thread.
Une direction rapide, l’autre lente : routage asymétrique, shaping asymétrique, ou CPU bloqué sur un seul côté.
Petits transferts « ok », gros transferts lents : MTU/PMTUD ou bufferbloat sous charge soutenue.
Plusieurs flux TCP surpassent fortement un flux : pertes, réordonnancements, ou trou MTU ; le lien brut est probablement OK.
Le trafic UDP va bien ; TCP est catastrophique : signe classique de pertes/queueing/MTU plutôt que de bande passante brute.

Symptômes qui vous font perdre du temps si vous vous y attardez trop

Le ping a l’air excellent : ping utilise des paquets minuscules ; votre problème concerne généralement de gros paquets sous charge.
La moyenne CPU est basse : un cœur bloqué compte ; les moyennes mentent.
« Ça s’est aggravé après l’activation de la fonctionnalité X de sécurité » : peut-être, mais mesurez. La corrélation est une drogue professionnelle dangereuse.

CPU du routeur & limites crypto : le tueur silencieux du débit

Beaucoup de cas « VPN lent » sont simplement « votre routeur effectue des calculs coûteux à un rythme qu’il ne peut pas soutenir. »
Ces calculs peuvent être le chiffrement, l’authentification, l’encapsulation, les checksums, ou simplement déplacer des paquets entre interfaces.

Schémas de goulot CPU reconnaissables rapidement

Sur les routeurs grand public, le débit VPN est fréquemment limité par :

Chiffrement mono-thread (commun sur OpenVPN) : un cœur monte à 100 %, le débit plafonne, et vous ne pouvez pas « optimiser » votre sortie sauf en changeant d’architecture (DCO, mode noyau, protocole différent) ou de matériel.
Surcharge du traitement paquet noyau : softirq élevé, activité ksoftirqd, beaucoup de petits paquets (ACKs), NAT, conntrack et règles de pare-feu.
Accélération crypto non utilisée : vous avez acheté une plateforme avec accélération, mais le chemin du trafic ne l’utilise pas.
Ou le cipher/paramètre choisi la contourne.

La crypto n’est pas juste « AES vs ChaCha » ; c’est tout le datapath

Les débats sur les ciphers font plaisir parce que ça donne l’impression d’ajuster une voiture de course. Mais la plupart des problèmes de perf VPN ressemblent davantage à « les pneus sont à plat ».
Posez les questions pas glamour :

Le VPN est-il en kernel ou userspace ?
Est-il en transport UDP ou TCP ?
L’offload matériel est-il actif de bout en bout ?
L’activation de NAT ou du routing par politique a-t-elle désactivé le fast-path ?
Faites-vous de l’inspection profonde des paquets ou trop de logging pare-feu sur des flux chiffrés ?

Le diagnostic clé : si augmenter le nombre de flux parallèles augmente fortement le débit, vous n’êtes pas purement CPU-bound sur le crypto.
Si le débit plafonne au même niveau quelle que soit l’augmentation des flux et la taille des paquets, vous l’êtes probablement.

MTU, trous PMTUD et MSS clamping : quand « ça marche » devient « lent »

Les VPN ajoutent des en-têtes. Les en-têtes consomment du MTU. Si vous ignorez ça, vous obtenez fragmentation ou pertes. Quand PMTUD est cassé, vous n’avez même pas d’échec net.
Vous avez des timeouts, des retransmissions, et un débit qui ressemble à un générateur de nombres aléatoires.

Overhead d’encapsulation : le calcul dont vous avez réellement besoin

Commencez simplement : le MTU Ethernet est typiquement 1500 octets. Un paquet VPN doit tenir dedans.
Si vous ajoutez (par exemple) IP + UDP + en-tête VPN + tag d’authentification, vous réduisez la charge utile.

L’overhead exact varie selon le protocole et les options. Ne devinez pas. Mesurez le MTU effectif réel à travers le tunnel.

Trou PMTUD : le piège classique du durcissement « sécurité »

PMTUD repose sur les messages ICMP « Fragmentation Needed ». Bloquez-les, et TCP continue d’envoyer des paquets trop grands avec DF activé, qui sont silencieusement jetés.
TCP recule alors, retransmet, et rampe.

Le MSS clamping est un contournement : si vous réduisez le MSS TCP pour que les endpoints n’envoient jamais de paquets nécessitant fragmentation, vous bypasser PMTUD.
Mais il faut clamper sur la bonne interface, dans la bonne direction, pour le bon trafic.

Pourquoi le MSS clamping « aide un peu » mais ne résout pas tout

Vous avez clampé le MSS sur l’interface WAN au lieu de l’interface tunnel (ou l’inverse).
Vous avez clampé seulement le trafic forwardé mais pas le trafic généré localement (ou inversement).
Vous avez clampé à une valeur toujours trop élevée pour le MTU encapsulé réel.
Vous avez clampé TCP, mais le trafic problématique est UDP (certaines applications) ou vous avez de l’IPsec avec des soucis de fragmentation ESP.

Blague #2 : le MSS clamping, c’est comme couper sa frange avec une tronçonneuse — ça peut marcher, mais vous n’aimerez ni le processus ni les cas limites.

Comportement TCP sur VPN : pourquoi latence et pertes amplifient la douleur

Le débit TCP n’est pas « bande passante ». C’est la bande passante contrainte par le contrôle de congestion et le produit bande passante–délai.
Les VPN ajoutent souvent un peu de latence. Ils ajoutent aussi souvent du queueing (surtout si le routeur tamponne trop).
Une petite perte sous charge peut réduire drastiquement le débit.

Ce que signifie vraiment « plusieurs flux plus rapides qu’un seul »

Quand un flux TCP est lent mais que quatre en parallèle saturent le lien, vous observez une ou plusieurs des choses suivantes :

événements de perte qui font s’effondrer la fenêtre de congestion d’un flux
bufferbloat causant une forte variance du RTT et des ACK retardés
retransmissions dues à des problèmes MTU/fragmentation
shaping/policing par flux sur un middlebox

Ne « réglez » pas ça en disant aux utilisateurs d’augmenter le parallélisme. C’est ainsi que vous transformez votre réseau en une expérience de mise en file d’attente.
Réparez le problème sous-jacent : correction MTU, gestion de file (fq_codel/cake), shaping correct à la périphérie, ou un meilleur datapath VPN.

VPN sur TCP est généralement une douleur auto-infligée

Faire tourner un tunnel VPN sur TCP, puis du TCP à l’intérieur, crée un effondrement TCP-over-TCP : retransmissions et contrôles de congestion qui se combattent.
Si vous pouvez utiliser le transport UDP pour le tunnel, faites-le. Si vous ne pouvez pas, attendez-vous à « ça marche mais lent bizarrement quand il y a des pertes ».

Offload matériel, NAT, et pourquoi l’accélération disparaît parfois

Beaucoup de routeurs annoncent « VPN gigabit ». Puis vous activez NAT, QoS, IDS, VLAN tagging, routing par politique, ou juste un cipher différent, et soudain vous êtes à 120 Mbps.
Le morceau manquant est généralement le fast-path / offload. L’accélération matérielle est pointilleuse ; elle exige souvent un chemin de trafic très spécifique.

Moyens courants de désactiver involontairement l’offload

NAT sur l’interface chiffrée alors que le moteur d’offload attend un forwarding route-only.
Règles de pare-feu nécessitant une inspection profonde sur le datapath (ou log de chaque paquet car « audit »).
Routing par politique qui sort les paquets du pipeline accéléré.
Utilisation d’un cipher/mode non supporté par le moteur matériel.
Gestion de fragmentation en software due à un mismatch MTU.

Vous n’avez pas à vénérer l’offload. Mais vous devez savoir s’il est actif. Sinon vous optimisez le mauvais moteur.

Tâches pratiques (commandes, sorties, décisions) — faites ces contrôles, pas des impressions

Ci‑dessous des tâches concrètes. Chacune inclut des commandes, une sortie d’exemple, ce que cela signifie, et la décision à prendre.
Exécutez-les sur les endpoints VPN (routeurs, passerelles Linux, ou serveurs) et sur un client si nécessaire.

Task 1: Measure raw throughput with iperf3 (1 stream vs 4 streams)

cr0x@server:~$ iperf3 -s
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------

cr0x@server:~$ iperf3 -c 10.20.0.10 -P 1 -t 15
Connecting to host 10.20.0.10, port 5201
[  5]   0.00-15.00  sec   145 MBytes  81.0 Mbits/sec  0             sender
[  5]   0.00-15.01  sec   143 MBytes  79.8 Mbits/sec                receiver

cr0x@server:~$ iperf3 -c 10.20.0.10 -P 4 -t 15
Connecting to host 10.20.0.10, port 5201
[SUM]   0.00-15.00  sec   580 MBytes   324 Mbits/sec  12             sender
[SUM]   0.00-15.01  sec   575 MBytes   321 Mbits/sec                receiver

Signification : Un flux fait 80 Mbps, quatre flux atteignent 320 Mbps. Le chemin peut déplacer les données, mais le TCP mono-flux souffre.
Décision : Prioriser diagnostics MTU/PMTUD, pertes et queueing. Ne pas acheter du matériel tout de suite.

Task 2: Check CPU saturation and per-core hotspots (Linux)

cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.8.0 (gw-a)  12/28/2025  _x86_64_  (8 CPU)

12:10:01 AM  CPU   %usr %nice  %sys %iowait  %irq %soft  %steal %idle
12:10:02 AM  all    6.2  0.0   9.8    0.0    0.0  4.1     0.0  79.9
12:10:02 AM    0    2.0  0.0   6.0    0.0    0.0  1.0     0.0  91.0
12:10:02 AM    1   38.0  0.0  55.0    0.0    0.0  7.0     0.0   0.0
12:10:02 AM    2    1.0  0.0   2.0    0.0    0.0  0.0     0.0  97.0

Signification : CPU1 est saturé (0 % idle) alors que les autres sont majoritairement inactifs. Ça sent le goulot mono-thread ou une queue IRQ unique.
Décision : Si c’est OpenVPN, testez DCO ou un autre protocole. Si c’est l’IRQ, envisagez un tuning RSS/RPS/XPS et des réglages de files NIC.

Task 3: Identify the VPN process and whether it’s the hot spot

cr0x@server:~$ top -H -b -n 1 | head -30
top - 00:10:12 up 12 days,  3:44,  1 user,  load average: 1.12, 0.98, 0.91
Threads: 274 total,   2 running, 272 sleeping,   0 stopped,   0 zombie
%Cpu(s): 45.3 us, 10.4 sy,  0.0 ni, 44.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 8421 root      20   0  164796  23452  10652 R  99.3   0.6  12:33.14 openvpn
 8428 root      20   0  164796  23452  10652 R  98.7   0.6  12:30.09 openvpn

Signification : Les threads OpenVPN consomment du CPU. Même s’il y a deux threads, le datapath peut rester limité par la façon dont les paquets sont traités.
Décision : Validez le mode OpenVPN (userspace vs DCO), pensez à migrer vers WireGuard ou IPsec avec accélération noyau si approprié.

Task 4: Check whether AES acceleration is available (x86 AES-NI)

cr0x@server:~$ grep -m1 -o 'aes\|avx\|sha_ni' /proc/cpuinfo | sort -u
aes
avx

Signification : Le CPU supporte les instructions AES. Ça ne garantit pas que votre VPN les utilise, mais rend un haut débit plausible.
Décision : Si le débit est encore bas et le CPU élevé, suspectez un chemin non-accéléré, overhead userspace ou offload désactivé.

Task 5: Confirm WireGuard handshake and per-peer transfer rates

cr0x@server:~$ sudo wg show
interface: wg0
  public key: T7oG...redacted...
  listening port: 51820

peer: 9q3B...redacted...
  endpoint: 198.51.100.20:49012
  allowed ips: 10.20.0.0/24
  latest handshake: 38 seconds ago
  transfer: 21.14 GiB received, 18.02 GiB sent
  persistent keepalive: every 25 seconds

Signification : Le tunnel est vivant. Les compteurs de transfert bougent. Si la perf est mauvaise, arrêtez de blâmer « l’instabilité des handshakes ».
Décision : Passez aux tests MTU/queueing et au profiling CPU ; WireGuard lui‑même est rarement le goulot à moins que la machine soit sous-dimensionnée.

Task 6: Inspect IPsec state and whether it’s rekeying too often

cr0x@server:~$ sudo ip -s xfrm state
src 203.0.113.10 dst 198.51.100.20
	proto esp spi 0x0000000b reqid 1 mode tunnel
	replay-window 32 flag af-unspec
	aead rfc4106(gcm(aes)) 0x... 128
	anti-replay context: seq 0x0007a12f, oseq 0x0, bitmap 0x00000000
	lifetime config:
	  limit: soft (INF) hard (INF)
	lifetime current:
	  12345(s) 0(bytes)
	stats:
	  replay-window 0 replay 0 failed 0
	  bytes 9823141234 packets 912341 errors 0

Signification : IPsec est stable (pas d’erreurs, compteurs augmentent). Un rekey fréquent montrerait des changements d’SA répétés et parfois des pauses courtes.
Décision : Si le CPU est élevé ici, regardez l’absence d’accélération matérielle ou l’overhead des petits paquets ; sinon passez au MTU/PMTUD.

Task 7: Find the effective MTU through the tunnel with DF pings (binary search)

cr0x@server:~$ ping -M do -s 1472 -c 3 10.20.0.10
PING 10.20.0.10 (10.20.0.10) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420

--- 10.20.0.10 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss

cr0x@server:~$ ping -M do -s 1392 -c 3 10.20.0.10
PING 10.20.0.10 (10.20.0.10) 1392(1420) bytes of data.
1400 bytes from 10.20.0.10: icmp_seq=1 ttl=64 time=18.6 ms
1400 bytes from 10.20.0.10: icmp_seq=2 ttl=64 time=18.7 ms
1400 bytes from 10.20.0.10: icmp_seq=3 ttl=64 time=18.5 ms

--- 10.20.0.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Signification : Vous avez découvert une contrainte MTU réelle (1420). Si l’interface tunnel est configurée plus haut, fragmentation ou pertes sont probables.
Décision : Réglez le MTU du tunnel en conséquence et/ou clamperez le MSS. Vérifiez aussi que ICMP frag-needed n’est pas bloqué sur le chemin.

Task 8: Check current interface MTU settings

cr0x@server:~$ ip link show dev wg0
6: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

Signification : Le MTU de wg0 correspond à la limite découverte. Bien.
Décision : Si vous avez trouvé un path MTU plus bas que l’interface MTU, diminuez-le ; ne « laissez pas fragmenter en espérant ».

Task 9: Verify MSS clamping rules (iptables) and confirm packet counters increment

cr0x@server:~$ sudo iptables -t mangle -S | grep -E 'TCPMSS|MSS'
-A FORWARD -o wg0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -i wg0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

cr0x@server:~$ sudo iptables -t mangle -L FORWARD -v -n | grep TCPMSS
  842K   52M TCP  --  *  wg0  0.0.0.0/0  0.0.0.0/0  tcp flags:0x02/0x02 TCPMSS clamp to PMTU
  799K   49M TCP  --  wg0 *   0.0.0.0/0  0.0.0.0/0  tcp flags:0x02/0x02 TCPMSS clamp to PMTU

Signification : Le MSS clamping est appliqué dans les deux sens et les compteurs augmentent. C’est ce qu’il faut quand PMTUD est peu fiable.
Décision : Si les compteurs sont à zéro, vous avez clampé la mauvaise chaîne/interface ; corrigez l’emplacement. Si PMTUD fonctionne, le clamping peut être optionnel.

Task 10: Confirm ICMP “fragmentation needed” isn’t being dropped (nftables example)

cr0x@server:~$ sudo nft list ruleset | grep -n 'icmp type'
42:    ip protocol icmp icmp type { echo-request, echo-reply, destination-unreachable, time-exceeded } accept

Signification : « destination-unreachable » inclut souvent les frag-needed ; le bloquer est la façon de fabriquer des trous PMTUD.
Décision : Si votre ruleset n’autorise que echo-request/echo-reply, étendez-le. Les équipes sécurité peuvent journaliser ; elles ne devraient pas le dropper.

Task 11: Look for fragmentation and reassembly signals in interface counters

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped overrun mcast
    9812312312 81231231 0       1234    0       0
    TX:  bytes  packets  errors  dropped carrier collsns
    8712312312 70123123 0       9876    0       0

Signification : Paquets dropés sous charge (TX dropped, RX dropped) corrèlent fortement avec la pression des buffers, des erreurs de shaping ou des soucis MTU.
Décision : Si les drops montent pendant les tests iperf, corrigez le queueing/shaping. Si les drops n’apparaissent que sur les gros paquets, reconsidérez MTU/MSS.

Task 12: Check for retransmits and TCP pain (ss -i)

cr0x@server:~$ ss -ti dst 10.20.0.10 | head -20
ESTAB 0 0 10.10.0.5:46732 10.20.0.10:445
	 cubic wscale:7,7 rto:220 rtt:48.3/12.1 ato:40 mss:1360 pmtu:1420 rcvmss:1360 advmss:1360 cwnd:18 bytes_acked:8123412 segs_out:51234 segs_in:49871 send 40.5Mbps lastsnd:28 lastrcv:12 lastack:12 pacing_rate 81.0Mbps retrans:214/51234

Signification : Retrans non négligeables (214) plus cwnd modeste suggèrent pertes/queueing/MTU qui impactent TCP.
Décision : Si les retrans augmentent pendant les transferts, trouvez où les paquets sont dropés. Ne touchez pas aux sysctls tant que vous avez des drops.

Task 13: Detect bufferbloat under load using ping while saturating

cr0x@server:~$ ping -i 0.2 -c 20 10.20.0.10
PING 10.20.0.10 (10.20.0.10) 56(84) bytes of data.
64 bytes from 10.20.0.10: icmp_seq=1 ttl=64 time=19.2 ms
64 bytes from 10.20.0.10: icmp_seq=2 ttl=64 time=18.9 ms
64 bytes from 10.20.0.10: icmp_seq=3 ttl=64 time=210.5 ms
64 bytes from 10.20.0.10: icmp_seq=4 ttl=64 time=243.1 ms
64 bytes from 10.20.0.10: icmp_seq=5 ttl=64 time=198.7 ms

Signification : Pics de latence sous charge indiquent du queueing / bufferbloat. Ça écrase le débit TCP et fait « bugger » les applications.
Décision : Mettez en place une gestion de file raisonnable (fq_codel/cake) et shapez au point de goulot, typiquement la sortie WAN.

Task 14: Confirm qdisc and apply fq_codel (Linux) if appropriate

cr0x@server:~$ tc qdisc show dev eth0
qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

cr0x@server:~$ sudo tc qdisc replace dev eth0 root fq_codel
cr0x@server:~$ tc qdisc show dev eth0
qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn

Signification : pfifo_fast est un vestige. fq_codel apporte une gestion active des files qui réduit le bufferbloat.
Décision : Si la latence pique sous charge, gardez fq_codel (ou cake) et ajoutez du shaping si le goulot est en amont.

Task 15: Check NIC and IRQ distribution (RSS/RPS hint)

cr0x@server:~$ cat /proc/interrupts | head -12
           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7
  35:   9123412  781234123      12345      11234      10987      10321      10012       9987  IR-PCI-MSI 524288-edge  eth0-TxRx-0

Signification : Une queue d’interruption qui tombe majoritairement sur CPU1 peut créer un goulot par cœur même si le CPU global semble OK.
Décision : Si un cœur est saturé et les interruptions déséquilibrées, ajustez RSS/RPS ou l’affinité IRQ ; ou mettez à jour le matériel/les pilotes NIC.

Trois mini-récits d’entreprise pris sur le terrain

Mini-récit 1 : Incident causé par une mauvaise hypothèse (PMTUD « durcissement sécurité »)

Une entreprise de taille moyenne a déployé un VPN site‑à‑site entre deux bureaux et une VPC cloud. Les pings étaient bons. Le RDP fonctionnait.
Puis l’équipe finance a commencé à exporter de gros rapports et le transfert restait bloqué à 2–5 % pendant des minutes, puis avançait, puis bloquait à nouveau.
L’hypothèse initiale : « Le crypto du VPN est trop lent ; il nous faut des boîtiers plus gros. »

L’équipe réseau a vérifié le CPU. Beaucoup de marge. Ils ont changé de ciphers quand même parce que c’est ce que font les gens coincés.
Légères améliorations dans un sens, pire dans l’autre. Le problème est resté étrange et intermittent, ce qui nourrit les mauvaises théories.

Un SRE a fait un test DF ping et a immédiatement rencontré un « message too long » MTU autour de 1412 octets — plus bas que prévu.
Ensuite il a vérifié les règles pare‑feu et a trouvé que destination-unreachable ICMP était dropé sur une ACL périmétrique « durcie ».
PMTUD était morte, donc les sessions TCP noyaient les gros paquets jusqu’à ce que les retransmissions et timeouts permettent l’avancement.

Le correctif n’était pas un routeur plus puissant. C’était d’autoriser les types ICMP nécessaires pour PMTUD et d’ajouter le MSS clamping en solution de secours.
Les transferts sont passés de « minutes de blocages » à « ennuyeusement rapides ». L’action postmortem n’était pas « ne pas durcir ».
C’était « ne pas casser les protocoles fondamentaux et appeler ça de la sécurité. »

Mini-récit 2 : L’optimisation qui s’est retournée contre eux (activation d’une « accélération » qui désactivait le fast path)

Une autre organisation avait un tunnel IPsec avec des performances moyennes. Un ingénieur réseau a activé une fonctionnalité vendor commercialisée comme « inspection avancée du trafic »
pour « meilleure visibilité ». C’était censé être léger. C’était aussi activé globalement parce que l’UI rendait cela l’option la plus simple.

En un jour, les plaintes sont arrivées : jitter VoIP, transferts de fichiers lents, réplication DB en retard.
La supervision montrait une utilisation WAN plus basse que la normale tandis que la latence applicative montait. C’est toujours un indice : le réseau n’est pas saturé ; il est congestionné à l’intérieur.

Le CPU du routeur n’était pas globalement saturé, mais le traitement des paquets a explosé et les interruptions ont grimpé. Les compteurs offload se sont aplatis.
La fonctionnalité d’inspection forçait les paquets hors du datapath accéléré et dans une voie lente logicielle.
Soudain le même matériel faisait plus de travail par paquet et ne tenait plus la charge.

Désactiver la fonctionnalité a restauré l’offload et le débit. Ils ont réintroduit la visibilité plus tard via des flow logs du côté décrypté et un échantillonnage sélectif,
pas une inspection paquet‑par‑paquet sur l’interface tunnel. La leçon n’était pas « ne jamais inspecter ».
C’était « si vous activez une fonctionnalité qui touche chaque paquet, prouvez qu’elle n’empêche pas ce qui paie vos factures de perf. »

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la journée (tests de référence et discipline de changement)

Une entreprise a planifié une migration de services entre datacenters via VPN. Le VPN « semblait OK » lors de tests informels.
Mais l’équipe SRE a insisté sur une baseline : iperf3 dans les deux sens, 1 et 4 flux, tests DF MTU, et ping‑sous‑charge.
Ils ont enregistré les résultats, pas pour la science mais pour avoir une source de vérité avant/après.

Pendant la fenêtre de migration, le débit a chuté d’environ 60 % et des pics de latence sont apparus sous charge.
Grâce à la baseline, ils n’ont pas perdu de temps à discuter de la « variabilité internet normale ».
Ils savaient exactement à quoi ressemblait le « normal » pour leur chemin.

Ils ont rollbacké le changement le plus récent : une mise à jour de politique QoS sur l’edge WAN qui avait accidentellement shaped le trafic du tunnel deux fois
(une fois sur l’interface physique et une seconde fois sur un sous‑interface VLAN). Le double shaping causait queueing et drops.
Le correctif était sans gloire : un seul shaper au vrai goulot, fq_codel pour l’équité, et une propriété claire de la politique.

Personne n’a eu de trophée. Mais la réplication s’est terminée à temps et la migration ne s’est pas transformée en incident de week‑end.
Les pratiques ennuyeuses — baselines, changements incrémentaux et « un shaper pour les gouverner tous » — sont comment les adultes gardent les VPN rapides.

Erreurs courantes : symptôme → cause racine → fix

Voici les récidivistes. Si vous reconnaissez votre situation, sautez l’improvisation et appliquez le correctif spécifique.

1) Symptom: Speed tops out at 80–200 Mbps no matter what

Cause racine : goulot CPU/crypto, VPN mono-thread, ou offload désactivé.
Fix : Vérifiez le CPU par cœur. Confirmez l’état de l’offload. Passez au datapath noyau (WireGuard, IPsec kernel) ou OpenVPN DCO si possible ; sinon changez le matériel.

2) Symptom: Small web browsing fine, big downloads stall or crawl

Cause racine : mismatch MTU ou trou PMTUD causant des drops de gros paquets.
Fix : DF ping pour trouver le MTU réel. Autorisez ICMP destination-unreachable/time-exceeded. Clamp MSS sur le chemin de forwarding du tunnel.

3) Symptom: One direction fast, reverse direction slow

Cause racine : routage asymétrique, shaping asymétrique, ou un endpoint CPU-bound sur decrypt/encrypt.
Fix : Testez iperf3 dans les deux sens. Vérifiez CPU et qdisc des deux côtés. Vérifiez tables de routage et routing par politique.

4) Symptom: VPN works until traffic ramps up, then latency explodes

Cause racine : bufferbloat ou uplink surchargé sans shaping/AQM.
Fix : Appliquez fq_codel/cake et shapez au vrai goulot (généralement WAN egress). Retestez ping sous charge.

5) Symptom: “We enabled QoS and now VPN is slower”

Cause racine : mauvaise classification (le trafic chiffré ressemble à tout), double shaping, ou des shapers trop bas causant des drops.
Fix : Shapez une seule fois, sur le vrai egress. Classez sur le trafic inner seulement quand possible (côté décrypté), sinon utilisez des politiques grossières.

6) Symptom: OpenVPN performance terrible on fast links

Cause racine : overhead userspace et contraintes mono-thread.
Fix : Envisagez OpenVPN DCO, ou migrez vers WireGuard/IPsec pour haut débit. Si impossible, assurez UDP mode, ajustez MTU/MSS et affinez l’affectation aux cœurs rapides.

7) Symptom: IPsec throughput dropped after enabling NAT on tunnel path

Cause racine : offload désactivé ou mismatch de politique ; NAT force le chemin lent.
Fix : Ré‑architectez pour éviter le NAT sur le tunnel quand possible. Si nécessaire, confirmez que le matériel/pilote le supporte ; sinon acceptez un débit moindre ou upgradez.

8) Symptom: Speed tests vary wildly across time of day

Cause racine : congestion amont, shaping ISP, ou saturation d’un medium partagé ; le VPN rend ça plus visible.
Fix : Établissez des baselines, mesurez aussi hors VPN, et shapez le trafic pour réduire les pertes. Si c’est l’ISP, escaladez avec des preuves.

Listes de contrôle / plan étape par étape

Checklist A: The “stop guessing” measurement sequence

Exécutez iperf3 à travers le VPN : 1 flux et 4 flux, dans les deux sens.
Vérifiez CPU par cœur et interruptions pendant le test.
DF ping pour trouver le MTU effectif à travers le tunnel.
Vérifiez que ICMP frag-needed n’est pas bloqué ; confirmez que les compteurs MSS clamp augmentent si utilisé.
Testez ping sous charge pour détecter le bufferbloat.
Vérifiez les drops sur les interfaces pertinentes (WAN et tunnel).

Checklist B: Decision tree you can use on an incident bridge

Si un cœur CPU est bloqué : confirmez le type de VPN ; passez au noyau/offload ou upgradez le matériel ; arrêtez de tripoter le MTU tant que vous ne pouvez pas chiffrer à la vitesse requise.
Si multi‑stream aide beaucoup : chassez MTU/PMTUD et pertes/queueing ; implémentez AQM et shaping avant de toucher au crypto.
Si DF ping échoue à des tailles surprenamment faibles : corrigez MTU et ICMP ; clamperez MSS ; retestez.
Si la latence pique sous charge : implémentez fq_codel/cake ; shapez au goulot ; retestez.
Si la perf a changé après activation d’une fonctionnalité : confirmez l’état offload/fast path ; revenez en arrière et réintroduisez de façon chirurgicale.

Checklist C: What to document so you don’t relearn this next quarter

Résultats de baseline iperf3 (1 vs 4 flux, deux sens) et conditions de test.
MTU effectif à travers le tunnel et MTU configuré sur l’interface.
Si MSS clamping est utilisé, où et pourquoi (PMTUD fiable ou pas).
État offload/accélération et quelles fonctionnalités le désactivent.
Paramètres de queueing/shaping et la justification des débits.

FAQ

1) Why is my VPN slow when my ISP speed test is fast?

Les tests ISP utilisent souvent plusieurs flux parallèles et peuvent s’exécuter vers des serveurs proches. Votre trafic VPN peut être mono‑flux,
avoir un RTT plus long, et être limité par le crypto endpoint ou des problèmes MTU. Testez avec iperf3 à travers le VPN et comparez 1 vs 4 flux.

2) How do I know if it’s CPU/crypto vs MTU?

Les goulots CPU/crypto montrent généralement un plafond dur de débit et un cœur bloqué pendant la charge.
Les problèmes MTU/PMTUD montrent des blocages, retransmissions, et une grosse amélioration quand on clamp le MSS ou baisse le MTU ; le multi‑stream aide souvent.

3) Should I just switch to WireGuard?

Si vous êtes coincé sur un VPN userspace mono-thread et que vous avez besoin de centaines de Mbps à Gbps, migrer aide souvent.
Mais ne l’utilisez pas comme substitut au diagnostic MTU et queueing ; WireGuard peut aussi être lent si le chemin droppe des paquets ou buffere trop.

4) Is MSS clamping always necessary?

Non. Si PMTUD fonctionne bout en bout (ICMP frag-needed permis) et que votre MTU de tunnel est correctement configuré, vous pouvez vous en passer.
Dans la réalité, PMTUD est souvent cassé par des middleboxes, donc le MSS clamping est un contournement pragmatique.

5) What MSS value should I set?

Préférez --clamp-mss-to-pmtu quand disponible ; il s’adapte au MTU d’interface.
Si vous devez fixer une MSS, calculez‑la à partir du path MTU effectif et des en‑têtes standards (typiquement MTU moins 40 pour IPv4 TCP headers, plus pour IPv6).
Mesurez d’abord ; deviner ici crée de nouveaux problèmes.

6) Why does ping look fine but file transfers are slow?

Ping utilise des paquets petits. Votre problème concerne généralement les gros paquets (MTU/fragmentation) ou les files soutenues sous charge (bufferbloat),
que le ping n’expose pas sauf si vous testez sous charge et avec DF.

7) Can firewall logging really slow down a VPN?

Oui. Logger par paquet ajoute du CPU et I/O, et peut désactiver le fast-path/offload sur certaines plateformes.
Loggez les flows ou événements échantillonnés plutôt que chaque paquet sur des chemins à haut débit.

8) What’s the single most common “security” change that breaks VPN throughput?

Bloquer ICMP destination-unreachable/time-exceeded. Ça casse PMTUD et convertit les problèmes MTU en drops silencieux et tempêtes de retransmission.
Autorisez les types ICMP nécessaires ; la sécurité peut rester stricte sans se saborder.

9) Why do multiple TCP streams “fix” my throughput?

Plusieurs flux masquent les pertes/queueing/MTU en laissant au moins certains flux progresser pendant que d’autres reculent.
C’est un indice de diagnostic, pas une vraie solution. Réparez les drops, PMTUD et bufferbloat à la place.

10) How do I explain this to management without sounding like I’m making excuses?

Montrez deux graphiques : débit vs utilisation CPU par cœur, et latence ping sous charge. Ajoutez les résultats iperf3 1‑flux vs 4‑flux.
C’est la preuve de l’endroit où se situe le goulot et du changement qui le résoudra.

Conclusion : prochaines étapes exécutables aujourd’hui

Diagnosez la lenteur VPN comme n’importe quel autre problème de performance en production : mesurez, isolez, puis changez une variable.
Ne commencez pas par des débats de cipher. Commencez par le playbook rapide : iperf3 (1 vs 4 flux), CPU par cœur, tests DF MTU, vérification MSS/ICMP,
et latence‑sous‑charge pour repérer le bufferbloat.

Prochaines étapes pratiques :

Exécutez iperf3 à travers le VPN dans les deux sens avec 1 et 4 flux ; notez les chiffres.
Pendant le test, capturez CPU par cœur et distribution des interruptions ; prouvez ou éliminez les limites de calcul des endpoints.
Mesurez le path MTU réel avec des DF pings ; alignez le MTU du tunnel et appliquez MSS clamping si PMTUD n’est pas fiable.
Vérifiez les drops et pics de latence sous charge ; corrigez la gestion de file et le shaping au goulot.
Si vous confirmez une limite du datapath crypto, changez l’architecture (noyau/offload/DCO) ou changez le matériel. Tout le reste, c’est du théâtre.