OpenVPN : configurer correctement (et pourquoi il est souvent plus lent que WireGuard)

Un modèle mental de la « vitesse VPN » qui aide vraiment

« Vitesse VPN » n’est pas une chose unique. C’est une pile de goulots d’étranglement prêts à être révélés par la bonne charge de travail.
Si vous ne nommez pas les couches, vous optimiserez la mauvaise et déclarerez victoire pendant que les utilisateurs souffrent.

Couche 1 : Qualité du chemin (pertes, gigue et bufferbloat)

Les VPN amplifient les réseaux médiocres. Si le dernier kilomètre perd des paquets, le chiffrement ne le répare pas ; il rend la perte plus difficile à diagnostiquer.
Un tunnel modifie aussi la taille et le rythme des paquets, ce qui interagit avec les tampons des routeurs grand public et des réseaux LTE.
Les pics de latence se ressentent comme un « VPN lent » même quand les tests de débit semblent corrects.

Couche 2 : Surcharge d’encapsulation (MTU/MSS)

Vos applications croient envoyer des trames Ethernet de 1500 octets. Votre VPN ajoute des en-têtes.
Si le MTU effectif est plus petit et que vous ne limitez pas le MSS ou n’ajustez pas le MTU, vous obtenez de la fragmentation ou des paquets noirs.
La fragmentation ressemble à des blocages aléatoires. Le blackholing ressemble à « certains sites se chargent, d’autres non ».

Couche 3 : Crypto et traitement des paquets

C’est là que la différence OpenVPN vs WireGuard devient visible. WireGuard vit dans le noyau sur Linux et garde le chemin chaud minimal.
OpenVPN classique fonctionne principalement en espace utilisateur. L’espace utilisateur n’est pas intrinsèquement lent, mais il paye en changements de contexte, copies mémoire
et ordonnancement, surtout à des taux de paquets élevés.

Couche 4 : Choix de transport (UDP vs TCP, et le piège TCP-over-TCP)

UDP est généralement le bon choix pour le plan de données d’un VPN. TCP à l’intérieur de TCP peut créer une boucle de rétroaction où les deux couches retransmettent,
où les deux couches reculent, et où les performances s’effondrent en cas de perte. Ce n’est pas théorique ; c’est ainsi que l’on obtient 2 Mbps sur un lien gigabit.

Faits et historique intéressants (ce qui explique les compromis d’aujourd’hui)

• OpenVPN date de 2001, construit autour de TLS et d’un design flexible en espace utilisateur. Cette flexibilité explique pourquoi il tourne presque partout — et pourquoi il est plus lourd.
• WireGuard a débuté au milieu des années 2010 avec une base de code volontairement petite et des primitives crypto modernes, optimisé pour la simplicité et l’auditabilité.
• OpenVPN est devenu le « choix par défaut entreprise » en partie parce qu’il était précoce et fonctionnait bien à travers NAT/firewalls, bien avant que le « zero trust » ne devienne un slide deck.
• Le récit des chiffrements d’OpenVPN a évolué des anciens modes CBC et combos HMAC vers AES-GCM et des valeurs par défaut modernes, mais des configurations legacy persistent pendant des années.
• Pendant longtemps, le tuning d’OpenVPN signifiait « choisir UDP et prier » ; des améliorations plus récentes comme ovpn-dco (data channel offload) sont arrivées pour réduire la surcharge en espace utilisateur.
• WireGuard utilise des handshakes basés sur Noise et un concept de « cryptokey routing », ce qui réduit la complexité du plan de contrôle et évite les drames de renégociation à l’exécution.
• Le jeu de fonctionnalités d’OpenVPN est énorme (plugins d’auth, routes poussées, hooks de script, multiples méthodes d’auth). Chaque fonctionnalité est un levier, et les leviers invitent les accidents.
• Sur Linux, les chemins rapides du noyau comptent : traiter les paquets sans rebondir entre noyau et espace utilisateur est souvent la différence entre « acceptable » et « pourquoi un cœur est à 100 % ? »

Une idée opérationnelle paraphrasée d’un notable de la fiabilité s’applique ici : idée paraphrasée : « La simplicité est une condition préalable à la fiabilité. » — John Ousterhout (idée paraphrasée)

Configurer OpenVPN correctement : la base qui évite la douleur auto-infligée

Choisissez une topologie sensée : routée (tun) sauf raison très spécifique

