Tests de qualité VPN de bureau : mesurer la latence, la gigue et la perte pour prouver les problèmes du FAI

À quoi ressemble réellement une « bonne qualité VPN »

La plupart des équipes ne remarquent la qualité du VPN que lorsqu’elle est mauvaise. C’est une erreur. Définissez ce que « bon » signifie, sinon vous passerez votre vie à débattre de sensations.

Pour un VPN bureau→datacenter (ou bureau→cloud) transportant du trafic interactif (VoIP, RDP, VDI, SSH), voici les cibles pratiques que j’utilise :

• Latence (RTT) : La stabilité prime sur la valeur basse. Moins de 50 ms RTT est excellent pour une même région ; moins de 100 ms est utilisable ; les pics sont l’ennemi.
• Gigue : Moins de 5–10 ms est généralement acceptable ; au‑delà de 20–30 ms la voix commence à ressembler à un robot mal en point.
• Perte de paquets : Moins de 0,1 % est habituellement invisible ; 0,5 % commence à gêner réellement les applications ; 1 % est une taxe sur la productivité ; 2 % est une crise.
• Réordonnancement : Généralement proche de zéro ; lorsqu’il apparaît, TCP peut sembler « lent » même si la bande passante est disponible.
• Sanité du MTU : Un MTU correct de bout en bout évite la fragmentation/les trous noirs ; un MTU erroné peut imiter une « lenteur aléatoire ».
• Débit : Pour les flux volumineux, vous vous souciez du débit soutenu en charge, pas des chiffres de pointe des tests de vitesse.

Les VPN compliquent la mesure parce que le tunnel ajoute de l’overhead, change la taille des paquets et souvent décale le trafic sur un chemin différent du trafic Internet non encapsulé. Résultat : votre argument « le FAI est OK » s’effondre dès que vous réalisez que vous n’avez testé qu’un CDN public, pas à travers le VPN vers la ressource réellement utilisée par les utilisateurs.

Faits intéressants et courte histoire (parce que ça explique le bazar actuel)

• Fait 1 : L’outil classique ping date du début des années 1980 et s’est inspiré du sonar ; il a été conçu pour vérifier la joignabilité, pas pour analyser la performance.
• Fait 2 : La « gigue » est devenue une métrique courante surtout parce que la voix/vidéo en temps réel est passée des réseaux commutés par circuit aux réseaux à paquets.
• Fait 3 : IPsec (technologie VPN site‑à‑site courante) a été standardisé dans les années 1990, quand les liaisons Internet typiques étaient bien plus lentes et que le NAT n’était pas omniprésent.
• Fait 4 : WireGuard est relativement récent (milieu‑fin des années 2010) et volontairement minimal ; moins de paramètres dangereux et une meilleure performance de base en général.
• Fait 5 : Le débit TCP est contraint par le RTT et la perte ; c’est pourquoi une ligne haute‑capacité peut quand même « paraître lente » sur un chemin VPN avec perte ou gigue.
• Fait 6 : Beaucoup de liaisons haut débit grand public et même « pro » reposent sur la suroffre ; la congestion dépend souvent de l’heure et n’apparaît pas dans un test unique.
• Fait 7 : Le bufferbloat (mise en tampon excessive dans les équipements réseau) est devenu un sujet courant à la fin des années 2000 et peut provoquer d’énormes pics de latence lors d’upload/download.
• Fait 8 : L’ECMP (equal‑cost multipath) dans les réseaux fournisseurs peut provoquer du réordonnancement ; l’encapsulation VPN change parfois la façon dont les flux sont hachés sur les chemins.
• Fait 9 : Certains réseaux traitent encore ICMP différemment (limitation de débit, dépriorisation) ; c’est pourquoi il faut corroborer ping avec d’autres méthodes avant de déclarer victoire.

Blague 1 : L’avantage du « perte de paquets intermittente » est qu’elle enseigne la pleine conscience à tout le monde. Vous ne pouvez pas vous accrocher aux attentes quand vos paquets n’existent pas.

Les métriques importantes (et celles qui mentent)

Latence : mesurer des distributions, pas un seul nombre

La latence moyenne masque la douleur. Les utilisateurs ressentent les pics. Capturez min/moy/max et les percentiles si vos outils le permettent.
Quand quelqu’un dit « le VPN est lent », il décrit généralement la variabilité, pas une moyenne en régime permanent.

Gigue : la métrique « qualité » pour le trafic en temps réel

La gigue est la variation du délai. Le VoIP et la visioconférence peuvent tamponner un peu ; une fois que la gigue dépasse le tampon,
l’audio se coupe et la vidéo gèle. Les tunnels VPN peuvent amplifier la gigue quand des appliances de chiffrement sont liées au CPU ou quand
les files d’attente du FAI se remplissent sous charge.

Perte : le tueur silencieux du débit

TCP interprète la perte comme de la congestion et recule. Une petite quantité de perte aléatoire peut effondrer le débit sur des chemins à RTT long.
Pour les VPN de bureau, la perte est aussi la cause principale de « RDP saccade », « Teams gèle » et « copie de fichier qui bloque ».

