VPN de bureau + VoIP : réduire la gigue et la latence sur les tunnels

Modèle mental : ce qu’un tunnel VPN fait à la voix

La VoIP est allergique à la variabilité. Pas seulement au délai — au délai variable. Les humains tolèrent bien mieux un délai constant de 80 ms qu’un pic irrégulier de 30–200 ms. Les tunnels VPN ont tendance à augmenter la variabilité pour trois raisons ennuyeuses :

• En‑têtes supplémentaires et chiffrement : plus d’octets par paquet, plus de CPU par paquet, et parfois un comportement différent des offloads NIC.
• Flux cachés : une fois le trafic chiffré, les appareils intermédiaires ne voient plus « ceci est du RTP » à moins que vous ne marquiez avant chiffrement et conserviez les marquages.
• Le placement des files change : vous pensez peut‑être que votre pare‑feu est le goulot d’étranglement ; en réalité, c’est souvent le CPE de l’ISP ou le shaper en amont où les paquets stagnent et pourrissent.

La voix (signalisation SIP + média RTP) utilise typiquement de petits paquets à cadence régulière. Les tunnels aiment la régularité aussi — jusqu’à ce que le lien du bureau soit saturé. Lorsqu’il y a saturation, les gros flux (stockage cloud, mises à jour, sauvegardes) créent des files. Ces files injectent de la gigue dans le RTP. Ensuite le jitter buffer tente de compenser, ajoute du délai, et quand il n’y arrive pas, l’audio est coupé.

Il existe une loi implacable du réseau de bureau : vous ne « corrigez pas la gigue » à l’intérieur du tunnel ; vous empêchez les files avant le goulot et vous priorisez la voix vers le tunnel. Cela signifie faire du shaping à la sortie du lien réellement contraint, et choisir une discipline d’ordonnancement qui ne pénalise pas les petits flux temps réel.

Une blague opérationnelle sèche, comme promis : les tunnels VPN sont comme des parapluies — les gens ne s’en souviennent que quand il pleut déjà et qu’ils sont déjà trempés.

Ce que cet article suppose (et ce qu’il ne suppose pas)

Hypothèses :

• Vous contrôlez un routeur/pare‑feu de bureau (Linux, pfSense/OPNsense, un pare‑feu d’un éditeur ou un routeur‑on‑a‑stick en VM).
• Les terminaux VoIP sont des postes fixes, softphones ou un SBC de PBX cloud, et le bureau tunnelise vers quelque chose (DC, cloud, passerelle de sécurité).
• Vous pouvez lancer des captures de paquets et des outils CLI basiques.

Non‑objectifs :

• Nous n’allons pas proposer « acheter un nouveau circuit WAN » comme solution primaire, même si parfois c’est la réponse adulte.
• Nous n’allons pas jouer au « QoS » sans prouver où se situe le goulot.

Faits et contexte intéressants (parce que l’histoire se répète dans les paquets)

1. La VoIP sur IP est devenue populaire bien avant que l’« internet de qualité » soit courant. Les premiers déploiements s’appuyaient fortement sur des jitter buffers parce que les accès étaient bruyants et congestionnés.
2. RTP est volontairement simple : il suppose que le réseau sera parfois mauvais, et les terminaux masquent cela avec du buffering et de la dissimulation de perte.
3. DiffServ (DSCP) date de la fin des années 1990 comme remplacement de l’ancien modèle IP Precedence. C’est toujours le langage principal de la QoS, même si beaucoup de réseaux l’ignorent.
4. IPsec ESP a été conçu pour la confidentialité, pas pour l’ingénierie du trafic. Le fait que l’on s’attende maintenant à ce qu’il préserve les marquages QoS est une adaptation opérationnelle, pas l’intention initiale.
5. Le terme bufferbloat date de 2009, mais le comportement existe depuis que le matériel grand public expédie des tampons profonds et non gérés.
6. FQ‑CoDel et CAKE sont nés de la douleur temps réel : joueurs et utilisateurs voix ont poussé des améliorations pratiques de la gestion des files, pas l’aboutissement académique.
7. SRTP (RTP sécurisé) chiffre les médias de bout en bout. Quand vous ajoutez un VPN par-dessus, vous doublez le chiffrement. Cela peut aller — sauf si votre équipement en bordure tient à une chandelle.
8. Les problèmes de MTU se sont aggravés avec les VPN sur le haut débit parce que PPPoE, balises VLAN et overhead des tunnels s’empilent comme des conteneurs.

À quoi ressemble une « bonne voix » : latence, gigue, perte et MOS

Pour réparer la VoIP sur VPN, vous avez besoin d’objectifs. Voici des valeurs pratiques utilisées en production :

• Latence unidirectionnelle : < 150 ms est généralement « bonne ». 150–250 ms est tolérable mais perceptible. Au‑dessus de 250 ms, les gens commencent à se marcher dessus.
• Gigue : gardez‑la < 20–30 ms pour une expérience confortable. On peut survivre à plus, mais le jitter buffer ajoutera du délai.
• Perte de paquets : maintenez‑la < 1 % pour un audio correct. Beaucoup de codecs peuvent masquer un peu de perte ; ils ne l’apprécient pas.
• Réordonnancement : de petites quantités sont acceptables. Certains artifices d’accélération WAN peuvent l’augmenter, et RTP déteste les surprises.