Utilisez dev tun et routez des sous-réseaux IP. Le bridging (tap) introduit le broadcast L2 dans le tunnel, augmente le trafic de découverte,
et rend le dépannage aussi frustrant que de chasser des ratons laveurs dans un faux-plafond.

Utilisez UDP pour le plan de données

À moins que votre environnement ne bloque absolument UDP, choisissez-le. Le mode TCP est pour « je suis coincé dans un portail Wi‑Fi d’hôtel de 2009 ».
Si vous contrôlez les deux extrémités, ne faites pas de TCP par défaut. Il vous trahira en cas de perte.

Utilisez une crypto moderne et accélérée matériellement

Sur des serveurs x86 typiques, AES-GCM avec AES-NI est rapide. ChaCha20-Poly1305 est aussi excellent, surtout sur des appareils sans accélération AES.
Ne cherchez pas à être trop astucieux avec des chiffrements exotiques « pour la sécurité ». La sécurité inclut la disponibilité, et un VPN qui rampe encourage les utilisateurs à le contourner.

Gardez la configuration ennuyeuse

« Ennuyeuse » signifie : plugins minimaux, scripts minimaux, pushes minimaux, overrides par client minimaux.
Chaque bouton en plus est un nouveau mode de défaillance, et OpenVPN a suffisamment de boutons pour ressembler à un orgue.

Prévoyez MTU et MSS d’emblée

Vous voulez que le tunnel évite la fragmentation sur le chemin réel Internet. En pratique, vous limitez le MSS pour les sessions TCP
afin que les points finaux n’essaient pas d’envoyer des segments trop grands. Ce n’est pas optionnel si vous voulez que ça « marche partout ».

La journalisation et l’observabilité font partie de la configuration

Si vous ne pouvez pas répondre « est-ce le CPU, le MTU, la perte ou la congestion ? » en cinq minutes, vous n’avez pas configuré un VPN de production.
Vous avez configuré un roman policier.

Blague n°1 : Les configs OpenVPN sont comme les tiroirs à bordel de cuisine — tout marche jusqu’au moment où vous avez besoin d’une chose vite.

Pourquoi OpenVPN est souvent plus lent que WireGuard (sans dogmatisme)

Espace utilisateur vs datapath noyau

WireGuard sur Linux s’exécute dans le noyau, donc les paquets entrent dans le noyau, sont chiffrés/déchiffrés, et poursuivent leur route avec moins de transitions.
OpenVPN classique lit typiquement les paquets d’un dispositif TUN en espace utilisateur, chiffre/déchiffre, puis réécrit.
Cela signifie plus de changements de contexte et de copies mémoire. À faible débit cela importe peu. À des taux de paquets élevés, ça se voit.

Le taux de paquets importe plus que le débit pour le CPU. Beaucoup de petits paquets (VoIP, jeux, RPC, microservices bavards)
peuvent saturer un cœur CPU bien avant de saturer un lien. La surcharge d’OpenVPN apparaît d’abord ici.

Complexité du protocole et bavardage du plan de contrôle

OpenVPN est construit sur TLS, supporte la renégociation, plusieurs mécanismes d’auth et un ensemble riche d’extensions.
C’est puissant. C’est aussi plus de pièces mobiles : plus d’état, plus de chemins de code, et plus de façons d’atterrir sur un chemin lent.
Le modèle de WireGuard est intentionnellement plus étroit.

Choix crypto et détails d’implémentation

OpenVPN peut être très rapide avec le bon chiffrement, mais il peut aussi être douloureusement lent avec le mauvais.
AES-CBC + HMAC peut convenir, mais AES-GCM est typiquement meilleur, et des valeurs par défaut obsolètes peuvent encore se cacher dans des déploiements anciens.
WireGuard standardise des primitives modernes ; vous ne « choisissez » pas dans un menu, donc vous ne choisissez pas la mauvaise option.

Le meltdown TCP-over-TCP est réel

Si vous exécutez OpenVPN sur TCP et transportez du trafic applicatif TCP à l’intérieur, vous avez créé deux boucles de contrôle de congestion.
La perte déclenche des retransmissions aux deux niveaux ; la latence monte ; les fenêtres rétrécissent ; le débit s’effondre.
WireGuard est uniquement UDP ; il évite entièrement cette catégorie par conception.

Gestion du MTU et pénalités de fragmentation