Débit : tester dans les deux sens et avec des flux concurrents

Un seul flux n’est pas représentatif. Beaucoup de passerelles VPN se débrouillent avec un flux iperf et s’effondrent avec dix. Testez aussi l’upload :
les bureaux saturent souvent l’ascendant pendant les sauvegardes, scans ou quand « quelqu’un a envoyé un fichier de 2 Go à toute l’entreprise ».

MTU/fragmentation : le piège classique du VPN

L’encapsulation VPN ajoute de l’overhead. Si votre MTU effectif diminue et que PMTUD est bloqué ou cassé, les gros paquets sont blackholés.
Les symptômes ressemblent à « certains sites fonctionnent, d’autres non » ou « SSH va bien mais le transfert de fichiers bloque ».
Les problèmes de MTU sont ennuyeux, courants et méritent d’être testés dès le départ.

Ce qui ment : tests de vitesse publics, ping unique et « tout est vert dans le tableau de bord »

Les tests de vitesse publics frappent souvent des nœuds CDN proches sur des chemins bien peered que votre trafic VPN n’emprunte jamais. Un ping unique à 9h03 ne prouve presque rien. Et les tableaux de bord deviennent verts quand ils mesurent la joignabilité, pas l’expérience.

Une citation (idée paraphrasée) : John Allspaw a soutenu que la fiabilité vient de la compréhension des systèmes dans des conditions réelles, et non du blâme des individus.

Playbook de diagnostic rapide

Quand le VPN de bureau « donne une mauvaise impression », vous n’avez pas le temps pour un projet de recherche d’une semaine. Commencez par les discriminants les plus rapides : le goulot est‑il sur le LAN/Wi‑Fi local, le dernier kilomètre du FAI, la passerelle VPN ou le réseau en amont ?

Première étape : confirmer le périmètre et choisir deux points

• Choisir un client : une machine filaire sur le LAN du bureau (pas le Wi‑Fi sauf si la plainte concerne le Wi‑Fi).
• Choisir deux cibles : (1) l’IP publique de la passerelle VPN du bureau, (2) une machine interne côté VPN (jump box ou serveur).
• Décider de la période : « maintenant » plus « répéter pendant les heures de pointe ».

Deuxième étape : scinder le chemin en segments

• Client → routeur du bureau : prouve les problèmes LAN/Wi‑Fi.
• Client → IP publique de la passerelle VPN : prouve le chemin FAI jusqu’à la passerelle.
• Client → hôte interne via le VPN : prouve le tunnel + le côté distant.
• Passerelle VPN → hôte interne : prouve le réseau distant si vous pouvez lancer des tests là‑bas.

Troisième étape : exécuter trois tests rapides

1. Ping avec horodatages et intervalles (base de latence/gigue/perte).
2. MTR (perte/latence par saut ; utile pour l’escalade, pas un dogme).
3. Un court iperf3 dans les deux sens (débit + perte sous charge).

Quatrième étape : provoquer le problème (avec précaution)

Si la qualité s’effondre uniquement quand la liaison est chargée, vous avez besoin d’un test de charge contrôlé. Saturez brièvement l’ascendant,
mesurez la latence sous charge et vous exposerez le bufferbloat, des bogues de shaping ou une appliance VPN qui panique lorsqu’elle doit faire du vrai travail.

Cinquième étape : décider où se concentrer

• Mauvais jusqu’à l’IP publique de la passerelle : circuit local/FAI, peering ou congestion du dernier kilomètre.
• Bon vers la passerelle mais mauvais à travers le tunnel : CPU de la passerelle VPN, MTU, paramètres de chiffrement ou côté distant.
• Bon en filaire mais mauvais en Wi‑Fi : arrêtez de blâmer le FAI ; corrigez le RF, le roaming ou les pilotes clients.

Tâches pratiques : commandes, sorties et décisions (12+)

Ces tâches supposent des clients/serveurs Linux. Si vous êtes sur macOS ou Windows, vous pouvez appliquer la logique ; les noms de commandes changent, la physique ne change pas.

Task 1: Identify the active interface and gateway (avoid testing the wrong path)

cr0x@server:~$ ip route show
default via 192.0.2.1 dev eno1 proto dhcp src 192.0.2.50 metric 100
192.0.2.0/24 dev eno1 proto kernel scope link src 192.0.2.50

Ce que cela signifie : Votre client sort via eno1 vers 192.0.2.1.
Si quelqu’un effectue des tests sur le Wi‑Fi alors que les utilisateurs sont en filaire (ou l’inverse), vous déboguez de la fiction.

Décision : Si la route est incorrecte, corrigez‑la avant de tester. Sinon, poursuivez.

Task 2: Baseline LAN health: ping the default gateway

cr0x@server:~$ ping -c 20 -i 0.2 192.0.2.1
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
64 bytes from 192.0.2.1: icmp_seq=1 ttl=64 time=0.362 ms
64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=0.401 ms
...
20 packets transmitted, 20 received, 0% packet loss, time 3804ms
rtt min/avg/max/mdev = 0.331/0.389/0.471/0.038 ms

