OpenVPN : pourquoi il semble lent (et les réglages qui le font décoller)

Ce que « lent » signifie réellement pour OpenVPN

« Lent » est un fourre-tout. Il faut nommer la douleur avant de toucher aux réglages :

• Débit faible : les gros téléchargements rampent, les sauvegardes expirent, les artefacts CI prennent une éternité.
• Latence élevée : SSH devient collant, RDP saccade, la VoIP coupe des mots.
• Jitter : ça va jusqu’à ce que ça n’aille plus ; les charges interactives paraissent hantées.
• Instabilité de la connexion : boucles de reconnexion, renégociations TLS qui tournent, blocages aléatoires.

Les performances d’OpenVPN ne sont pas un seul bouton. C’est une chaîne : chiffrement en espace utilisateur + tunnel dans le noyau + routage/NAT + le réseau réel. N’importe quelle partie peut devenir limitée. Donc on commence par un triage rapide, puis on creuse.

Feuille de diagnostic rapide (premiers/seconds/troisièmes contrôles)

Premier : déterminer si vous êtes limité par le CPU ou par le réseau

1. Vérifiez la saturation CPU du serveur pendant un transfert. Si un seul cœur est saturé, vous êtes probablement lié au chiffrement/espace utilisateur.
2. Vérifiez la qualité du lien (pertes, retransmissions, problèmes MTU). Si vous voyez de la fragmentation ou des retransmissions, vous êtes probablement limité par le chemin/MTU.
3. Vérifiez le choix du protocole. TCP over TCP est le classique « fonctionne en test, casse en production ».

Second : validez la correction MTU/MSS

1. Recherchez des trous noirs ICMP « fragmentation nécessaire ».
2. Confirmez que vous ne fragmentez pas à l’intérieur du tunnel.
3. Réglez mssfix/tun-mtu de façon conservatrice et vérifiez avec des captures de paquets.

Troisième : vérifiez buffers, files d’attente et ordonnancement

1. Buffers de socket et disciplines de file d’attente du noyau.
2. Options OpenVPN comme sndbuf/rcvbuf, et limites OS comme net.core.rmem_max.
3. Comportement de la file d’attente TUN/TAP et multi-queue là où applicable.

Si vous ne faites qu’une chose : prouvez le goulot avec des mesures. Tuner sans mesurer, c’est rendre votre futur vous misérable.

Comment OpenVPN déplace les paquets (et où il perd en performance)

OpenVPN fonctionne principalement en espace utilisateur. C’est à la fois sa force et sa taxe. Les paquets parcourent le chemin suivant :

1. L’application génère du trafic (TCP/UDP).
2. Le noyau le route dans l’interface TUN.
3. OpenVPN lit depuis TUN en espace utilisateur.
4. OpenVPN chiffre/authentifie, ajoute un overhead (en-têtes, IV, tags).
5. OpenVPN écrit les paquets encapsulés sur une socket UDP ou TCP.
6. L’internet fait ses choses : NAT, perte, réordonnancement, bizarreries MTU.
7. De l’autre côté : on inverse le processus.

Les implications de performance sont prévisibles :

• Changements de contexte : les boucles de lecture/écriture en espace utilisateur ajoutent de l’overhead.
• Points chauds mono‑thread : un seul processus peut devenir votre goulot.
• Coût du chiffrement : dépend du cipher, des fonctionnalités CPU et de la distribution des tailles de paquets.
• Overhead d’encapsulation : réduit le MTU effectif et peut déclencher la fragmentation.
• Comportement TCP : si vous tunnelisez TCP dans TCP, le contrôle de congestion devient… philosophique.

Une citation qui devrait figurer dans chaque runbook de performance VPN : idée paraphrasée de Jim Gray : « Mesurez, puis décidez ; les suppositions de performance sont généralement fausses. » C’est le boulot.

Blague #1 : Tuner OpenVPN sans métriques, c’est comme optimiser une base de données en la regardant plus fort. La base de données ne respectera pas votre confiance.

Faits intéressants et contexte historique