Le jitter buffer n’est pas une cure ; c’est un prêt

Les terminaux compensent la gigue en bufferisant. Ce tampon augmente la latence. Si vous « corrigez » la gigue en augmentant la taille du buffer, vous venez de déplacer la douleur de l’audio robotique à la conversation retardée. Parfois c’est le bon compromis — les centres d’appels préfèrent souvent un peu plus de délai plutôt que de la coupure — mais ce n’est pas gratuit.

MOS n’est pas non plus magique

MOS (Mean Opinion Score) est un modèle. Il est utile quand les tendances sont claires et qu’on ne le trompe pas. Si possible, mesurez directement la gigue/la perte ; traitez le MOS comme un proxy de satisfaction client, pas comme un moteur physique.

Une citation de fiabilité (idée paraphrasée), parce que les opérations ont leurs prophètes : Idée paraphrasée de Werner Vogels : tout échoue, tout le temps — concevez et exploitez comme si la défaillance était normale.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Premier : prouver où est le goulot

Avant de toucher aux boutons QoS, identifiez ce qui se sature :

1. Vérifiez l’utilisation et les erreurs de la liaison montante sur la vraie sortie WAN (l’appareil qui pousse les paquets vers l’ISP). Si vous shapez sur une interface interne, vous shapez probablement au mauvais endroit.
2. Vérifiez le bufferbloat : la latence sous charge est la vérité. Si les temps de ping augmentent de 10x pendant un upload, vous avez trouvé votre usine à gigue.
3. Vérifiez le CPU de l’extrémité VPN : le traitement des paquets chiffrés est souvent limité à un seul cœur. Un tunnel peut être « up » pendant que la machine fond silencieusement.

Second : valider MTU et fragmentation bout en bout

Si vous avez de la fragmentation, des blackholes PMTUD ou des problèmes MSS, la voix échouera de façons qui ressemblent à une « gigue aléatoire ». Ce n’est pas aléatoire ; ce sont des paquets retardés, fragmentés ou perdus.

Troisième : assurer que la voix est classée correctement avant chiffrement

La voix doit être identifiée et priorisée avant de disparaître dans un tunnel. Ensuite vous devez soit :

• Préserver DSCP dans l’en‑tête externe du tunnel, ou
• Classifier au point de terminaison du tunnel et appliquer shaping/ordonnancement là‑bas.

Quatrième : corriger l’ordonnancement avec des disciplines modernes (FQ‑CoDel/CAKE)

Les files à priorité classique peuvent aider, mais elles peuvent aussi affamer tout le reste et créer des rafales bizarres. Pour les liens de bureau, CAKE ou FQ‑CoDel avec un shaping raisonnable est généralement la solution « qui marche le lundi matin ».

Cinquième : n’ajustez le terminal et le PBX qu’après

La sélection de codecs, le temps de paquetisation (ptime), le jitter buffer et les timers SIP comptent — mais ils ne peuvent pas réparer un uplink saturé avec de mauvaises files.

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

Ces tâches sont écrites pour une passerelle VPN basée sur Linux. Si vous êtes sur un appliance, les concepts restent ; seules les commandes deviennent spécifiques au fournisseur.

Tâche 1 : identifier la vraie interface WAN et son type de lien

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
ens18            UP             52:54:00:aa:bb:cc <BROADCAST,MULTICAST,UP,LOWER_UP>
ppp0             UNKNOWN        00:11:22:33:44:55 <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP>
wg0              UNKNOWN        9a:bc:de:f0:12:34 <POINTOPOINT,NOARP,UP,LOWER_UP>

Ce que cela signifie : Vous pouvez être sur PPPoE (ppp0) sans réaliser que vous shapez la mauvaise interface (ens18). PPP ajoute de l’overhead et a un comportement MTU différent.

Décision : Appliquez shaping/QoS sur la vraie sortie WAN (souvent ppp0). Si vous shapez ens18 mais que le goulot réel est ppp0 ou le modem ISP, vous faites juste de la danse interprétative.

Tâche 2 : vérifier les stats de l’interface VPN pour erreurs et paquets perdus

cr0x@server:~$ ip -s link show dev wg0
4: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
      987654321  123456      0      12       0       0
    TX:  bytes packets errors dropped carrier collsns
      876543210  120000      0       0       0       0

Ce que cela signifie : Des RX dropped peuvent indiquer un débordement de file côté réception, une contention CPU, ou une pression au niveau noyau. Pour WireGuard, les drops sont souvent dus à une congestion en aval ou à du policing ailleurs.

Décision : Si les drops augmentent pendant les appels, ne touchez pas d’abord au PBX. Réparez la congestion/l’ordonnancement et vérifiez CPU et shaping.

Tâche 3 : mesurer la latence sous charge (test bufferbloat à lancer maintenant)

cr0x@server:~$ ping -i 0.2 -c 30 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=56 time=12.3 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=13.1 ms
...
--- 1.1.1.1 ping statistics ---
30 packets transmitted, 30 received, 0% packet loss, time 6008ms
rtt min/avg/max/mdev = 11.9/12.8/14.6/0.6 ms