Ce que cela signifie : C’est votre plancher. Si vous voyez de la perte ou une gigue de plusieurs millisecondes ici sur un réseau filaire, le FAI n’est pas votre premier problème.

Décision : Si le ping LAN est instable, vérifiez les ports de commutateur, le duplex, les erreurs NIC, le Wi‑Fi ou la congestion locale.

Task 3: Check NIC counters for drops and errors

cr0x@server:~$ ip -s link show dev eno1
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    987654321  123456      0       2       0       123
    TX:  bytes packets errors dropped carrier collsns
    876543210  112233      0       0       0       0

Ce que cela signifie : Quelques pertes peuvent être tolérables ; une augmentation des erreurs/pertes pendant les plaintes est un indice très fort.

Décision : Si les erreurs augmentent, remplacez le câble, corrigez un mismatch de duplex, mettez à jour pilotes/firmware ou changez de port.

Task 4: Confirm VPN route selection (split tunnel surprises are common)

cr0x@server:~$ ip route get 10.10.20.15
10.10.20.15 dev wg0 src 10.200.0.2 uid 1000
    cache

Ce que cela signifie : Le trafic vers 10.10.20.15 passe par wg0 (le VPN).
S’il passe par votre route par défaut à la place, vous ne testez pas le tunnel du tout.

Décision : Corrigez le routage/policy routing avant de diagnostiquer la « performance VPN ».

Task 5: Measure RTT, jitter proxy (mdev), and loss to the VPN gateway public IP

cr0x@server:~$ ping -c 50 -i 0.2 203.0.113.10
PING 203.0.113.10 (203.0.113.10) 56(84) bytes of data.
64 bytes from 203.0.113.10: icmp_seq=1 ttl=52 time=18.9 ms
64 bytes from 203.0.113.10: icmp_seq=2 ttl=52 time=19.2 ms
...
50 packets transmitted, 50 received, 0% packet loss, time 10052ms
rtt min/avg/max/mdev = 18.5/19.4/28.7/1.8 ms

Ce que cela signifie : mdev n’est pas une mesure parfaite de la gigue, mais c’est un bon indicateur rapide.
Le pic max (28.7 ms) est notable ; s’il grimpe à 200+ ms pendant les plaintes, vous observez probablement de la congestion.

Décision : Si de la perte apparaît ici, concentrez‑vous sur le chemin FAI avant d’accuser les paramètres crypto du VPN.

Task 6: MTR to the VPN gateway public IP (evidence, not theology)

cr0x@server:~$ mtr -rwzc 200 203.0.113.10
Start: 2025-12-28T09:15:02+0000
HOST: office-client                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.0.2.1                        0.0%   200    0.5   0.6   0.4   1.2   0.1
  2.|-- 198.51.100.1                     0.0%   200    7.8   8.1   6.9  20.3   1.5
  3.|-- 198.51.100.34                    1.5%   200   12.1  12.8  10.2  45.7   4.2
  4.|-- 203.0.113.10                     0.5%   200   19.6  21.4  18.4  80.2   6.9

Ce que cela signifie : La perte sur des sauts intermédiaires peut être due à une limitation d’ICMP. L’essentiel est de savoir si la perte persiste jusqu’au saut final. Ici, 0,5 % de perte vers la destination est suffisamment réel pour détériorer l’expérience VPN.

Décision : Si la perte vers la destination coïncide avec les fenêtres de plainte, commencez à constituer un dossier d’escalade auprès du FAI.

Task 7: Compare to a “control” target outside the VPN (prove it’s path-specific)

cr0x@server:~$ ping -c 50 -i 0.2 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=9.7 ms
...
50 packets transmitted, 50 received, 0% packet loss, time 10043ms
rtt min/avg/max/mdev = 9.4/9.9/12.5/0.4 ms

Ce que cela signifie : L’Internet en général peut sembler sain alors que le chemin vers votre passerelle VPN est malade.
C’est exactement pourquoi vous testez le point de terminaison VPN réel.

Décision : Si le contrôle est propre mais que la passerelle ne l’est pas, poussez le FAI sur le routage/le peering vers cette destination.

Task 8: Verify MTU to an internal host (find blackholes early)

cr0x@server:~$ ping -M do -s 1372 -c 3 10.10.20.15
PING 10.10.20.15 (10.10.20.15) 1372(1400) bytes of data.
1380 bytes from 10.10.20.15: icmp_seq=1 ttl=63 time=24.3 ms
1380 bytes from 10.10.20.15: icmp_seq=2 ttl=63 time=24.8 ms
1380 bytes from 10.10.20.15: icmp_seq=3 ttl=63 time=25.1 ms

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

Ce que cela signifie : -M do interdit la fragmentation. Si cela échoue, votre MTU effectif est plus petit que ce que vous pensez, et PMTUD pourrait ne pas fonctionner.

Décision : Si cela échoue, réduisez le MTU du tunnel (ou appliquez un clamp MSS) et retestez jusqu’à ce que ça passe de manière consistante.

Task 9: Detect PMTUD breakage (classic “works for small, fails for big”)