OpenVPN et WireGuard peuvent souffrir si le MTU est incorrect. Mais les déploiements OpenVPN héritent plus souvent de réglages legacy comme
des MTU fixes, une compression supplémentaire (n’en mettez pas), et des scripts transmis. Les configs WireGuard ont tendance à être plus courtes et récentes,
ce qui signifie moins de mines historiques.

DCO change la comparaison

OpenVPN avec Data Channel Offload (ovpn-dco) rapproche le plan de données du noyau, réduisant substantiellement la surcharge.
Si vous avez besoin des fonctionnalités enterprise d’OpenVPN mais voulez des performances proches de WireGuard, DCO est la première chose à évaluer.
Toutes les plateformes ne le supportent pas également, et la maturité opérationnelle varie selon la distribution.

Blague n°2 : Exécuter TCP sur TCP pour la « fiabilité » ressemble à porter deux imperméables et se plaindre de ne pas pouvoir bouger les bras.

Méthode de diagnostic rapide : trouver le goulot en quelques minutes

Quand quelqu’un dit « OpenVPN est lent », vous avez besoin d’un ordre de triage reproductible. Ne commencez pas par changer les chiffrements.
Commencez par prouver où se trouvent le temps et les pertes.

Première étape : confirmer l’évident (transport, chemin, MTU)

1. Vérifiez si vous utilisez UDP. Si TCP : suspectez immédiatement le meltdown TCP-over-TCP.
2. Vérifiez les symptômes MTU/MSS. Si « certains sites bloquent » ou « gros téléchargements stagnent », suspectez le MTU.
3. Vérifiez la perte et la gigue. Si de la perte existe, le débit chutera même avec une crypto parfaite.

Seconde étape : confirmer si le serveur est limité par le CPU ou par le taux de paquets

1. Cherchez un cœur unique saturé. OpenVPN est souvent limité par un thread qui gère la crypto ou l’I/O.
2. Mesurez la pression softirq et les drops NIC. Si vous perdez avant qu’OpenVPN voie les paquets, régler OpenVPN est cosmétique.
3. Vérifiez le chiffrement et les options d’offload noyau. Si vous avez un chiffrement lent ou pas de DCO, vous le ressentirez.

Troisième étape : valider le routage/NAT et le placement des files d’attente

1. Vérifiez qdisc et bufferbloat. Une mauvaise politique de file peut ajouter une grosse latence sous charge.
2. Confirmez le routage correct. Si le trafic fait un hairpin à travers un pare-feu ou traverse inutilement des AZ, votre « problème VPN » est topologique.
3. Mesurez le débit avec et sans tunnel. Vous avez besoin d’une base pour éviter de chasser des fantômes.

Tâches pratiques avec commandes : quoi lancer, ce que ça signifie, ce que vous décidez

Ces tâches supposent un serveur OpenVPN sous Linux. Ajustez les chemins pour votre distro. Chaque tâche inclut : commande, exemple de sortie, signification, et décision.
Exécutez-les dans cet ordre approximatif quand vous êtes en mode feu de production.

Task 1: Confirm OpenVPN is using UDP (not TCP)

cr0x@server:~$ sudo ss -lunpt | grep openvpn
udp   UNCONN 0      0            0.0.0.0:1194       0.0.0.0:*    users:(("openvpn",pid=1324,fd=6))

Ce que cela signifie : Le serveur écoute sur UDP/1194. Si vous voyez tcp à la place, attendez-vous à de moins bonnes performances en cas de perte.
Décision : Si TCP est présent par accident, basculez sur UDP sauf contrainte stricte de pare-feu.

Task 2: Check negotiated cipher and data channel parameters

cr0x@server:~$ sudo journalctl -u openvpn-server@server --since "1 hour ago" | egrep -i "Data Channel|Cipher|peer info" | tail -n 8
Dec 27 09:20:11 server openvpn[1324]: Control Channel: TLSv1.3, cipher TLS_AES_256_GCM_SHA384
Dec 27 09:20:11 server openvpn[1324]: [client1] Peer Connection Initiated with [AF_INET]203.0.113.10:51234
Dec 27 09:20:11 server openvpn[1324]: [client1] Data Channel: cipher 'AES-256-GCM', peer-id: 0