Ce que cela signifie : Le baseline semble stable. Recommencez pendant que vous saturez l’upload (par ex. un speedtest depuis un poste ou un iperf contrôlé). Si le max bondit à 200–800 ms, vous avez du bufferbloat.

Décision : Si la latence sous charge explose, votre première correction est le shaping + AQM moderne (CAKE/FQ‑CoDel), pas « changer les codecs ».

Tâche 4 : confirmer le qdisc actuel sur la sortie WAN

cr0x@server:~$ tc qdisc show dev ppp0
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

Ce que cela signifie : pfifo_fast est ancien et généralement mauvais avec du trafic mixte. Il ne gère pas activement la latence.

Décision : Remplacez par CAKE ou FQ‑CoDel + shaping. Si vous ne pouvez pas, vous lutterez éternellement contre les symptômes.

Tâche 5 : installer le shaping CAKE (exemple) et vérifier qu’il est actif

cr0x@server:~$ sudo tc qdisc replace dev ppp0 root cake bandwidth 80Mbit diffserv4 nat nowash ack-filter
cr0x@server:~$ tc -s qdisc show dev ppp0
qdisc cake 8001: root refcnt 2 bandwidth 80Mbit diffserv4 nat nowash ack-filter
 Sent 123456789 bytes 234567 pkt (dropped 123, overlimits 456 requeues 0)
 backlog 0b 0p requeues 0

Ce que cela signifie : CAKE shape à 80 Mbit et applique des niveaux DiffServ. Quelques drops sont normaux ; ils doivent se produire chez votre shaper, pas en amont dans un tampon géant de l’ISP.

Décision : Réglez la bande passante légèrement en dessous du débit réel (souvent 85–95 %). Puis retestez la qualité des appels sous charge. Si ça s’améliore fortement, vous avez trouvé le coupable principal.

Tâche 6 : observer le DSCP du RTP entrant avant qu’il n’entre dans le tunnel

cr0x@server:~$ sudo tcpdump -ni ens18 -vv 'udp and (port 5060 or portrange 10000-20000)' -c 5
tcpdump: listening on ens18, link-type EN10MB (Ethernet), snapshot length 262144 bytes
IP (tos 0xb8, ttl 64, id 12345, offset 0, flags [DF], proto UDP (17), length 214)
    10.10.20.50.40012 > 198.51.100.10.16432: UDP, length 172
IP (tos 0x00, ttl 64, id 12346, offset 0, flags [DF], proto UDP (17), length 498)
    10.10.20.50.5060 > 198.51.100.10.5060: SIP, length 456

Ce que cela signifie : Le RTP marqué DSCP EF (0xb8) est idéal. Le SIP reste souvent best‑effort (0x00), ce qui est acceptable ; le média importe davantage.

Décision : Si le RTP n’est pas marqué, décidez de marquer au téléphone, au switch d’accès/AP, ou à la passerelle (table mangle). Marquer à la périphérie est plus propre.

Tâche 7 : vérifier si le DSCP survit à l’intérieur du tunnel (en‑tête externe)

cr0x@server:~$ sudo tcpdump -ni ppp0 -vv 'udp and host 203.0.113.20' -c 3
tcpdump: listening on ppp0, link-type LINUX_SLL2, snapshot length 262144 bytes
IP (tos 0x00, ttl 64, id 54321, offset 0, flags [DF], proto UDP (17), length 148)
    192.0.2.10.51820 > 203.0.113.20.51820: UDP, length 96

Ce que cela signifie : Les paquets externes du tunnel sont best‑effort (tos 0x00). C’est courant : l’encapsulation n’a pas copié le DSCP interne vers l’externe.

Décision : Si votre QoS WAN dépend du DSCP, vous devrez peut‑être copier le DSCP (là où c’est supporté) ou classifier le trafic sur le point de terminaison du tunnel et y faire le shaping. Sinon, votre ISP voit un seul flux homogène et traite la voix comme des vidéos de chats.

Tâche 8 : vérifier le MTU du tunnel et détecter le risque de fragmentation

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

Ce que cela signifie : 1420 est un MTU WireGuard courant. Si votre LAN est à 1500 et que vous ne clampiez pas MSS pour TCP, vous verrez de la fragmentation pour les gros paquets. Le RTP est petit, mais le SIP/TLS et « autre trafic pendant un appel » peuvent toujours déclencher de la file et des retransmissions.

Décision : Si vous suspectez un problème MTU, clamppez MSS pour TCP et validez PMTUD. Ne devinez pas.

Tâche 9 : test PMTU avec un ping « do not fragment »

cr0x@server:~$ ping -M do -s 1372 -c 3 203.0.113.20
PING 203.0.113.20 (203.0.113.20) 1372(1400) bytes of data.
1400 bytes from 203.0.113.20: icmp_seq=1 ttl=57 time=23.1 ms
1400 bytes from 203.0.113.20: icmp_seq=2 ttl=57 time=23.4 ms
1400 bytes from 203.0.113.20: icmp_seq=3 ttl=57 time=23.0 ms

--- 203.0.113.20 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 23.0/23.1/23.4/0.2 ms

Ce que cela signifie : Les paquets de 1400 octets avec DF réussissent. Augmentez la taille jusqu’à échec pour trouver la vraie marge PMTU.