cr0x@server:~$ tracepath 10.10.20.15
 1?: [LOCALHOST]                      pmtu 1500
 1:  10.200.0.1                        4.123ms
 2:  10.10.20.15                      24.910ms reached
     Resume: pmtu 1420 hops 2 back 2

Ce que cela signifie : Le PMTU du chemin est identifié comme 1420. C’est plausible pour certains scénarios d’overhead VPN.
Si vos interfaces sont réglées sur 1500 et que vous comptez sur PMTUD mais que l’ICMP est bloqué quelque part, vous pouvez obtenir des trous noirs.

Décision : Réglez le MTU VPN à la PMTU découverte (avec marge), ou appliquez un clamp TCP MSS à la frontière.

Task 10: Run iperf3 through the VPN (single stream)

cr0x@server:~$ iperf3 -c 10.10.20.15 -t 15
Connecting to host 10.10.20.15, port 5201
[  5] local 10.200.0.2 port 45322 connected to 10.10.20.15 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  6.25 MBytes  52.4 Mbits/sec    0   1.12 MBytes
[  5]   1.00-2.00   sec  6.12 MBytes  51.3 Mbits/sec    2   0.96 MBytes
...
[  5]  14.00-15.00  sec  3.10 MBytes  26.0 Mbits/sec   18   0.42 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-15.00  sec  67.2 MBytes  37.6 Mbits/sec  61             sender
[  5]   0.00-15.00  sec  66.5 MBytes  37.2 Mbits/sec                  receiver

Ce que cela signifie : Les retransmissions (Retr) et la chute du bitrate pointent vers de la perte, de la congestion ou un chemin lié au CPU. Un chemin VPN sain ne devrait pas afficher des retransmissions qui montent rapidement lors d’un court test propre.

Décision : Si les retransmissions grimpent, corrélez avec la perte de ping et étudiez le FAI ou le MTU/les files d’attente du tunnel.

Task 11: Run iperf3 reverse direction (office download can be fine while upload is a disaster)

cr0x@server:~$ iperf3 -c 10.10.20.15 -R -t 15
Connecting to host 10.10.20.15, port 5201
Reverse mode, remote host 10.10.20.15 is sending
[  5] local 10.200.0.2 port 45330 connected to 10.10.20.15 port 5201
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-15.00  sec  120 MBytes  67.1 Mbits/sec   3             sender
[  5]   0.00-15.00  sec  119 MBytes  66.5 Mbits/sec                 receiver

Ce que cela signifie : Le sens inverse est propre ; le sens avant ne l’était pas. C’est un indice fort que l’ascendant du bureau est congestionné ou mal traité, ou que votre file de sortie est gonflée.

Décision : Concentrez‑vous sur la capacité montante, le QoS/SQM ou une dégradation de l’upload par le FAI.

Task 12: Measure latency under load (bufferbloat check)

cr0x@server:~$ (ping -i 0.2 -c 50 203.0.113.10 | tail -n 3) & iperf3 -c 10.10.20.15 -t 15 > /dev/null; wait
50 packets transmitted, 50 received, 0% packet loss, time 10041ms
rtt min/avg/max/mdev = 19.0/85.4/312.7/58.1 ms

Ce que cela signifie : Le RTT moyen a été multiplié par quatre et le max a atteint 312 ms pendant l’envoi de trafic. C’est du bufferbloat classique ou une saturation de file. Les utilisateurs perçoivent cela comme « le VPN va bien jusqu’à ce qu’on fasse quelque chose ».

Décision : Implémentez une gestion intelligente des files d’attente (SQM) à la frontière, shapez juste en dessous du débit fournisseur ou augmentez la bande passante montante.

Task 13: Check VPN interface MTU and stats (tunnel-level drops)

cr0x@server:~$ ip -s link show dev wg0
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none
    RX:  bytes packets errors dropped  missed   mcast
    12345678   54321      0      45       0       0
    TX:  bytes packets errors dropped carrier collsns
    23456789   65432      0      12       0       0

Ce que cela signifie : Des drops sur l’interface de tunnel peuvent indiquer de la mise en file locale, du policing ou des rafales dépassant ce que le chemin peut supporter.

Décision : Si les drops augmentent en période de pointe, shapez le trafic, révisez le QoS et vérifiez la saturation CPU du point de terminaison VPN.

Task 14: Observe WireGuard runtime stats (handshake freshness and transfer)

cr0x@server:~$ sudo wg show
interface: wg0
  public key: zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz=
  private key: (hidden)
  listening port: 51820

peer: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy=
  endpoint: 203.0.113.10:51820
  allowed ips: 10.10.0.0/16
  latest handshake: 28 seconds ago
  transfer: 1.23 GiB received, 2.10 GiB sent
  persistent keepalive: every 25 seconds

Ce que cela signifie : Les handshakes ont lieu ; le tunnel est vivant. Si le dernier handshake devient obsolète ou clignote, vous pourriez atteindre des timeouts NAT ou un filtrage en amont.

Décision : Si les handshakes tombent pendant l’inactivité, activez le keepalive ou corrigez les timeouts NAT/firewall d’état.