• Les premières versions publiques d’OpenVPN datent du début des années 2000, conçues pour la portabilité et la correction quand « appliance VPN » signifiait souvent « boîte mystère ».
• La conception en espace utilisateur était volontaire : elle évitait la douleur des modules noyau sur plusieurs OS et rendait les audits plus abordables, au prix de copies/context switches supplémentaires.
• Les abstractions TUN/TAP viennent de l’histoire du réseau Unix ; TUN (L3) est généralement plus rapide et plus simple que TAP (L2) sauf si vous avez vraiment besoin du pont Ethernet.
• Le mode UDP est devenu la recommandation par défaut parce que le mode TCP amplifie la latence et les pathologies de retransmission en cas de perte.
• Les contrôles de type « TLS auth » / « tls-crypt » ont évolué en partie comme réponse pratique au bruit de fond d’Internet et au scanning actif.
• AES-NI a changé la donne pour le débit OpenVPN sur x86 : soudain le chiffrement n’était plus toujours le goulot — le traitement des paquets l’était souvent.
• ChaCha20-Poly1305 s’est popularisé car il est performant sur des appareils sans accélération AES (nombreux petits routeurs et certaines VM).
• L’offload du canal de données n’est pas l’histoire centrale d’OpenVPN comme pour certains VPN noyau‑based ; OpenVPN gagne sur la maturité et la flexibilité, pas sur le zéro‑copy fanfaron.
• Beaucoup de rapports « OpenVPN est lent » sont en réalité des trous noirs MTU créés par des réseaux qui bloquent l’ICMP nécessaire à la découverte du PMTU.

Les goulots habituels : CPU, MTU, buffers, routage et mauvais réglages

1) Chiffrement lié au CPU (ou, plus souvent, le churn de paquets en espace utilisateur)

Si un processus OpenVPN réalise tout le travail, vous pouvez saturer un seul cœur bien avant de saturer un lien 1 Gbps — surtout avec beaucoup de petits paquets (trafic interactif, API bavardes, DNS, RDP, métadonnées SMB). Le chiffrement est coûteux, mais « juste déplacer des paquets » en espace utilisateur l’est aussi.

Ce qui aggrave le problème :

• Faire fonctionner OpenVPN dans une petite VM avec un ordonnancement CPU contraint.
• Utiliser un cipher lent sur votre CPU (ou sans accélération matérielle).
• Des taux de paquets élevés : le débit en Mbps peut sembler médiocre même si la bande passante n’est pas énorme.

2) Incompatibilité MTU/MSS et fragmentation

L’encapsulation vole des octets à votre payload. Si votre trafic interne suppose un MTU de 1500 octets et que le chemin du tunnel ne peut porter que, disons, 1472 octets (ou moins), vous obtenez de la fragmentation. La fragmentation peut être simplement inefficace, ou catastrophique quand l’ICMP est bloqué et que le PMTUD casse.

Le schéma est classique :

• Les petites requêtes fonctionnent.
• Les gros téléchargements se figent, surtout sur TCP.
• Certaines sites fonctionnent, d’autres bloquent mystérieusement.

3) Effondrement TCP‑sur‑TCP

Tunneliser du trafic TCP à travers un tunnel OpenVPN qui fonctionne sur TCP équivaut à empiler deux contrôleurs de congestion et leur demander de se coordonner par vibration. En cas de perte, les deux couches retransmettent et reculent, et la latence explose. Ça peut « marcher » sur des réseaux de labo parfaits, puis s’effondrer sur des liens réels.

4) Buffers et file d’attente (aka « la latence est un problème de stockage avec des paquets »)

Les buffers existent pour lisser les rafales. Trop petits, vous perdez. Trop grands, vous générez du bufferbloat et ajoutez de la latence. OpenVPN a ses propres buffers de socket, et l’OS a des limites. Il faut des tailles raisonnables et des qdiscs appropriés, surtout pour les réseaux large‑BDP.

5) Erreurs de routage/NAT et chemins asymétriques

OpenVPN peut être rapide alors que votre routage est lent. Si le trafic fait un chemin en épingle à cheveux via un pare‑feu, ou si vos règles NAT forcent un churn conntrack, vous accuserez le VPN parce que c’est le changement visible. Ne le faites pas. Suivez les paquets.

6) Le tueur discret : DNS et résolution de noms

Parfois le tunnel va bien mais le DNS via le tunnel ne va pas. Pics de latence, retries, split‑DNS cassé, ou résolveurs inatteignables. Les utilisateurs disent « le VPN est lent » alors qu’ils veulent dire « chaque page attend le DNS ».

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

Ces tâches sont conçues pour être lancées sur des serveurs/clients Linux. Adaptez les noms d’interface si nécessaire. Chaque tâche indique ce que la sortie signifie et quelle décision en découle.