Décision : Si même des pings DF modestes échouent, vous avez probablement un blackhole PMTUD. Corrigez MTU/MSS et assurez‑vous que les ICMP « frag needed » ne sont pas bloqués.

Tâche 10 : clamp MSS pour TCP afin d’éviter la fragmentation via le tunnel

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

Ce que cela signifie : Cela empêche les sessions TCP d’essayer d’envoyer des segments trop grands pour le tunnel, réduisant la fragmentation et les retransmissions qui peuvent indirectement aggraver la gigue sous charge.

Décision : Conservez‑le sauf raison très spécifique de ne pas le faire. C’est une des garde‑fous « ennuyeux et corrects ».

Tâche 11 : vérifier la saturation CPU du point de terminaison VPN pendant les appels

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

12:10:01 AM  CPU   %usr %nice %sys %iowait %irq %soft %steal %idle
12:10:02 AM  all   22.0  0.0  11.0    0.0  0.0  20.0    0.0  47.0
12:10:02 AM    0   18.0  0.0   9.0    0.0  0.0  42.0    0.0  31.0
12:10:02 AM    1   25.0  0.0  12.0    0.0  0.0  18.0    0.0  45.0
12:10:02 AM    2   23.0  0.0  11.0    0.0  0.0  15.0    0.0  51.0
12:10:02 AM    3   22.0  0.0  12.0    0.0  0.0   5.0    0.0  61.0

Ce que cela signifie : Un %soft élevé sur un cœur peut indiquer un goulot de traitement des paquets (softirq). Le chiffrement et l’encapsulation VPN peuvent être collés à un cœur selon le pilote/queueing.

Décision : Si un cœur est constamment saturé pendant les pics, optimisez le chemin CPU (NIC RSS, affinité IRQ), choisissez un chiffrement plus rapide, utilisez du matériel ou réduisez le nombre de paquets via un ptime plus grand si acceptable.

Tâche 12 : observer la pression softirq (traitement réseau) et les paquets perdus

cr0x@server:~$ cat /proc/softirqs | egrep 'NET_RX|NET_TX'
NET_TX:     1020304   993322   880011   770022
NET_RX:     9090909  8888888  7777777  6666666

Ce que cela signifie : Un NET_RX important et rapidement croissant sur un CPU peut corréler avec la gigue lorsque le système est surchargé et que les paquets attendent leur tour.

Décision : Si corrélé avec de mauvais appels, réduisez le taux de paquets (packetization codec), scalez le CPU, ou ajustez IRQ/RPS/RFS pour répartir le travail.

Tâche 13 : vérifier la perte et la gigue RTP avec une capture sur la passerelle

cr0x@server:~$ sudo tshark -ni ens18 -f "udp portrange 10000-20000" -c 50 -q -z rtp,streams
Running as user "root" and group "root". This could be dangerous.
========================= RTP Streams =========================
Start time  End time  Src IP       Src port  Dst IP       Dst port  SSRC        Payload  Packets  Lost  Max Jitter
0.000000    9.842000  10.10.20.50  40012     198.51.100.10 16432   0x1a2b3c4d  111      400      3     14.7 ms
===============================================================

Ce que cela signifie : Vous observez une perte et une gigue RTP réelles (telles qu’observées au point de capture). Quelques paquets perdus peuvent être acceptables ; une perte soutenue corrèle avec des artefacts audibles.

Décision : Si la perte survient avant l’encapsulation du tunnel, réparez le LAN/Wi‑Fi. Si la perte survient après encapsulation (capture côté WAN), réparez le shaping WAN/chemin ISP/point de terminaison du tunnel.

Tâche 14 : vérifier la pression conntrack (saturation de la table NAT peut ressembler à de la « gigue »)

cr0x@server:~$ sudo sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
net.netfilter.nf_conntrack_count = 24789
net.netfilter.nf_conntrack_max = 262144

Ce que cela signifie : Beaucoup de marge disponible. Si le count est proche du max, les nouveaux flux sont drop/evictés, ce qui peut casser SIP/RTP de façon étrange.

Décision : Si proche du max pendant les heures de bureau, augmentez conntrack_max et/ou réduisez le churn NAT inutile (flux courts, timeouts mal configurés, appareils bavards).

Tâche 15 : confirmer que les timeouts RTP/SIP ne sont pas tués par des défauts du pare‑feu

cr0x@server:~$ sudo sysctl net.netfilter.nf_conntrack_udp_timeout net.netfilter.nf_conntrack_udp_timeout_stream
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180

Ce que cela signifie : Si ces valeurs sont trop basses pour votre environnement, les flux RTP peuvent être supprimés en plein appel lors d’un bref silence ou d’une danse de re‑INVITE.

Décision : Si vous observez une audio unidirectionnelle en milieu d’appel après ~30 secondes de silence, augmentez les timeouts UDP ou assurez‑vous que des keepalives sont configurés.

Conseils spécifiques aux tunnels : IPsec, WireGuard, OpenVPN

IPsec (IKEv2/ESP) : robuste, courant, et facile à mal‑QoSer

IPsec est un cheval de travail. Il aime aussi rendre votre QoS invisible si vous ne la préservez pas délibérément.