Task 15: Confirm IPsec SA health (if you run IPsec)

cr0x@server:~$ sudo ipsec statusall
Status of IKE charon daemon (strongSwan 5.9.8, Linux 6.5.0, x86_64):
  uptime: 2 hours, since Dec 28 07:12:03 2025
Connections:
office-to-dc:  192.0.2.0/24 === 10.10.0.0/16
Security Associations (1 up, 0 connecting):
office-to-dc[1]: ESTABLISHED 12 minutes ago, 198.51.100.10[CN=office]...203.0.113.10[CN=dc]
office-to-dc{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c1a2b3c4_i c4b3a2c1_o
office-to-dc{1}:   192.0.2.0/24 === 10.10.0.0/16

Ce que cela signifie : L’SA est établie. Cela ne prouve pas la qualité, mais écarte le churn de négociation qui peut causer des gels intermittents.

Décision : Si les SA se renouvellent trop souvent ou fluctuent, corrigez les durées de vie, la gestion NAT‑T ou les pinholes firewall.

Task 16: Capture a short packet trace to prove fragmentation or retransmissions

cr0x@server:~$ sudo tcpdump -ni wg0 -c 20 -vv 'host 10.10.20.15 and (tcp or icmp)'
tcpdump: listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
09:18:41.120001 IP (tos 0x0, ttl 64, id 12345, offset 0, flags [DF], proto ICMP (1), length 1420)
    10.200.0.2 > 10.10.20.15: ICMP echo request, id 3011, seq 1, length 1400
09:18:41.144210 IP (tos 0x0, ttl 63, id 54321, offset 0, flags [DF], proto ICMP (1), length 1420)
    10.10.20.15 > 10.200.0.2: ICMP echo reply, id 3011, seq 1, length 1400
...

Ce que cela signifie : Vous voyez DF activé et des réponses réussies à la taille 1400 — bon pour le MTU. Pour TCP, vous chercherez des retransmissions et un rétrécissement de la fenêtre.

Décision : Utilisez les traces avec parcimonie : juste assez pour prouver une hypothèse, pas assez pour être noyé dans les paquets.

Trois mini‑histoires d’entreprise (toutes douloureusement plausibles)

Incident causé par une fausse hypothèse : « Le ping est propre, donc le FAI est innocent »

Une entreprise de taille moyenne avait un VPN site‑à‑site du siège vers un VPC cloud. Le support a signalé des sessions RDP qui gelaient puis rattrapaient en rafales. L’équipe réseau a exécuté ping vers la passerelle VPN. 0 % de perte, ~12 ms.
Ils ont déclaré le FAI ok et ont poursuivi en accusant Windows Update.

Le gel a continué. Quelqu’un a finalement lancé un test qui correspondait réellement à la charge : un upload soutenu via le VPN tout en mesurant la latence vers la passerelle. Le RTT est passé d’environ 12 ms à ~280 ms et est resté élevé. Le VPN n’était pas « down ». Il était juste coincé derrière un océan de buffering dans la file montante du routeur du bureau.

La fausse hypothèse était subtile : « Si ping est bon maintenant, la ligne est bonne. » En réalité, le ping à l’état idle mesure le chemin heureux. L’entreprise souffrait sous charge. Un simple upload de caméra, une sauvegarde cloud ou même un grand partage d’écran Teams suffisait à remplir la file et introduire des secondes de délai.

La correction n’était pas glamour. Ils ont implémenté SQM au bord et shapeé l’upload légèrement en dessous du débit réel du FAI. RDP est redevenu ennuyeux. Le FAI n’a rien changé ; le bureau l’a fait.

Optimisation qui a échoué : « Nous avons activé l’accélération matérielle et empiré les choses »

Une autre société a déployé de nouvelles appliances edge et activé toutes les fonctionnalités d’accélération : checksum offload, GRO/LRO et une sorte de « VPN fast path » spécifique au vendeur. Les benchmarks de débit étaient excellents en labo.
En production, les appels VoIP sur le VPN ont commencé à perdre des mots. Le tunnel restait up et les transferts massifs étaient rapides, donc le problème a été attribué à « Teams qui fait son cinéma ».

L’indice est venu de la gigue. Sous charge modérée, la latence n’était pas élevée en moyenne, mais elle était extrêmement variable — micro‑rafales et regroupement de paquets. Les offloads coalesçaient les paquets et les livraient par paquets groupés. Les flux interactifs détestent les paquets groupés.

L’« optimisation » a amélioré la métrique que quelqu’un regardait (débit de pointe) et dégradé la métrique que les utilisateurs ressentent (stabilité de la latence). Désactiver certains offloads sur les interfaces WAN/VPN a réduit légèrement le débit mais a rendu la gigue acceptable. Le VoIP s’est stabilisé immédiatement.

Personne n’aime la conclusion : parfois vous achetez une voiture plus rapide et réalisez que vous ne conduisez qu’en embouteillage. Optimisez d’abord la stabilité de la latence. La bande passante est rarement le facteur limitant pour la douleur utilisateur sur VPN.

Pratique mais efficace qui a sauvé la situation : « Mesures temporelles avec journal des changements »

Une équipe globale avait une plainte récurrente : « Tous les mardis après‑midi le VPN est terrible. » Les gens avaient des théories :
maintenance du FAI, problèmes du cloud, éruptions solaires, et une suggestion mémorable impliquant un switch hanté.

Le SRE de garde a fait la chose la moins excitante possible. Il a mis en place des tests planifiés toutes les cinq minutes depuis un hôte filaire du bureau : ping et MTR vers la passerelle VPN, plus un court iperf3 vers un serveur de test interne. Ils ont stocké les sorties brutes horodatées et les ont alignées avec un journal des changements simple : modifications du circuit WAN, changements de politique firewall, upgrades d’équipements et événements locaux.

Après deux semaines, le schéma était clair. La perte et la gigue grimpaient en même temps chaque semaine, mais seulement en direction montante. Cela corrélait avec un job de sauvegarde hors site récurrent qui pilonnait l’upload. Le job n’était pas nouveau ; l’ensemble de données avait grandi et avait franchi le seuil où les files s’effondraient.

Ils ont déplacé la fenêtre de sauvegarde, limité le débit et mis en place un SQM basique. Les mardis après‑midi sont redevenus calmes. Le meilleur : ils n’avaient pas besoin d’actions héroïques, seulement des reçus. Les preuves ont aussi évité une escalade inutile au FAI qui aurait fini par « aucun problème trouvé ».

Blague 2 : La stratégie réseau la plus fiable est « mesurer d’abord ». La deuxième plus fiable est « arrêter de programmer des sauvegardes à 14h ».

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

Étape par étape : établir un test de qualité VPN reproductible

1. Choisir un client de test stable. Filaire, pas sur une station d’accueil avec une NIC USB instable.
   Si vous devez tester le Wi‑Fi, faites‑le intentionnellement et documentez que c’est du Wi‑Fi.
2. Choisir des cibles stables.
   Une cible publique : l’IP publique de la passerelle VPN. Une cible privée : un hôte interne accessible uniquement via le VPN.
3. Définir trois fenêtres de test.
   Calme du matin, heures de pointe et « l’heure de plainte » dont tout le monde parle.
4. Exécuter des tests de base.
   Ping passerelle (LAN), ping IP publique de la passerelle VPN, ping hôte interne via VPN, MTR vers la passerelle VPN, vérifs MTU.
5. Effectuer des tests de charge en courtes rafales.
   iperf3 avant et arrière pendant 15–30 secondes. Ne faites pas fondre les liens de production pendant des minutes.
6. Répéter et enregistrer les sorties brutes.
   Les captures d’écran ne sont pas des données. Conservez les sorties texte horodatées.
7. Corréler avec les métriques des équipements.
   CPU passerelle VPN, drops d’interface, utilisation WAN et compteurs de shaping/policing.
8. Prendre une décision.
   Si l’altération apparaît avant le tunnel (vers l’IP publique), escaladez vers le FAI. Si elle apparaît seulement à travers le tunnel,
   corrigez la configuration VPN ou le côté distant.

Checklist : avant d’appeler le FAI

• Confirmer que le problème se produit depuis un client filaire (sauf si le Wi‑Fi est la cause suspectée).
• Montrer la perte/gigue vers l’IP publique de la passerelle VPN sur la durée, pas un seul test.
• Fournir des sorties MTR vers le même endpoint pendant périodes bonnes et mauvaises.
• Fournir des preuves de latence sous charge si la congestion/bufferbloat est suspectée.
• Confirmer que le MTU fonctionne (ou documenter que vous l’avez ajusté) pour éviter que le FAI rejette votre overhead de tunnel.
• Documenter qui, où, quand : ID du circuit, emplacement du bureau, horodatages avec fuseau, et si les tests étaient via VPN.

Checklist : changements qui améliorent souvent la qualité VPN

• Activer ou corriger le SQM sur l’edge du bureau (ou shapez légèrement en dessous du débit FAI).
• Corriger le MTU/MSS pour le chemin VPN.
• Privilégier le filaire pour les utilisateurs VPN critiques ; corriger le roaming Wi‑Fi pour les autres.
• Surveiller le CPU et la pression d’interruption de la passerelle VPN durant les pics ; monter en capacité ou décharger si besoin.
• Séparer le trafic volumineux (sauvegardes, synchronisations larges) du trafic interactif avec du QoS.

Erreurs fréquentes : symptôme → cause racine → correction

• Symptôme : « Le VPN est lent, mais les tests de vitesse sont excellents. »
  Cause racine : Les tests de vitesse atteignent un CDN proche ; le trafic VPN emprunte un chemin différent, congestionné ou souffre de perte/gigue.
  Correction : Testez vers l’IP publique de la passerelle VPN et vers un hôte interne via le tunnel ; exécutez des tests aux heures de pointe et sous charge.
• Symptôme : « SSH fonctionne, mais les transferts de fichiers bloquent ; certaines applis expirent. »
  Cause racine : MTU/PMTUD blackhole dans le chemin VPN.
  Correction : Utilisez ping -M do avec des payloads plus grands, employez tracepath, puis réduisez le MTU du tunnel ou clampiez le MSS TCP en bordure.
• Symptôme : « Teams/VoIP saccade seulement quand des uploads ont lieu. »
  Cause racine : Bufferbloat ou saturation montante sur la liaison du bureau.
  Correction : Appliquez SQM/shaping pour l’ascendant ; déplacez les jobs volumineux hors heures d’activité ; imposez des limites de débit pour les sauvegardes.
• Symptôme : « MTR montre de la perte au saut 3 ; le FAI dit que tout va bien. »
  Cause racine : Limitation d’ICMP sur des routeurs intermédiaires ; pas nécessairement une perte en plan de données.
  Correction : Concentrez‑vous sur la perte/latence vers la destination finale ; corroborer avec les retransmissions iperf3 et les symptômes applicatifs.
• Symptôme : « Le débit VPN est mauvais sur un site ; ailleurs c’est correct. »
  Cause racine : Routage asymétrique, différences de peering ou impairment local du dernier kilomètre.
  Correction : Comparez MTR et ping depuis plusieurs sites vers le même endpoint VPN ; présentez le delta au FAI.
• Symptôme : « Les performances sont mauvaises après la mise à jour du firewall. »
  Cause racine : Limite de débit crypto, CPU trop petit, MTU mal dimensionné, ou offloads provoquant de la gigue.
  Correction : Mesurez le CPU et les drops d’interface sous charge ; réalisez des tests iperf3 multi‑flux ; désactivez les offloads problématiques ; montez la capacité de l’appliance.
• Symptôme : « Le VPN se déconnecte toutes les quelques minutes, surtout au repos. »
  Cause racine : Timeouts NAT, nettoyage agressif des états ou UDP mal traité.
  Correction : Activez le keepalive du tunnel ; ajustez les timeouts UDP du firewall/NAT ; confirmez que le FAI ne filtre pas UDP.
• Symptôme : « RDP lagge, mais le copy de fichiers en masse est correct. »
  Cause racine : Gigue et micro‑rafales ; regroupement/coalescence ; délais de mise en file qui n’impactent pas le débit.
  Correction : Mesurez la latence sous charge ; ajustez le SQM ; réduisez les offloads qui groupent les paquets ; priorisez le trafic interactif.
• Symptôme : « Tout est mauvais seulement sur le Wi‑Fi. »
  Cause racine : Interférences RF, problèmes de roaming, comportement power save ou mauvais positionnement des AP.
  Correction : Reproduisez en filaire ; si le filaire est propre, corrigez le Wi‑Fi — plan de canaux, RSSI minimum, steering de bandes et mises à jour de pilotes.
• Symptôme : « Nous voyons de la perte, mais seuls les pings petits réussissent de façon fiable. »
  Cause racine : Fragmentation/MTU ou policing qui abandonne les paquets plus gros sous charge.
  Correction : Effectuez des pings DF avec tailles croissantes ; ajustez MTU/MSS ; vérifiez qu’aucun policing n’est mal configuré sur les interfaces WAN/VPN.

Constituer un dossier de preuves solide pour le FAI

Les FAI ne répondent pas à « le VPN est lent. » Ils répondent à « voici la perte et la latence jusqu’à votre point de raccordement, voici la perte jusqu’à la destination, voici des horodatages, et voici une comparaison avec un chemin témoin. » Votre objectif n’est pas de gagner une dispute.
Votre objectif est d’obtenir un ticket routé vers quelqu’un qui peut changer quelque chose.

Ce qu’il faut collecter (reçus minimaux viables)

• Deux semaines de pings périodiques vers l’IP publique de la passerelle VPN (ou au moins plusieurs jours incluant les fenêtres « mauvaises »).
• Exécutions MTR pendant périodes bonnes et mauvaises vers l’IP publique de la passerelle VPN.
• Test de latence sous charge démontrant du bufferbloat (ping pendant iperf3) si la congestion est suspectée.
• Résultats iperf3 avant et arrière via le VPN pour montrer la directionnalité.
• Tests MTU montrant que votre tunnel est configuré sainement (pour que le FAI n’impute pas la fragmentation).
• Métriques du bord du bureau : utilisation WAN, drops d’interface, CPU de la passerelle VPN, horodatages alignés avec les plaintes utilisateurs.

Comment présenter pour obtenir une action

Restez concis. Facilitez la lecture. Les équipes FAI sont composées d’humains avec des files. Fournissez :
identifiant du circuit, IP publique, IP de la passerelle VPN, IP du client de test, horodatages avec fuseau, et une phrase d’impact (« trafic VPN interactif inutilisable 10:00–12:00 quotidiennement ; perte jusqu’à 1 % et pics RTT à 300 ms »).

Ensuite, joignez les sorties brutes. Les sorties brutes comptent car elles sont difficiles à contester et faciles à transférer en interne.
Aussi : incluez des échantillons « bons » et « mauvais ». Si vous ne montrez que des échecs, vous serez coincé dans la boucle « impossible à reproduire ».

Une posture pratique sur la recherche de responsabilité

Ne commencez pas par blâmer. Commencez par segmenter. « La perte est présente du bureau jusqu’à l’IP publique de la passerelle VPN ; le LAN est propre ;
les tests en sens inverse montrent une dégradation montante. » C’est ainsi que vous obtenez du FAI qu’il arrête de vous demander de redémarrer votre modem.

FAQ

1) Quelle est la différence entre latence et gigue, en termes simples ?