Ce que cela signifie : Vous êtes en AES-256-GCM pour le canal de données. Bon défaut sur matériel AES-NI.
Décision : Si vous voyez des chiffrements seulement CBC ou des réglages legacy, modernisez. Si des clients sont sur ARM faible, envisagez ChaCha20 si votre pile OpenVPN le supporte.

Task 3: Check whether DCO is active (if you expect it)

cr0x@server:~$ sudo modprobe -n ovpn-dco && lsmod | grep ovpn
insmod /lib/modules/6.1.0-18-amd64/kernel/drivers/net/ovpn/ovpn-dco.ko
ovpn_dco               94208  0

Ce que cela signifie : Le module DCO existe et est chargé.
Décision : Si vous attendiez DCO mais qu’il manque, arrêtez de tuner l’espace utilisateur en premier. Corrigez la capacité plateforme et les choix de build/package OpenVPN.

Task 4: Measure server CPU saturation and single-thread pinning

cr0x@server:~$ top -b -n 1 | head -n 12
top - 09:31:02 up 32 days,  3:11,  2 users,  load average: 3.12, 2.98, 2.71
Tasks: 189 total,   1 running, 188 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.3 us,  2.1 sy,  0.0 ni, 85.2 id,  0.0 wa,  0.0 hi,  0.4 si,  0.0 st
MiB Mem :  32118.5 total,  11234.7 free,   4231.9 used,  16651.9 buff/cache
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1324 nobody    20   0  143832  21572   9856 R  98.7   0.1  10:44.02 openvpn

Ce que cela signifie : OpenVPN consomme un cœur CPU (~99%). C’est un comportement classique de plafond de débit pour OpenVPN en espace utilisateur.
Décision : Si cela corrèle avec « VPN lent », vous êtes limité par le CPU/le taux de paquets. Envisagez DCO, une montée en horizontal, ou migrer des charges vers WireGuard.

Task 5: Confirm AES-NI / crypto acceleration is available

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

Ce que cela signifie : Le CPU a les flags AES et PCLMULQDQ — bons signes pour AES-GCM rapide.
Décision : Si les flags AES sont absents (commun sur certaines petites VMs ou vieux matériels), attendez-vous à ce qu’AES-GCM soit plus lent. Envisagez ChaCha20 si votre pile OpenVPN le supporte proprement.

Task 6: Check NIC errors and drops (don’t blame OpenVPN for a bad NIC day)

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    9876543210 8432190      0    1274       0  10233
    TX:  bytes packets errors dropped carrier collsns
    8765432109 7321987      0       9       0      0

Ce que cela signifie : Des drops RX existent. Cela peut venir de rafales, de limites du ring buffer, ou de congestion amont.
Décision : Si les drops augmentent pendant les plaintes, investiguez les queues NIC, le driver et la congestion de l’hôte avant d’éditer les configs OpenVPN.

Task 7: Look for UDP receive buffer pressure

cr0x@server:~$ netstat -su | egrep -i "receive errors|packet receive errors|RcvbufErrors|InErrors"
    204 packet receive errors
    198 RcvbufErrors

Ce que cela signifie : Le noyau jette des paquets UDP à cause de limites de buffer de réception.
Décision : Augmentez les buffers de socket et revoyez les réglages sysctl ; sinon vous poursuivrez une « lenteur VPN » qui est en réalité des drops noyau.

Task 8: Inspect key sysctls for UDP buffers and forwarding

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

Ce que cela signifie : Les buffers sont petits pour un serveur VPN chargé.
Décision : Si vous avez vu RcvbufErrors, augmentez-les prudemment et surveillez. Si ip_forward est désactivé, le routage cassera et vous aurez « VPN connecté mais rien ne fonctionne ».

Task 9: Confirm routing and that return paths exist

cr0x@server:~$ ip route show table main | head
default via 198.51.100.1 dev eth0
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
198.51.100.0/24 dev eth0 proto kernel scope link src 198.51.100.20

Ce que cela signifie : Le sous-réseau VPN existe et est attaché à tun0.
Décision : Si la route manque, votre instance OpenVPN ne crée pas le dispositif tunnel ou est mal configurée. Corrigez cela avant le travail de performance.

Task 10: Check NAT rules if clients need internet access

cr0x@server:~$ sudo iptables -t nat -S | egrep 'POSTROUTING|MASQUERADE'
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Ce que cela signifie : Le trafic client VPN est NATé vers l’extérieur sur eth0.
Décision : Si les clients se plaignent « connecté mais pas d’internet », l’absence de NAT est un suspect habituel (si vous faites full-tunnel).