Task 1: Confirm OpenVPN mode, cipher, and whether you’re on UDP

cr0x@server:~$ sudo ss -lntup | awk 'NR==1 || /openvpn/'
Netid State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp   UNCONN 0      0      0.0.0.0:1194      0.0.0.0:*     users:(("openvpn",pid=1324,fd=6))

Signification : Vous écoutez sur UDP/1194. Bon choix par défaut pour la performance.

Décision : Si vous voyez tcp ici, soyez méfiant. N’utilisez TCP que si vous devez absolument traverser des réseaux hostiles.

Task 2: Check server CPU saturation during a transfer

cr0x@server:~$ top -b -n 1 -o %CPU | head -n 12
top - 10:21:33 up 31 days,  4:02,  1 user,  load average: 1.92, 1.41, 1.22
Tasks: 162 total,   1 running, 161 sleeping,   0 stopped,   0 zombie
%Cpu(s):  8.2 us,  1.0 sy,  0.0 ni, 90.5 id,  0.2 wa,  0.0 hi,  0.1 si,  0.0 st
MiB Mem :  7986.4 total,  2141.2 free,  1680.0 used,  4165.2 buff/cache
MiB Swap:  2048.0 total,  2048.0 free,     0.0 used.  5789.1 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1324 nobody    20   0  178248  18624   7512 R  98.7   0.2  52:14.11 openvpn

Signification : OpenVPN monopolise un cœur. Vous êtes probablement lié au CPU/espace utilisateur.

Décision : Envisagez des ciphers plus rapides pour votre CPU, assurez‑vous que AES‑NI est disponible, réduisez les problèmes de taux de paquets, ou scalez horizontalement (plus d’instances, plus de tunnels, ou une autre tech VPN si vous avez besoin de multi‑gigabit).

Task 3: Verify hardware crypto capability (AES-NI) on x86

cr0x@server:~$ lscpu | egrep 'Model name|Flags' | head -n 2
Model name:                           Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
Flags:                                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr ... aes ...

Signification : le flag aes est présent ; l’accélération AES est probablement disponible.

Décision : Privilégiez AES‑GCM sur les CPUs avec AES‑NI. Si absent (commun sur petits appareils ARM), envisagez ChaCha20‑Poly1305 (si votre build OpenVPN le supporte).

Task 4: Identify packet loss and retransmits on the physical interface

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
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    9812345678 8123456      0   12890       0       0
    TX:  bytes packets errors dropped carrier collsns
    8765432109 7345678      0    4321       0       0

Signification : Des drops sur RX/TX peuvent indiquer congestion, problèmes de pilote, ou pression sur les buffers.

Décision : Si les drops augmentent pendant la charge VPN, ajustez les qdiscs, augmentez les buffers prudemment, ou corrigez les paramètres NIC/virtio. Les drops ne sont pas « normaux ». Ce sont des indices.

Task 5: Check UDP receive errors at the kernel level

cr0x@server:~$ netstat -su | egrep -i 'packet receive errors|receive buffer errors|ignored|InDatagrams'
    1892345 packets received
    0 packet receive errors
    0 receive buffer errors
    1892345 InDatagrams

Signification : Si receive buffer errors augmente, le noyau jette des UDP parce que les buffers sont trop petits ou le CPU ne suit pas.

Décision : Augmentez les limites de buffers socket du système et envisagez rcvbuf/sndbuf dans OpenVPN avec push (mais ne les mettez pas aveuglément à « infini »).

Task 6: Measure real tunnel throughput with iperf3 (don’t trust speed tests)

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

cr0x@server:~$ iperf3 -c 10.8.0.1 -P 4 -t 15
Connecting to host 10.8.0.1, port 5201
[SUM]   0.00-15.00  sec   620 MBytes   347 Mbits/sec  sender
[SUM]   0.00-15.00  sec   616 MBytes   344 Mbits/sec  receiver

Signification : Vous avez une base de référence. Les flux parallèles aident à révéler si vous atteignez des limites de congestion par flux unique.

Décision : Si un flux est lent mais que plusieurs flux vont bien, regardez du côté du fenêtrage TCP/latence et du contrôle de congestion, pas seulement la bande passante brute.

Task 7: Detect MTU blackhole with ping and “do not fragment”

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

--- 1.1.1.1 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2042ms