• L’encapsulation ESP cache les ports, donc « prioriser UDP 10000–20000 » n’aide pas côté WAN ; tout devient ESP.
• La copie DSCP n’est pas automatique partout. Certains stacks copient le DSCP interne vers l’externe ; d’autres ne le font pas ; certains le font jusqu’à activation du NAT‑T.
• NAT‑T (encapsulation UDP) ajoute un autre en‑tête et peut modifier MTU et dynamique de fragmentation.

Que faire : priorisez le trafic avant chiffrement, puis assurez‑vous que le point de terminaison VPN utilise cela pour ordonnancer les paquets dans le tunnel. Si vous faites de la QoS en aval (gérée par l’ISP), vous devrez préserver le DSCP externe et le vérifier par captures.

WireGuard : léger, rapide, mais pas magique

La simplicité de WireGuard est opérationnellement séduisante. Mais il ne résout pas automatiquement la gigue ; il gaspille simplement moins de cycles CPU que certains anciens designs.

• Les choix MTU par défaut comptent. 1420 est courant ; votre environnement peut nécessiter ~1380 si vous empilez PPPoE/VLAN.
• Problème du flux UDP unique : pour l’ISP c’est un seul flux à moins que vous ne shapiez intelligemment. Vous devez appliquer un fair queueing de votre côté.
• Marquage : le DSCP des paquets internes ne devient pas automatiquement le DSCP de l’UDP externe 51820.

OpenVPN : flexible, parfois plus lourd qu’on le pense

OpenVPN peut convenir parfaitement pour la VoIP. Il peut aussi devenir générateur de gigue si vous l’exécutez en espace utilisateur sur un CPU modeste et que vous poussez beaucoup de petits paquets.

• Le mode UDP est généralement le bon choix pour la VoIP. Le mode TCP peut amplifier la latence à cause des retransmissions (« TCP meltdown »).
• Le surcoût en espace utilisateur peut être visible comme de la gigue pendant les rafales de trafic.
• La compression est un piège dans les setups modernes : souvent un risque de sécurité et source de gigue CPU accrue.

QoS et shaping qui fonctionnent réellement sur les tunnels

Commencez par le shaping, pas par la « priorité »

Si vous ne faites rien d’autre : shapez la sortie egress juste en dessous du vrai débit WAN et utilisez CAKE. Cela force la mise en file chez vous (où vous la contrôlez) plutôt que dans le mystérieux tampon de l’ISP (où vous n’avez pas la main).

Pourquoi cela aide la VoIP sur VPN :

• Les paquets RTP restent petits et fréquents ; le fair queueing leur donne des tours réguliers.
• Les gros uploads sont étalés au lieu de créer une file géante.
• La latence sous charge devient prévisible, ce dont les jitter buffers ont besoin.

Classification : marquer avant chiffrement, puis ordonnancer dans le tunnel

Il y a deux modèles viables :

1. Classification interne + shaping conscient du tunnel : classifiez RTP/SIP sur l’interface LAN puis shapez sur le WAN en vous basant sur des firewall marks. Cela évite d’avoir à compter sur le DSCP externe.
2. DSCP de bout en bout : marquez RTP EF et assurez‑vous que le tunnel copie le DSCP dans l’en‑tête externe pour que les équipements en aval puissent l’honorer. C’est plus propre quand ça marche. Souvent ça ne marche pas à moins de le configurer explicitement.

N’en faites pas trop avec la priorité

Beaucoup de guides QoS recommandent une file à priorité stricte pour la voix. C’est acceptable si le volume voix est modeste et la classification correcte. Dans un vrai bureau, la mauvaise classification arrive, et une priorité stricte peut affamer DNS, ACKs et trafic de contrôle — causant une sorte d’autopanne étrange où la voix est cristalline et tout le reste s’effondre.

Deuxième blague courte (et c’est le quota) : la QoS à priorité stricte, c’est comme donner à un collègue la seule clé de la salle de réunion ; la réunion est efficace jusqu’à ce que les autres commencent à crocheter la serrure.

Rendez‑le mesurable : la latence sous charge comme KPI

Votre meilleur « avant/après » n’est pas le MOS d’un seul téléphone. C’est la latence ping sous charge plus la perte/gigue RTP depuis des captures à des points clés. Si le shaping marche, le ping sous charge s’améliore nettement et la gigue RTP se stabilise.

MTU, MSS, fragmentation : le tueur silencieux de la voix

Pourquoi les problèmes MTU apparaissent comme de la « gigue »

La fragmentation ne fait pas toujours perdre des paquets, mais elle augmente la variabilité. Des fragments peuvent suivre des chemins différents, être mis en file différemment, ou être supprimés sélectivement. Si vous êtes malchanceux, la PMTUD casse et les gros paquets sont blackholés ; alors les retransmissions TCP inondent le lien et le flux voix subit des dégâts collatéraux.

Stacks MTU courants en bureaux

• Ethernet : 1500
• PPPoE : typiquement 1492
• Overhead de balise VLAN : réduit l’espace utile sauf si jumbo frames de bout en bout
• WireGuard : souvent ~1420
• IPsec ESP/NAT‑T : variable ; peut réduire substantiellement le MTU effectif

Règles pratiques