Task 11: Detect MTU blackholes with ping + DF (don’t fragment)

cr0x@server:~$ ping -c 3 -M do -s 1472 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=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420

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

Ce que cela signifie : Le MTU effectif le long du chemin (depuis ce contexte d’hôte/interface) est autour de 1420. Votre hypothèse 1500 échoue.
Décision : Définissez un MTU tunnel approprié et/ou clamptez le MSS. Si vous ignorez cela, vous aurez des blocages intermittents et « marche sur Wi‑Fi, échoue sur LTE ».

Task 12: Check MSS clamping is in place (when routing/NAT requires it)

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

Ce que cela signifie : Le MSS est clampé selon le PMTU, réduisant les problèmes de fragmentation pour les flux TCP.
Décision : Si absent et que vous avez des problèmes MTU, ajoutez le clamp et retestez le symptôme « certains sites bloquent ».

Task 13: Measure baseline throughput outside the VPN

cr0x@server:~$ iperf3 -c 198.51.100.50 -P 4 -t 10
[SUM]   0.00-10.00  sec  4.82 GBytes  4.14 Gbits/sec  0             sender
[SUM]   0.00-10.00  sec  4.78 GBytes  4.10 Gbits/sec  12            receiver

Ce que cela signifie : Le chemin réseau brut peut faire ~4.1 Gbit/s.
Décision : Si le débit VPN est bien inférieur, ce n’est pas la montée ; c’est votre traitement de tunnel, MTU, ou contraintes endpoint.

Task 14: Measure throughput through the VPN (server-to-client or client-to-server)

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

Ce que cela signifie : Vous êtes prêt à tester depuis un client VPN connecté vers l’IP VPN du serveur.
Décision : Comparez le débit VPN vs non-VPN. Si l’écart est énorme et que le CPU du serveur est saturé, vous avez trouvé votre limite.

Task 15: Inspect qdisc (queue discipline) for latency under load