Signification : Votre MTU de chemin est plus petit que l’attente de payload 1500. Sur un tunnel, il sera encore plus petit.

Décision : Réglez tun-mtu et mssfix pour éviter la fragmentation. Ne devinez pas ; trouvez la plus grande taille fonctionnelle le long du chemin du tunnel.

Task 8: Check effective MTU on the tunnel interface

cr0x@server:~$ ip link show dev tun0
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 500
    link/none

Signification : Le MTU est 1500 sur tun0. Cela peut être incorrect selon l’encapsulation et le chemin.

Décision : Si vous voyez fragmentation ou blocages, baissez tun-mtu (et clamp MSS). Un point de départ raisonnable est 1500 moins l’overhead ; beaucoup d’opérateurs tombent autour de 1400–1450 selon l’environnement.

Task 9: Observe actual fragmentation with tcpdump

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 1194 -vv -c 10
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:25:11.123456 IP (tos 0x0, ttl 64, id 54321, offset 0, flags [+], proto UDP (17), length 1514)
    203.0.113.10.1194 > 198.51.100.20.51123: UDP, length 1486
10:25:11.123457 IP (tos 0x0, ttl 64, id 54321, offset 1480, flags [none], proto UDP (17), length 54)
    203.0.113.10.1194 > 198.51.100.20.51123: UDP, length 26

Signification : Les flags [+] et offsets indiquent de la fragmentation.

Décision : Baissez le MTU du tunnel et utilisez le clamp MSS. La fragmentation est une taxe ; la fragmentation blackholed est une panne.

Task 10: Check for TCP retransmits (symptom of loss or MTU trouble)

cr0x@server:~$ ss -ti dst 10.8.0.2 | head -n 30
ESTAB 0 0 10.8.0.1:5201 10.8.0.2:51044
	 cubic wscale:7,7 rto:204 rtt:45.2/3.1 ato:40 mss:1360 pmtu:1400 rcvmss:1360 advmss:1360 cwnd:26 bytes_sent:12345678 bytes_retrans:23456 bytes_acked:12320000

Signification : L’augmentation de bytes_retrans indique des retransmissions ; notez aussi les valeurs pmtu et mss.

Décision : Si les retransmissions montent en flèche, corrigez d’abord la perte (Wi‑Fi, LTE, liens surchargés) et corrigez le MTU ensuite. Ne « optimisez » pas les ciphers pendant que le chemin est en flammes.

Task 11: Verify routing: is traffic actually going through the tunnel?

cr0x@server:~$ ip route get 8.8.8.8
8.8.8.8 via 10.8.0.5 dev tun0 src 10.8.0.1 uid 0
    cache

Signification : Cette destination passe par tun0. Correct.

Décision : Si ça sort par eth0 alors que vous attendez tun0, vous avez un problème de routage de politique ou des routes poussées — les utilisateurs peuvent hairpinner, fuir, ou avoir un split‑routing involontaire.

Task 12: Confirm NAT/forwarding for site-to-site or “push redirect-gateway” setups

cr0x@server:~$ sudo sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    iifname "tun0" oifname "eth0" accept
    iifname "eth0" oifname "tun0" ct state established,related accept
  }
}
table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    oifname "eth0" ip saddr 10.8.0.0/24 masquerade
  }
}

Signification : Le forwarding est activé et il y a du NAT pour les clients du tunnel sortant via eth0.

Décision : Si le forwarding est désactivé ou que des règles drop, vous verrez « VPN connecté mais pas d’internet » ou des lenteurs étranges dues à des chemins de retour asymétriques.

Task 13: Check socket buffer maximums (OS limits)

cr0x@server:~$ sysctl net.core.rmem_max net.core.wmem_max net.ipv4.udp_rmem_min net.ipv4.udp_wmem_min
net.core.rmem_max = 212992
net.core.wmem_max = 212992
net.ipv4.udp_rmem_min = 4096
net.ipv4.udp_wmem_min = 4096

Signification : Les valeurs par défaut sont conservatrices. Sur des liens à haut BDP, cela peut limiter le débit ou provoquer des drops.

Décision : Augmentez-les prudemment (et surveillez). Si vous augmentez les buffers OpenVPN mais que le max OS est faible, votre réglage ne tiendra pas.

Task 14: Validate queue discipline (bufferbloat control)

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 : fq_codel est généralement favorable à la latence sous charge.