La latence est le temps qu’un paquet met pour effectuer un aller‑retour. La gigue est la variation de ce temps. Les humains détestent la gigue plus que la latence moyenne modérée.

2) Quelle quantité de perte de paquets est « acceptable » pour un VPN ?

Pour le travail interactif, visez pratiquement zéro. En pratique, moins de 0,1 % est généralement acceptable ; 0,5 % soutenu est perceptible ;
1 %+ provoquera des douleurs récurrentes et des tickets de support.

3) Le ping ICMP peut‑il induire en erreur ?

Oui. Certains réseaux limitent le débit ICMP ou le traitent différemment. C’est pourquoi vous corroborerez avec des tests de bout en bout comme
les retransmissions iperf3, la latence sous charge et le comportement applicatif. Néanmoins, ping reste utile lorsqu’il est utilisé avec soin.

4) Pourquoi le VPN s’aggrave‑t‑il pendant les appels vidéo ou les sauvegardes ?

Parce que vous remplissez les files d’attente. Sur beaucoup de liens de bureau, la bande montante est limitée et les buffers sont profonds. Une fois la file montante pleine, la latence explose. Le tunnel reste up ; l’expérience s’effondre.

5) Quel MTU dois‑je régler pour WireGuard ou IPsec ?

Il n’y a pas de numéro magique. Commencez autour du défaut courant de WireGuard (~1420), puis validez avec des pings DF et tracepath. Pour IPsec, l’overhead varie (NAT‑T, algorithmes). Mesurez, ne devinez pas.