• Clampez le MSS pour TCP vers le tunnel pour prévenir les tempêtes de fragmentation.
• Autorisez les ICMP essentiels (frag‑needed, time‑exceeded). Les bloquer, c’est supprimer les panneaux de signalisation et blâmer les conducteurs pour leurs retards.
• Fixez délibérément le MTU du tunnel. L’auto n’est pas forcément mauvais, mais « pas mal » n’est pas une stratégie quand le PDG entend des robots.

Wi‑Fi et problèmes de dernière‑mile que vous attribuez au « VPN »

Le Wi‑Fi introduit de la gigue par conception

Le Wi‑Fi est basé sur la contention. Les clients se passent le canal, retransmettent et adaptent le débit. C’est étonnant que la VoIP fonctionne dessus, et la raison est que la voix est faible en bande passante. Mais faible bande passante ne veut pas dire faible sensibilité.

Si vos téléphones de bureau sont en Wi‑Fi :

• Privilégiez le 5 GHz (ou le 6 GHz si disponible) pour moins d’interférences.
• Activez WMM (Wi‑Fi Multimedia) et mappez correctement le DSCP aux catégories d’accès WMM.
• Surveillez les « clients collants » sur des AP lointains provoquant des retries et une consommation d’airtime anormale.

Asymétrie de dernière‑mile et policing

Beaucoup de liaisons haut débit sont asymétriques en upload. La VoIP est bidirectionnelle ; la montée a souvent plus d’importance car c’est là que le bureau envoie le RTP au fournisseur, et où les sauvegardes et synchronisations cloud peuvent saturer.

De plus : les ISP peuvent parfois policer le trafic d’une manière qui cause des micro‑paquets perdus. Votre shaper doit lisser les rafales avant qu’elles n’atteignent le modem. Si vous ne shapez pas, l’ISP le fera pour vous — mal.

Trois mini‑histoires d’entreprise (douleur, regret et succès ennuyeux)

1) L’incident causé par une mauvaise hypothèse

Ils ont migré des téléphones vers un PBX cloud et ont conservé le site‑to‑site VPN parce que « la sécurité exige tout via le siège ». Le plan de migration supposait que la voix était « juste un autre flux UDP », et comme les graphes de bande passante semblaient corrects, personne ne s’est inquiété.

La première semaine en production, les cadres ont commencé à signaler que les appels étaient parfaits tôt le matin et inutilisables à 10h30. Ce schéma criait « congestion », mais le NOC regardait l’utilisation moyenne et ne voyait rien d’alarmant — parce que les moyennes sont le mensonge que vos graphes racontent pour vous calmer.

Une capture côté LAN montrait le RTP marqué EF. Une capture côté WAN montrait les paquets du tunnel tous best‑effort. Le pare‑feu du siège avait une belle politique QoS pour les ports voix, mais une fois les paquets entrés en IPsec, ils étaient devenus ESP. La politique ne correspondait plus. La voix était mise en file derrière une vague du sync cloud et un cycle de mises à jour hebdomadaire.

La correction n’était pas exotique : shapez l’uplink du siège avec CAKE, classifiez la voix avant chiffrement, et ordonnancez‑la dans une tier supérieure. Une fois la file déplacée de l’ISP vers leur shaper contrôlé, la gigue s’est aplatie et les appels se sont stabilisés. L’hypothèse erronée était « nous avons déjà la QoS » parce que la config existait. Le réseau ne s’est pas soucié de la config ; il s’est soucié de l’endroit où les paquets faisaient réellement la queue.

2) L’optimisation qui s’est retournée contre eux

Une autre entreprise avait une petite antenne avec un pare‑feu modeste. La VoIP sur VPN était limite pendant les périodes chargées, alors quelqu’un a « optimisé » en activant le coalescing agressif de paquets et les offloads, plus un profil performance qui a augmenté la modulation d’interruptions pour réduire l’usage CPU.

Les graphes CPU du pare‑feu semblaient meilleurs immédiatement. L’équipe a célébré. Puis le helpdesk a reçu une nouvelle catégorie de plaintes : « Les gens ont l’air d’être sous l’eau » et « Toutes les quelques secondes l’audio saute ». Cela ne corrélait pas avec la bande passante ; cela corrélait avec des rafales de trafic.

Ce qui s’est passé : la modulation d’interruptions et le coalescing ont augmenté la variance de latence. Les paquets n’étaient plus traités régulièrement ; ils arrivaient par paquets. Le RTP préfère un métronome. Il a eu du jazz. De plus, certains offloads interagissaient mal avec le trafic encapsulé, augmentant les retransmissions sur d’autres flux, qui ont créé plus de rafales. Une boucle de rétroaction parfaite — comme un écho, mais pour de mauvaises décisions.

Ils ont annulé le tuning « performance », puis ont utilisé du shaping pour limiter le WAN légèrement en dessous du débit ligne. Le CPU est monté, mais la qualité des appels s’est stabilisée. La leçon : optimiser pour le CPU moyen peut aggraver la latence en queue. La VoIP vit dans les queues.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise

Un dernier : une société avec des dizaines de petits sites faisait de la VoIP sur WireGuard vers un hub régional. Rien de fancy. Mais ils avaient l’habitude peu glamour : chaque nouveau site passait un « test d’acceptation voix » standardisé dès le premier jour.