Décision : Si vous voyez un pfifo_fast énorme ou des buffers massifs en sortie WAN, envisagez de passer à fq_codel ou cake (quand disponible) pour dompter les pics de latence.

Réglages qui font décoller (et quoi éviter)

Choisissez UDP sauf vrai besoin contraire

UDP n’est pas « plus rapide parce que UDP ». Il est plus performant parce que vous évitez l’effondrement TCP‑sur‑TCP et vous laissez les sessions TCP internes faire leur travail sans être enveloppées dans une autre couche de fiabilité.

À faire : proto udp pour la plupart des déploiements.

À éviter : proto tcp par défaut. Utilisez‑le pour les portails captifs et les réseaux très verrouillés, en acceptant la perte de performances.

Utilisez TUN (routé) sauf si vous avez vraiment besoin de TAP (ponté)

TAP traîne les sémantiques Ethernet dans votre vie : broadcasts, bruit ARP, et trames plus grosses. Parfois nécessaire (apps legacy, L2), souvent non.

À faire : dev tun pour site‑à‑site et VPN client.

À éviter : dev tap quand la seule justification est « c’était dans un article de blog ».

Réglez MTU/MSS correctement, puis arrêtez d’y toucher

Si vous retenez une règle de tuning : évitez la fragmentation à l’intérieur du tunnel. Utilisez mssfix pour clamer le MSS TCP afin que les endpoints n’envoient pas de segments trop grands pour le MTU effectif. Utilisez tun-mtu pour fixer le MTU de l’interface tunnel si nécessaire.

Extraits de config serveur typiques (illustratifs, pas universels) :

• mssfix : clamp le MSS TCP ; utile pour éviter les problèmes PMTUD.
• tun-mtu : fixe le MTU du tunnel ; aide à imposer des tailles sans fragmentation.
• fragment : généralement à éviter ; la fragmentation est souvent un palliatif à un chemin cassé et peut mal interagir avec les réseaux modernes.

Choisissez des ciphers modernes en fonction de votre CPU

Sur x86 avec AES‑NI, AES‑128‑GCM est souvent un bon compromis. AES‑256‑GCM peut convenir aussi, mais ne payez pas des cycles supplémentaires sans bénéfice réel pour votre modèle de menace. Sur des appareils sans accélération AES, ChaCha20‑Poly1305 peut être plus performant.

Aussi : la négociation de cipher et la compatibilité comptent. Un « cipher rapide » que vous ne pouvez pas utiliser partout est juste un risque de changement futur.

Ne gonflez pas les buffers aveuglément

Oui, des buffers plus gros peuvent aider le débit sur des liens à haute latence. Ils peuvent aussi créer des secondes de mise en file et rendre le trafic interactif misérable. Pensez aux buffers comme un cache d’écriture : utile jusqu’à ce que ça devienne votre incident.

Keepalive et renégociation : n’engendrez pas du jitter auto‑infligé

La renégociation et des keepalives agressifs peuvent provoquer des arrêts périodiques. Réglez les keepalives selon les timeouts NAT, et ne faites pas chuter TLS inutilement. Si vous voyez des « tout le monde gèle pendant une seconde », vérifiez les intervalles de renégociation et les pics CPU.

Scalez horizontalement quand vous atteignez les limites d’un seul processus

OpenVPN gère bien de nombreux clients, mais il existe de vrais plafonds par processus selon le taux de paquets, le chiffrement et le CPU. Si vous poussez beaucoup de bande passante agrégée, envisagez :

• Plusieurs instances OpenVPN liées à différents ports/IP.
• Distribution des clients entre les instances.
• Plus de CPU et des cœurs plus rapides (pas seulement plus de RAM).
• Réévaluer si un VPN noyau‑based vous convient mieux si vous visez du multi‑gigabit par tunnel.

Blague #2 : Si vous réglez tous les buffers à 16 MB, vous n’avez pas optimisé le VPN. Vous avez construit un musée de latence et facturé vos utilisateurs pour l’entrée.

Trois mini-récits d’entreprise depuis le terrain

Mini‑récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise moyenne a déployé OpenVPN pour connecter le personnel distant aux outils internes. Le groupe pilote était ravi. Le déploiement est devenu global. Puis la file de tickets a commencé à ressembler à une attaque par déni de service, sauf que les attaquants étaient des employés.