6) Dois‑je exécuter iperf3 sur des liens de production pendant les heures de bureau ?

Oui, mais en courtes rafales contrôlées et avec avertissements. Un test de 15 secondes suffit généralement à révéler la directionnalité, les retransmissions et la gigue sous charge. Ne lancez pas un test de saturation de cinq minutes et soyez surpris quand les gens se plaignent.

7) Comment prouver que l’appliance VPN est le goulot, et non le FAI ?

Montrez des performances propres jusqu’à l’IP publique de la passerelle VPN mais des performances dégradées seulement à travers le tunnel. Corrélez ensuite avec le CPU de la passerelle VPN, les drops d’interface ou les compteurs d’offload crypto pendant la même fenêtre.

8) Notre FAI dit « aucun problème trouvé ». Et maintenant ?

Fournissez des preuves temporelles et segmentez le chemin. Incluez MTR/ping bons vs mauvais, la directionnalité (iperf3 avant vs inverse) et des résultats de latence sous charge. S’ils refusent encore, demandez une escalade vers le backbone/peering ou demandez un déplacement de circuit — poliment, avec des reçus.

9) Pourquoi je vois de la perte dans MTR sur un saut intermédiaire mais pas sur la destination ?

Ce saut peut limiter les réponses ICMP. Cela peut apparaître comme de la « perte » dans le rapport alors que le forwarding est correct.
Faites davantage confiance aux résultats de bout en bout qu’au comportement ICMP par saut.