Le test incluait un ping sous charge, un balayage MTU DF‑ping, et un court flux RTP synthétique mesuré au hub. Ils stockaient les résultats par site et les comparaient au baseline. C’était si routinier qu’un technicien junior pouvait l’exécuter sans improvisation.

Un site a commencé à avoir des problèmes intermittents après un remplacement de matériel ISP. L’ISP insistait que la ligne était OK. L’équipe a relancé le test d’acceptation et a vu tout de suite la latence sous charge passer de « stable » à « montagnes russes ». Le balayage MTU montrait aussi une PMTU réduite. Ils n’avaient rien changé en interne.

Parce qu’ils avaient des données baseline, ils n’ont pas discuté sur des impressions. Ils ont présenté des preuves mesurées, ajusté leur shaper et le MTU du tunnel temporairement, et poussé l’ISP à corriger la provision. Les appels se sont améliorés le jour même. La pratique n’était pas glamour. Elle était correcte. Elle a fait gagner du temps et évité la réunion sans fin où quelqu’un dit « mais ça marchait l’année dernière ».

Erreurs courantes : symptôme → cause racine → correction

1) Symptom : les appels vont bien jusqu’à ce que quelqu’un téléverse un gros fichier

Cause racine : bufferbloat sur l’uplink ; la mise en file se produit dans le modem/ISP, pas sous votre contrôle.

Correction : shapez la sortie egress sous le débit ligne réel sur la vraie interface WAN (CAKE/FQ‑CoDel). Validez via un ping sous charge.

2) Symptom : audio unidirectionnel, surtout après une minute de silence

Cause racine : timeouts NAT/conntrack UDP trop bas ; les mappages SIP/RTP expirent.

Correction : augmentez les timeouts UDP, activez les keepalives SIP/RTP si possibles, et assurez une routage symétrique.

3) Symptom : audio robotique avec brefs saccades périodiques, même quand la bande passante est faible

Cause racine : goulot CPU/softirq sur la passerelle VPN, souvent saturation mono‑coeur, ou modulation d’interruptions agressive rendant le traitement rafaleux.

Correction : vérifiez le CPU par cœur et les softirq. Ajustez IRQ/RSS, réduisez le taux de paquets (ptime codec), ou upgradez le matériel. Annulez les offloads « hostiles à la latence ».

4) Symptom : drops aléatoires en activant le VPN, surtout pour certaines applications

Cause racine : problèmes MTU/PMTUD ; ICMP frag‑needed bloqué ; fragmentation ou blackholing.

Correction : validez la PMTU avec des pings DF ; clampz MSS ; autorisez ICMP ; fixez le MTU du tunnel délibérément.

5) Symptom : QoS configurée, mais la voix reste mauvaise sur VPN

Cause racine : vous matchiez sur des ports internes qui sont cachés après chiffrement ; ou le DSCP ne copie pas vers l’en‑tête externe.

Correction : classifiez avant chiffrement en utilisant des marks, shapez sur le WAN avec ces marks ; ou configurez la copie DSCP et vérifiez par captures.

6) Symptom : la gigue n’affecte que les utilisateurs Wi‑Fi, les postes filaires sont OK

Cause racine : retries Wi‑Fi, interférences, contention airtime, absence de mapping WMM/DSCP‑to‑WMM.

Correction : imposez l’utilisation du 5/6 GHz, optimisez les AP, activez WMM, réduisez les retries, et envisagez un SSID/VLAN dédié pour la voix.

7) Symptom : le VPN « fonctionne », mais l’établissement d’appel est lent ou échoue de façon intermittente

Cause racine : SIP ALG ou fonctions « utiles » du pare‑feu réécrivant SIP ; ou routage asymétrique entre plusieurs WAN.

Correction : désactivez SIP ALG sauf si vous en avez besoin démontrablement ; assurez un chemin cohérent pour la signalisation et le média ; utilisez un SBC si l’architecture l’exige.

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

Étape par étape : stabiliser la voix sur un VPN en bureau

1. Cartographiez le chemin du trafic : où est le point de terminaison VPN, où se fait le NAT, où est le véritable goulot (egress WAN) ? Écrivez‑le.
2. Mesurez le baseline : ping vers une cible externe stable ; capturez les stats RTP à la passerelle ; notez les symptômes d’appel et les heures.
3. Réalisez un test latence sous charge : saturez l’upload brièvement ; observez le max et la gigue du ping. Si ça explose, arrêtez de blâmer « le PBX ».
4. Installez du shaping sur l’egress WAN : commencez avec CAKE à 85–95 % du up/down réel. Retestez sous charge.
5. Classifiez la voix : marquez RTP EF (ou équivalent) à la périphérie ; assurez‑vous que le shaper respecte cela. Si vous ne pouvez pas préserver DSCP dans le tunnel, utilisez des marks firewall.
6. Corrigez MTU/MSS : balayage DF‑ping, clamp MSS, autorisez les ICMP nécessaires, ajustez le MTU du tunnel si besoin.
7. Vérifiez la marge CPU : surveillez CPU par cœur et softirq pendant des appels concurrents + charge. Si vous êtes CPU bound, aucune politique QoS ne vous sauvera.
8. Validez le Wi‑Fi séparément : si seul le Wi‑Fi casse, traitez‑le comme un problème Wi‑Fi. Les tests filaires sont votre groupe contrôle.
9. Verrouillez le monitoring : suivez latence sous charge, drops de tunnel, drops qdisc, et gigue/perte RTP. Trendez‑les. Rendez‑les ennuyeux.