Les symptômes étaient incohérents : certains utilisateurs pouvaient charger des apps internes sans problème, mais télécharger de gros fichiers depuis un dépôt d’artefacts interne allait se figer. D’autres rapportaient que seuls certains sites étaient cassés, et les échecs variaient selon les Wi‑Fi d’hôtel. Naturellement, tout le monde accusait le serveur OpenVPN parce que c’était la nouveauté.

La mauvaise hypothèse : « MTU fonctionnera parce qu’Ethernet fait 1500. » L’équipe réseau avait un segment de chemin avec un MTU plus petit (un segment fournisseur et un saut VPN‑dans‑VPN), et les messages ICMP « fragmentation nécessaire » étaient filtrés. La découverte du PMTU ne pouvait pas faire son travail. Les petits paquets survivaient ; les plus gros mouraient en silence.

La correction fut ennuyeuse et immédiate : clamp MSS et baisser le MTU du tunnel à une valeur sûre sur toute la flotte. Une fois fait, les « blocages aléatoires » ont disparu. Ils ont ensuite corrigé le filtrage ICMP, mais les réglages MTU/MSS ont constitué la vraie ceinture de production.

Mini‑récit 2 : L’optimisation qui a mal tourné

Une autre organisation voulait plus de débit pour une synchronisation nocturne de données. Quelqu’un a lu que « des buffers plus gros améliorent la performance » et a gonflé sndbuf/rcvbuf d’OpenVPN, plus augmenté les max du kernel. Le débit est monté dans un test synthétique. Champagne.

Puis les plaintes ont commencé : la qualité VoIP a chuté, les sessions terminales semblaient retardées, et la surveillance a commencé à fluctuer. Rien n’était « en panne », mais tout paraissait pire. C’était la dégradation qui vous fait douter de votre choix de carrière.

Ils avaient créé du bufferbloat sur la sortie VPN. La synchronisation nocturne augmentait son débit en s’asseyant sur une montagne de paquets en file, et le trafic interactif devait attendre derrière. Sous charge, la latence est passée de « correcte » à « sommes‑nous attaqués ? ». Il n’y avait pas d’attaque. Juste un buffering enthousiaste.

Le rollback a amélioré l’expérience utilisateur instantanément. La solution finale a été d’utiliser un fair queueing en sortie, de garder des buffers raisonnables, et de limiter le débit des flux de masse pour qu’ils n’écrasent pas tout le reste.

Mini‑récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise régulée utilisait OpenVPN pour l’accès des fournisseurs dans un environnement segmenté. Rien de glamour : règles de pare‑feu strictes, routes explicites, et fenêtres de changement qui pouvaient fossiliser un bug.

L’équipe faisait une chose peu sexy de façon consistante : ils conservaient un runbook de performance avec des tests répétables — iperf3 à travers le tunnel, sondes MTU, snapshots CPU, et captures de paquets pour les canaux de contrôle et de données. Chaque demande de changement incluait des résultats « avant » et « après ».

Un mois, les plaintes de performance ont explosé après une mise à jour de politique de pare‑feu. Grâce aux baselines, ils ont rapidement prouvé que le serveur VPN n’était pas le limiteur : CPU ok, pas de fragmentation, débit stable sur le serveur. Les captures ont montré des retransmissions et du désordre commençant à la périphérie.

Il s’est avéré qu’une nouvelle politique d’inspection sur le pare‑feu interagissait mal avec les flux UDP à grande échelle. Ils ont reverté cette politique et ont restauré des performances normales. Sans baselines, le blâme serait tombé sur OpenVPN (et les gens qui le maintiennent), et la correction aurait pris des semaines de tuning erroné.

Erreurs courantes : symptôme → cause racine → correction

• Symptôme : « Le VPN se connecte, la navigation est correcte, mais les gros téléchargements se figent. »

  Cause racine : Trou noir MTU / PMTUD cassé ; messages de fragmentation nécessaires bloqués.

  Correction : Définir mssfix et potentiellement baisser tun-mtu ; vérifier avec ping -M do et tcpdump pour la fragmentation.

• Symptôme : « Le débit est plafonné bizarrement bas ; le CPU semble élevé. »

  Cause racine : Processus OpenVPN lié au CPU ; cipher lent sur ce CPU ; overhead lié au taux de paquets.

  Correction : Privilégier AES‑GCM sur les systèmes AES‑NI ou ChaCha20 sur les systèmes non‑AES ; allouer des cœurs plus rapides ; scalabilité horizontale d’instances.