10) Le Wi‑Fi est‑il vraiment si déterminant pour la qualité VPN ?

Oui. Les VPN amplifient les problèmes Wi‑Fi : retransmissions, interruptions de roaming et latence variable. Reproduisez toujours sur filaire avant d’escalader au FAI — sauf si la plainte est explicitement « Wi‑Fi + VPN ».

Conclusion : prochaines étapes qui font réellement bouger les choses

La qualité VPN n’est pas mystérieuse. Elle se mesure. L’astuce est de mesurer les bonnes choses, sur le bon segment du chemin, de façon à résister au rituel corporatif du « prouvez‑le ».

1. Définir des objectifs pour la latence, la gigue et la perte, et les consigner par écrit.
2. Instrumenter le chemin : pings/MTR planifiés vers le endpoint public du VPN et une cible interne privée.
3. Tester le MTU tôt ; corrigez‑le une fois pour toutes et arrêtez de retrouver le même problème chaque trimestre.
4. Mesurer sous charge pour exposer le bufferbloat et les problèmes de directionnalité.
5. Constituer un dossier de preuves avec horodatages et sorties brutes ; escalader par segmentation, pas par impressions.
6. Corriger le banal : SQM, shaping, jobs volumineux hors heures et dimensionnement sain de la passerelle VPN.

Faites cela, et la prochaine fois que quelqu’un dira « le VPN est lent », vous n’argumenterez pas. Vous montrerez un graphique, joindrez un log
et choisirez le bon levier — ticket FAI, shaping à la frontière, changement MTU ou montée en capacité VPN — en connaissance de cause.