cr0x@server:~$ tc -s qdisc show dev eth0
qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
 Sent 8765432109 bytes 7321987 pkt (dropped 9, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0

Ce que cela signifie : fq_codel est actif, les drops sont faibles, le backlog est vide. C’est généralement bon pour la latence.
Décision : Si vous voyez un qdisc FIFO basique et un gros backlog, attendez-vous à du bufferbloat. Corrigez le shaping avant de blâmer le VPN.

Task 16: Check per-process packet rate and context switches

cr0x@server:~$ pidstat -p $(pgrep -n openvpn) -w 1 3
Linux 6.1.0-18-amd64 (server)  12/27/2025  _x86_64_  (8 CPU)

09:44:01      UID       PID   cswch/s nvcswch/s  Command
09:44:02      65534    1324    120.00   8400.00  openvpn
09:44:02      65534    1324    115.00   8600.00  openvpn
09:44:03      65534    1324    118.00   8550.00  openvpn

Ce que cela signifie : Beaucoup de changements de contexte non volontaires peuvent indiquer contention et pression du scheduler, fréquent quand un datapath en espace utilisateur est chargé.
Décision : Si c’est élevé pendant les tests de débit, vous bénéficierez de DCO, d’une réduction du nombre de paquets (MTU/agrégation), ou de déplacer les flux lourds vers un tunnel plus efficace.

Trois mini-histoires en entreprise (réalistes, anonymisées, un peu douloureuses)

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a déployé OpenVPN pour connecter des sites de vente au siège. Le déploiement avait l’air propre : même modèle d’appliance, même template de config,
même niveau ISP sur le papier. Ils ont validé un site pilote puis l’ont cloné quarante fois.

Deux semaines plus tard, les appels au support ont commencé : « l’outil d’inventaire ne répond pas », « le lot de cartes de crédit échoue », « le VPN est instable ». Le VPN restait connecté.
Les pings fonctionnaient. Mais les gros transferts se bloquaient de façon imprévisible. Les ingénieurs ont fait ce que font les ingénieurs sous pression : ils ont changé les chiffrements et augmenté les keepalives.
Rien n’a changé.

La mauvaise hypothèse était simple : « le MTU est 1500 partout ». Plusieurs ISP livraient en PPPoE ou des liens contraints.
À l’intérieur du tunnel, les paquets grossissaient, se fragmentaient, et certains chemins perdaient les fragments. Blackholing classique de PMTU.
Les blocages étaient surtout visibles sur de grosses réponses HTTPS et des requêtes base de données avec de grands jeux de résultats.

La correction était ennuyeuse : imposer le clamp MSS, définir un MTU tunnel conservateur, et retester depuis les pires sites.
L’incident s’est clos sans héroïsme, juste de l’humilité et une note permanente dans la checklist de déploiement :
ne jamais supposer le MTU, le mesurer toujours.

Mini-histoire 2 : L’optimisation qui a mal tourné

Une équipe plateforme interne voulait plus de débit de leur concentrateur OpenVPN. Ils ont trouvé un vieux billet de blog suggérant d’augmenter les buffers socket
et ont monté net.core.rmem_max et wmem_max de façon dramatique. Ils ont aussi augmenté les buffers internes d’OpenVPN.
Les tests synthétiques se sont améliorés sur un réseau de labo propre. Ils ont déployé.

Un mois plus tard, une autre plainte est arrivée : « le VPN est saccadé pendant les appels ». Pas « téléchargements lents » — latence. Les réunions vidéo bégayaient.
Les sessions SSH semblaient collantes. Les graphiques de débit étaient corrects. L’équipe était confuse, ce qui est une émotion populaire en entreprise.

Le retour de bâton était le queueing. D’énormes buffers plus un lien occupé ont créé du bufferbloat : les paquets restaient en file plus longtemps, et le trafic interactif en souffrait.
La voix et la vidéo sont sensibles à la latence. Elles se fichent que votre tunnel puisse pousser plus de bits par seconde si ces bits arrivent en retard.

Ils ont fait un rollback vers des buffers modérés, activé fq_codel sur l’interface de sortie, et limité légèrement le shaping en dessous du débit physique
pour contrôler l’emplacement de la file. Le débit a un peu baissé. L’expérience utilisateur s’est beaucoup améliorée. La leçon réelle : « plus rapide » n’est pas une grandeur unique.
Ça dépend de ce que font vos utilisateurs et de ce que votre réseau cache.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une organisation attentive à la sécurité exploitait à la fois WireGuard et OpenVPN : WireGuard pour les laptops gérés, OpenVPN pour les contractuels et les « appareils bizarres »
incapables d’exécuter le client standard. Le service OpenVPN n’était pas glamour, donc il était traité comme tout autre service production :
versions de paquets figées, fenêtre de changement et un canari.

Un jour, ils ont dû faire une rotation de certificats et ajuster les préférences de chiffrements pour la conformité. Le changement était planifié et testé.
Le groupe canari était petit mais divers : un client macOS, un client Windows, un client Linux, un client mobile.
Ils ont surveillé les logs pour les échecs de négociation et mesuré le débit et les taux de reconnexion.

Le canari a révélé une surprise : un ancien client contractuel ne supportait pas la nouvelle combinaison de suites de chiffrements choisie par l’équipe.
En production à grande échelle, cela serait devenu un incident du lundi matin avec une audience exécutive.
Au lieu de cela, ils ont ajusté la liste de chiffrements pour conserver un fallback compatible et diffusé une recommandation de mise à jour client.

Rien de dramatique ne s’est produit. C’est le but. La pratique ennuyeuse — canari plus petite matrice de compatibilité — a évité une panne de compatibilité.
Vous n’obtenez pas de trophée pour ça. Vous obtenez le droit de déjeuner.

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

1) « Le VPN est connecté, mais certains sites ne finissent jamais de se charger »

Cause racine : MTU/PMTU blackholing ; fragments perdus sur certains chemins ; absence de clamp MSS.
Correction : Mesurez le MTU effectif avec des pings DF ; clamptez le MSS (TCPMSS --clamp-mss-to-pmtu) ; définissez un tun-mtu conservateur si nécessaire.

2) « C’est rapide sur le Wi‑Fi du bureau mais terrible sur LTE ou réseaux d’hôtel »

Cause racine : pertes/gigue du chemin plus pression des buffers UDP ; parfois UDP est bridé par des réseaux captifs ; variabilité MTU.
Correction : Assurez-vous que les buffers UDP ne drop pas ; envisagez un listener TCP secondaire uniquement pour réseaux hostiles ; tunez le MTU ; validez avec des tests réels.