• Symptôme : « Ça marche au bureau, terrible sur mobile ou Wi‑Fi. »

  Cause racine : Perte de paquets et réordonnancement ; TCP‑over‑TCP si OpenVPN tourne sur TCP ; ou MTU trop agressif.

  Correction : Utiliser le transport UDP ; clamp MSS ; considérer un MTU conservateur ; s’assurer que les keepalives correspondent aux NAT.

• Symptôme : « Les tests de vitesse montrent une latence élevée sous charge ; les appels saccadent pendant les gros transferts. »

  Cause racine : Bufferbloat dû à des buffers surdimensionnés ou un mauvais qdisc.

  Correction : Utiliser fq_codel/cake quand possible ; garder des buffers raisonnables ; limiter les flux de masse.

• Symptôme : « Seul le DNS est lent ; tout semble retardé au chargement des pages. »

  Cause racine : Les résolveurs poussés via le tunnel sont lents/inaccessibles ; split DNS mal configuré.

  Correction : Tester la reachabilité/latence des résolveurs ; pousser le DNS correct ; éviter de hairpinner vers un résolveur distant.

• Symptôme : « Le débit VPN est correct pour certains clients, terrible pour d’autres. »

  Cause racine : Problèmes côté client : MTU/Wi‑Fi/LTE ; comportement NAT différent des ISP ; routes différentes vers le POP du serveur.

  Correction : Tester MTU et pertes par client ; préférer des endpoints serveur proches ; standardiser les configs clients ; mesurer le chemin avec mtr.

• Symptôme : « Après activation de la compression, la vitesse a chuté et le CPU a chauffé. »

  Cause racine : Overhead de compression sur du trafic déjà compressé ; préoccupations de sécurité ; CPU additionnel en espace utilisateur.

  Correction : Désactiver la compression pour le trafic Internet général ; ne l’envisager que dans des cas restreints et mesurables.

• Symptôme : « Des blocages intermittents toutes les N minutes. »

  Cause racine : Événements de rekey/renégociation provoquant des pics CPU ; timeouts NAT causant de brèves coupures ; redémarrages watchdog.

  Correction : Inspecter les logs pour les renégociations ; ajuster les keepalives ; assurer des ressources système stables ; ne pas définir des intervalles de rekey trop agressifs sans raison.

Listes de contrôle / plan pas à pas

Pas à pas : rendre OpenVPN rapide sans le rendre fragile

1. Établir une baseline : exécutez iperf3 à travers le tunnel (1 flux puis plusieurs flux), enregistrez le RTT et les retransmissions.
2. Confirmer le transport : utilisez UDP sauf contrainte stricte nécessitant TCP.
3. Vérifier le CPU : si un cœur est bloqué, corrigez le choix du cipher/l’allocation CPU/scale‑out avant de toucher au MTU.
4. Corriger MTU/MSS : sonder le MTU ; définir mssfix ; ajuster tun-mtu si besoin ; vérifier que la fragmentation disparaît.
5. Vérifier les drops noyau : utiliser ip -s link et netstat -su ; si des drops apparaissent, traiter buffers/CPU/NIC.
6. Valider le routage : assurez‑vous que les routes sont comme prévu ; éviter les hairpins ; confirmer la symétrie des chemins de retour.
7. Contrôler la file d’attente : vérifier le qdisc ; éviter le bufferbloat ; si vous devez prioriser, faites‑le explicitement.
8. Retester : répétez les tests de base et comparez. Si vous n’avez pas mesuré, vous n’avez rien réparé.
9. Documenter la config « connue bonne » : inclure les hypothèses MTU, choix de ciphers, et sysctls OS utilisés.
10. Surveiller en continu : CPU, drops de paquets et uptime du tunnel doivent être sur des dashboards, pas dans la tête de quelqu’un.

Checklist rapide : bonnes et mauvaises pratiques de tuning

• Do utilisez le transport UDP pour la performance.
• Do clamppez le MSS pour éviter les surprises de fragmentation.
• Do vérifiez AES‑NI / features CPU et choisissez les ciphers en conséquence.
• Do utilisez le fair queueing sur les interfaces WAN quand possible.
• Don’t faites TCP‑over‑TCP sauf si vous aimez déboguer les retransmissions pour le sport.
• Don’t « résolvez » le débit en gonflant les buffers jusqu’à ce que la latence devienne une caractéristique de personnalité.
• Don’t activez la compression comme bouton magique d’accélération.
• Don’t tunez à l’aveugle — loguez, mesurez, puis changez une chose à la fois.