Checklist opérationnelle : avant de changer quoi que ce soit en plein incident

• Capturez 30 secondes de trafic côté LAN et côté WAN (ou interface tunnel) pendant un mauvais appel.
• Vérifiez les stats qdisc et les drops d’interface.
• Vérifiez le CPU par cœur et les softirq.
• Confirmez si l’uplink se sature (pas la moyenne ; les pics actuels).
• Confirmez si le DSCP est présent sur le RTP et s’il survit à l’encapsulation.
• Lancez un ping DF avec quelques tailles pour détecter des régressions PMTU.

FAQ

1) Un VPN rend‑il intrinsèquement la VoIP mauvaise ?

Non. Un VPN ajoute de l’overhead et peut cacher le trafic pour la QoS, mais le tueur habituel est la mise en file induite par la congestion et la mauvaise gestion des files. Réparez cela et la VoIP peut très bien fonctionner sur un tunnel.

2) Dois‑je faire passer la VoIP en dehors du VPN pour « régler » le problème ?

Parfois c’est une architecture valide, surtout avec un PBX cloud et SRTP/TLS déjà en place. Mais ne l’utilisez pas comme contournement du bufferbloat que vous aurez toujours pour tout le reste.

3) Qu’est‑ce qui compte le plus : latence ou gigue ?

Pour la qualité audio, la gigue est souvent ce que les utilisateurs perçoivent comme du « haché ». Pour le confort de conversation, la latence compte davantage. En pratique, ils sont liés : les jitter buffers échangent gigue contre latence.

4) Le DSCP vaut‑il le coup sur l’internet public ?

Sur l’internet ouvert, le DSCP est incohérent. À l’intérieur de votre bureau et sur votre bord contrôlé, il vaut absolument le coup car il informe votre shaper et le mapping WMM Wi‑Fi. Considérez l’honneur côté ISP comme un bonus, pas une dépendance.

5) Quel est le meilleur changement unique pour la VoIP de bureau sur VPN ?

Shapez l’egress WAN avec CAKE (ou FQ‑CoDel) à une limite de bande réaliste, puis vérifiez que la latence sous charge s’améliore. Ce n’est pas glamour. C’est efficace.

6) Pourquoi mes graphes montrent‑ils une faible utilisation mais les appels bégayent quand même ?

Parce que les moyennes cachent les micro‑rafales et la mise en file. La voix échoue sur la variabilité à l’échelle milliseconde. Regardez la latence max sous charge, les drops d’interface et le backlog qdisc — pas seulement les moyennes sur 5 minutes.

7) Dois‑je changer de codec pour réparer la gigue ?

Le choix du codec peut aider (certains tolèrent mieux la perte), et le ptime affecte le taux de paquets. Mais si vos files uplink sont le problème, changer de codec n’est qu’un pansement. Réparez d’abord le réseau, puis optimisez les codecs si nécessaire.

8) Un VPN basé sur TCP (ou SIP sur TCP) est‑il une bonne idée ?

Pour le média (RTP), non — utilisez UDP. Pour la signalisation SIP, TCP/TLS est acceptable. Mais le tunneling basé sur TCP pour tout peut amplifier la latence en cas de perte à cause des retransmissions et du head‑of‑line blocking.

9) Et si le point de terminaison VPN est dans le cloud, pas au bureau ?

Vous devez quand même faire du shaping à l’egress WAN du bureau. Le shaping côté cloud ne règle pas la file d’attente uplink du bureau. Vous pouvez aussi ajouter shaping/ordonnancement côté cloud pour protéger l’aval, mais le premier goulot est généralement l’uplink de la succursale.

10) Comment savoir si le problème vient de l’ISP ou de mon équipement ?

Si le shaping sur votre passerelle améliore fortement la latence sous charge, le chemin ISP peut être correct ; votre emplacement de mise en file précédent était mauvais. Si vous voyez toujours perte/gigue après shaping et que le CPU est sain, collectez des captures et poussez l’ISP avec des preuves (changements PMTU, motifs de perte, corrélation horaire).

Conclusion : prochaines étapes réalisables cette semaine

Si votre bureau fait transiter la VoIP par un tunnel VPN et que la qualité est incohérente, arrêtez de débattre et commencez à mesurer. La correction est généralement un petit ensemble de contrôles ennuyeux :

1. Réalisez des tests latence sous charge et prouvez le bufferbloat (ou excluez‑le).
2. Shapez la vraie sortie WAN avec CAKE ou FQ‑CoDel, légèrement en dessous du débit réel.
3. Classifiez la voix avant chiffrement ; ne supposez pas que les règles QoS s’appliquent une fois le trafic devenu « juste un tunnel ».
4. Validez MTU/PMTU et clampz MSS pour éviter le chaos induit par la fragmentation.
5. Vérifiez le CPU/softirq du point de terminaison VPN et annulez les « optimisations » qui augmentent la latence en queue.

Faites cela, et la VoIP sur VPN deviendra ennuyeuse — ce qui est le plus grand compliment qu’un SRE puisse faire à un système en production.