3) « Le débit plafonne à ~100–300 Mbps sur un gros serveur »

Cause racine : OpenVPN en espace utilisateur est limité par le CPU/le taux de paquets ; un cœur est saturé ; chiffrement lent ou pas d’accélération AES.
Correction : Passez à AES-GCM avec support matériel ; activez DCO si possible ; scale-out horizontal ; envisagez WireGuard pour des charges de débit important.

4) « La latence explose pendant de gros téléchargements »

Cause racine : bufferbloat dû à des buffers surdimensionnés ou un mauvais qdisc ; uplink congestionné ; files vivant au mauvais endroit.
Correction : Utilisez fq_codel ou CAKE ; shapez légèrement en dessous de l’uplink ; n’augmentez pas aveuglément les buffers socket.

5) « Les clients se connectent, mais n’atteignent pas les sous-réseaux internes »

Cause racine : routes manquantes sur le serveur ou les routeurs en aval ; ip_forward désactivé ; conflits de routage policy/NAT.
Correction : Confirmez que les routes existent, activez le forwarding, poussez les routes correctes, assurez le routage de retour correct (ne comptez pas sur le NAT accidentel).

6) « Déconnexions aléatoires ou blocages sous charge »

Cause racine : pertes de paquets, drops UDP, erreurs de buffer de réception, ou serveur surchargé causant des keepalives retardés.
Correction : Vérifiez netstat -su erreurs, drops NIC, saturation CPU ; réduisez le taux de paquets ; augmentez les buffers prudemment ; scale-out.

7) « C’est devenu plus lent après activation de la compression »

Cause racine : La compression ajoute une charge CPU et peut mal interagir avec du trafic chiffré moderne (déjà compressé) et des contraintes de sécurité.
Correction : Désactivez la compression pour le canal de données ; concentrez-vous sur MTU, crypto et routage. La compression n’est pas un plat gratuit ; souvent ce n’est même pas un plat.

8) « Nous sommes passés à TCP pour plus de fiabilité, et maintenant c’est pire »

Cause racine : meltdown TCP-over-TCP sous perte et réordonnancement.
Correction : Utilisez UDP. Si bloqué, proposez TCP comme profil de secours uniquement, et fixez les attentes : c’est un mode de compatibilité, pas de performance.

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

Étape par étape : une base OpenVPN correcte pour la production

1. Choisissez le mode routé TUN sauf si vous avez vraiment besoin de bridging L2.
2. Utilisez UDP comme transport par défaut.
3. Sélectionnez des chiffrements modernes (AES-GCM sur serveurs AES-NI ; évitez les setups legacy CBC-only).
4. Désactivez la compression pour le canal de données dans les environnements modernes.
5. Planifiez le MTU : testez les pings DF ; clamptez le MSS pour les flux TCP.
6. Mettez en place le routage correctement : poussez les routes délibérément ; assurez les chemins de retour.
7. Décidez NAT vs routé pour l’accès Internet des clients et la reachabilité interne. Documentez le choix.
8. Observabilité : journalisez les négociations, connexions clients, raisons de déconnexion ; collectez CPU, drops et compteurs d’erreurs UDP.
9. Test de capacité avec iperf3 à travers le tunnel avec concurrence et tailles de paquets réalistes.
10. Ayez un profil de secours (TCP ou port alternatif) pour les réseaux hostiles — clairement étiqueté comme plus lent.
11. Automatisez la distribution des configs client et gardez une petite matrice de compatibilité.
12. Cadence de correctifs : traitez OpenVPN comme tout autre service edge. Fenêtres de changement et canaris.

Étape par étape : décider de garder OpenVPN ou migrer vers WireGuard

1. Mesurez le plafond actuel : débit VPN vs utilisation CPU et drops de paquets.
2. Si un cœur est saturé, évaluez DCO en premier si vous avez besoin des fonctionnalités OpenVPN.
3. Si vous avez surtout besoin de site-to-site ou clients gérés, WireGuard est souvent plus simple opérationnellement et plus rapide.
4. Gardez OpenVPN pour les environnements nécessitant des flux d’auth entreprise matures et une large compatibilité client.
5. Faites un pilote : un petit groupe sur WireGuard ; comparez la latence sous charge, le comportement de reconnexion et la charge de support.

FAQ

OpenVPN est-il intrinsèquement lent ?