FAQ

1) Pourquoi OpenVPN semble-t-il plus lent que ma connexion internet brute ?

Parce que vous avez ajouté un overhead de chiffrement, des en‑têtes supplémentaires (MTU effectif plus petit), et du traitement de paquets en espace utilisateur. N’importe lequel de ces éléments peut devenir la limite.

2) UDP est-il toujours plus rapide que TCP pour OpenVPN ?

Pas toujours, mais généralement plus stable et performant en présence de perte. Le transport TCP est parfois nécessaire pour des réseaux très restrictifs, mais c’est un compromis de performance.

3) Quelle est la cause la plus courante dans le monde réel d’un « OpenVPN lent » ?

Des problèmes MTU/PMTUD menant à de la fragmentation ou à des trous noirs. C’est le pire type de problème : intermittent, dépendant du chemin, et mal attribué.

4) Dois‑je activer la compression pour accélérer OpenVPN ?

Généralement non. La plupart du trafic moderne est déjà compressé (HTTPS, vidéo, téléchargements). La compression brûle du CPU et peut poser des soucis de sécurité. Ne l’envisagez que si vous pouvez prouver qu’elle aide votre mix de trafic.

5) Comment savoir si je suis limité par le CPU ?

Pendant un transfert, si le processus OpenVPN bloque un cœur et que le débit plafonne, vous êtes lié CPU/espace utilisateur. Confirmez avec top et comparez les changements de débit après avoir modifié le cipher/CPU.

6) Quel MTU dois‑je définir pour OpenVPN ?

Il n’y a pas de nombre universel. Commencez par mesurer le MTU de chemin puis réglez mssfix pour empêcher les segments TCP d’excéder le MTU effectif. Beaucoup d’environnements choississent 1400–1450 pour le MTU du tunnel, mais mesurez votre chemin.

7) Pourquoi plusieurs flux iperf3 améliorent-ils le débit ?

Un flux peut être limité par la croissance de la fenêtre TCP et la récupération après perte. Plusieurs flux peuvent mieux exploiter la bande passante sur des chemins à haute latence. C’est aussi un indice : si les flux parallèles aident, votre souci n’est pas seulement la bande passante brute.

8) OpenVPN peut-il atteindre des débits gigabit ?

Oui, dans certains contextes avec des CPUs puissants et un bon tuning. Mais le taux de paquets compte : beaucoup de petits paquets peuvent vous limiter avant que les Mbps ne le fassent. À un moment, scaler horizontalement ou changer de technologie VPN peut être plus propre.

9) Dois‑je utiliser le bridging TAP pour « de meilleures performances » ?

Non. TAP sert des besoins L2, pas la vitesse. Il ajoute souvent de l’overhead à cause du broadcast et du bruit ARP. Utilisez TUN sauf si vous avez besoin d’adjacence Ethernet.

10) Pourquoi la performance est‑elle correcte au bureau mais mauvaise pour les utilisateurs distants ?

Parce qu’Internet n’est pas un réseau unique. Les utilisateurs distants ont des MTU différents, des comportements NAT divers, des taux de perte et des routes distinctes. Mesurez depuis le chemin de l’utilisateur et tunez pour survivre à des réseaux hostiles.

Conclusion : prochaines étapes pratiques

Si OpenVPN semble lent, ne commencez pas par une séance de configuration mystique. Commencez par des preuves.

1. Exécutez iperf3 à travers le tunnel (flux simple et parallèles). Enregistrez débit et RTT.
2. Vérifiez le CPU pendant le test. Si un cœur est bloqué, corrigez cela en priorité.
3. Sondez le MTU et éliminez la fragmentation. Clampez le MSS. Vérifiez avec tcpdump.
4. Recherchez les drops et erreurs de buffer dans les stats du noyau. Corrigez le contrôle de file d’attente et les limites de buffer prudemment.
5. Retestez et documentez une configuration « connue bonne » pour que vos incidents futurs aient moins de rebondissements.

OpenVPN peut être ennuyeusement rapide si vous le traitez comme un système, pas comme un tunnel magique. Mesurez. Changez une chose. Mesurez encore. Répétez jusqu’à ce que les graphiques se calment.