Non. Il est souvent plus lent que WireGuard à des taux de paquets élevés parce qu’OpenVPN classique exécute le datapath en espace utilisateur et paie une surcharge.
Avec de bonnes configs et le support DCO, OpenVPN peut être suffisamment rapide pour beaucoup d’organisations.

Pourquoi OpenVPN utilise-t-il parfois un seul cœur CPU à 100 % ?

Le chiffrement/déchiffrement et le mouvement des paquets entre noyau et espace utilisateur peuvent devenir des hot paths monothreads.
Les petits paquets aggravent le phénomène car le taux de paquets augmente. Le symptôme est un cœur coincé pendant que les autres dorment.

Dois-je faire tourner OpenVPN sur TCP pour la fiabilité ?

Pas par défaut. Le meltdown TCP-over-TCP est un mode de défaillance classique sous perte. Utilisez UDP sauf si vos clients sont dans des réseaux qui le bloquent.
Si vous devez proposer TCP, traitez-le comme un profil de secours.

Quel est le bug de performance OpenVPN le plus courant ?

Les problèmes de MTU. Ils se déguisent en « lenteurs aléatoires » et « certains sites ne marchent pas ». Mesurez le MTU et clamptez le MSS.
Ce n’est pas glamour, ce qui explique pourquoi ça arrive encore.

AES-256-GCM rend-il OpenVPN plus lent que AES-128-GCM ?

Parfois un peu, selon le CPU et l’implémentation, mais les gains plus importants viennent généralement de l’architecture et du taux de paquets.
Ne poursuivez pas des micro-optimisations tant que vous n’avez pas confirmé que vous êtes limité par le CPU et que vous utilisez l’accélération matérielle.

Comment savoir si je suis limité par la perte de paquets vs le CPU ?

Si le serveur montre des erreurs de buffer de réception UDP, des drops NIC ou de la perte sur le chemin (et le CPU n’est pas saturé), vous êtes probablement limité par la perte/congestion.
Si OpenVPN est coincé à ~100% sur un cœur pendant les tests, vous êtes probablement limité par le CPU/le taux de paquets.

WireGuard est-il toujours plus rapide ?

Souvent, mais pas toujours. Si votre goulot d’étranglement est l’ISP, le Wi‑Fi, la perte LTE ou le CPU du client distant, changer de VPN ne créera pas de bande passante.
L’avantage de WireGuard est le plus marqué sur Linux où le datapath in-kernel et le protocole léger réduisent la surcharge.

Puis-je simplement augmenter les buffers pour rendre OpenVPN plus rapide ?

Augmenter les buffers peut réduire les drops, mais peut aussi augmenter la latence et rendre les usages interactifs insupportables.
Tuner les buffers en fonction des drops mesurés et de la latence sous charge, et conservez des disciplines de file sensées en sortie.

Qu’est-ce que OpenVPN DCO et devrais-je l’utiliser ?

DCO (Data Channel Offload) déplace plus de traitement de paquets dans le noyau, réduisant la surcharge en espace utilisateur.
Si vous avez besoin des fonctionnalités d’OpenVPN mais souhaitez un meilleur débit/latence, c’est à évaluer — prudemment, avec canaris et tests de compatibilité client.

Quand devrais-je garder OpenVPN au lieu de migrer ?

Si vous dépendez d’intégrations d’auth entreprise matures, de pushes de politiques complexes, ou d’une large compatibilité client tierce, OpenVPN reste pratique.
Vous pouvez aussi exécuter les deux : WireGuard pour les endpoints gérés, OpenVPN pour « tout le reste ».

Conclusion : que faire ensuite

Si vous voulez qu’OpenVPN se comporte, rendez-le ennuyeux : UDP, TUN routé, chiffrements modernes, pas de compression, et gestion délibérée du MTU.
Ensuite, instrumentez-le sérieusement — CPU, drops, erreurs de buffer UDP et file d’attente.

Si vous avez besoin du plus haut débit et de la plus faible latence à l’échelle sur Linux, WireGuard gagne souvent car il a été conçu pour éviter la taxe de l’espace utilisateur.
Si vous avez besoin de l’écosystème et des contrôles d’OpenVPN, envisagez DCO et des architectures scale-out. Dans tous les cas : mesurez d’abord, changez ensuite, et notez ce que vous avez appris pour ne pas le réapprendre à 2 h du matin.