WireGuard ou OpenVPN : lequel choisir pour son serveur ?

La réponse courte

Pour une personne qui exploite un serveur VPN sur son propre VPS, le choix entre WireGuard et OpenVPN ne se discute presque pas : choisissez WireGuard. Il est plus compact, s’exécute dans le noyau Linux, établit la connexion en une fraction de seconde et sa configuration client fonctionnelle tient en une dizaine de lignes. OpenVPN conserve quatre usages réels. Si aucun ne vous concerne, vous n’en avez pas besoin.

Ces quatre usages sont les suivants : sortir d’un réseau qui n’autorise que le port TCP 443, s’intégrer à une autorité de certification existante, authentifier des utilisateurs nommément avec un mot de passe ou un second facteur, et faire du bridging au niveau 2. La suite présente les éléments qui justifient cette recommandation et indique précisément à partir de quel moment chaque exception peut vous concerner.

Pourquoi WireGuard s’est imposé auprès des auto-hébergeurs

Le code est suffisamment court pour être lu. Le projet WireGuard implémente son protocole dans environ 4,000 lignes de code. OpenVPN dépasse les 100,000 lignes si l’on compte la bibliothèque OpenSSL dont il dépend pour chaque opération cryptographique. La taille compte, car chaque ligne constitue une surface d’attaque, et ni vous ni votre relecteur ne lirez 100,000 lignes. Vous pouvez en lire 4,000.

Il s’exécute dans le kernel. WireGuard fait partie du kernel Linux mainline depuis la version 5.6. Ubuntu 24.04 et Debian 13 le fournissent donc sans rien compiler. Les paquets sont chiffrés là où ils se trouvent déjà, dans l’espace kernel, sans copie vers un processus userspace puis retour. Vérifiez ce point avant toute autre chose :

sudo modprobe wireguard && echo ok

Sur un VPS KVM, cette commande affiche ok. Dans une virtualisation par conteneurs qui partage le kernel de l’hôte, comme OpenVZ ou LXC, elle échoue avec Operation not supported, car vous ne pouvez pas charger un module dans un kernel qui ne vous appartient pas.

Il n’y a rien à négocier. WireGuard utilise une suite cryptographique fixe : ChaCha20-Poly1305 pour les données, avec des clés Curve25519. Il n’y a aucune version à rétrograder ni aucune option à mal configurer. OpenVPN négocie la suite cryptographique et la version de TLS (transport layer security) avec chaque client. Cette flexibilité est aussi une source de mauvaises configurations. Un serveur configuré avec data-ciphers AES-256-GCM:AES-128-CBC repasse sans problème au chiffrement CBC pour un client qui ne propose rien de mieux, et le journal n’indique pas que ce chiffrement est plus faible. Lorsque le data channel offload est disponible, OpenVPN indique que l’entrée CBC a désactivé l’offload. Cet avertissement concerne la vitesse, pas la sécurité.

Le port ne répond pas. Un paquet WireGuard dont la vérification d’authentification du message échoue est abandonné sans aucune réponse. Ainsi, nmap -sU -p 51820 ne peut pas distinguer un serveur WireGuard d’un port que le firewall abandonne silencieusement : dans les deux cas, le résultat est open|filtered. Seul un port non filtré sur lequel rien n’écoute se signale, car le kernel répond avec un message ICMP port unreachable et nmap l’indique comme closed. En mode TCP, un serveur OpenVPN termine le handshake TCP avant de décider que vous n’êtes pas autorisé. Cela suffit à prouver à un scanner qu’un service est présent. OpenVPN sur UDP avec tls-crypt est presque aussi discret. Il s’agit donc d’un argument contre l’exécution d’OpenVPN sur TCP, et non contre OpenVPN lui-même.

L’itinérance est native. Un peer WireGuard est identifié par sa clé publique, et non par son adresse. Votre ordinateur portable passe du réseau domestique à un hotspot mobile, envoie un handshake depuis la nouvelle adresse, puis le serveur met à jour l’endpoint auquel il répond. Rien ne se reconnecte, car rien n’a jamais été connecté. OpenVPN peut faire quelque chose de similaire avec float, mais le client ferme et recrée généralement une session TLS complète. C’est pourquoi la pause à l’ouverture du capot est perceptible avec OpenVPN, mais pas avec WireGuard.

Vitesse en 2026 : l’écart se réduit uniquement avec le déchargement dans le kernel

Pendant des années, l’argument honnête en matière de performances était qu’OpenVPN copiait chaque paquet dans l’espace utilisateur, l’y chiffr ait, puis le recopiait, tandis que WireGuard ne quittait jamais le kernel. Sur un serveur Ubuntu 24.04 standard, c’est toujours le cas, et WireGuard est nettement plus rapide. Ce qui a changé en 2026, c’est qu’OpenVPN peut désormais déplacer aussi son chemin de données dans le kernel, lorsque le kernel et la version d’OpenVPN le prennent en charge. Une comparaison qui ignore ce point n’est plus à jour.

OpenVPN 2.7, publié en février 2026, prend en charge le module kernel ovpn en amont, intégré à Linux 6.16. Il s’agit de DCO (data channel offload) : le canal de contrôle reste dans l’espace utilisateur, tandis que le chemin principal des données passe dans le kernel. C’est à peu près ce que WireGuard fait depuis toujours. Avec un kernel et une version d’OpenVPN suffisamment récents pour l’utiliser, le débit est du même ordre, et non dans une catégorie différente. Vérifiez ce qui est réellement installé :

uname -r
openvpn --version | head -n 1
modinfo ovpn 2>/dev/null | head -n 3

En octobre 2026, Ubuntu 24.04 LTS fournit OpenVPN 2.6, et non 2.7. Le module ovpn nécessite la version 2.7. Avec cette version d’Ubuntu, le déchargement n’est possible qu’au moyen de l’ancien paquet openvpn-dco-dkms, qui compile un module externe contre le kernel en cours d’exécution et doit donc être recompilé après chaque mise à niveau du kernel. WireGuard n’a pas cette contrainte. Ubuntu 26.04 LTS fournit OpenVPN 2.7.0 et un kernel Linux 7.0, tous deux suffisamment récents pour ovpn. Dans cette version, la ligne modinfo ci-dessus est donc celle qu’il faut vérifier.

Lisez les limitations de DCO avant de le considérer comme une raison de rester avec OpenVPN. Il prend uniquement en charge les tunnels de couche 3, accepte seulement les chiffrements AEAD (authenticated encryption with associated data : AES-GCM ou ChaCha20-Poly1305), ne prend pas en charge la compression et, sur un serveur, fonctionne uniquement avec topology subnet. Chacune de ces restrictions réduit une partie de la souplesse qui constituait précisément l’argument d’OpenVPN. Un OpenVPN rapide est un OpenVPN configuré pour fonctionner comme WireGuard.

Ne faites confiance à aucun chiffre de débit publié, y compris ceux de cette page. Sur un VPS, le plafond vient généralement de la capacité CPU ou réseau disponible, et non du protocole. Mesurez votre propre débit avec iperf3 exécuté à travers le tunnel, puis à nouveau sans le tunnel, et comparez les deux résultats.

Dans quels cas OpenVPN reste pertinent

Vous devez sortir par le port TCP 443. WireGuard fonctionne uniquement sur UDP, de manière délibérée, et aucun mode TCP n’est prévu. Un réseau d’hôtel qui filtre uniquement selon le numéro de port laissera généralement passer OpenVPN configuré avec proto tcp-server et port 443. Ne confondez pas cela avec une dissimulation : OpenVPN sur TCP utilise son propre framing des paquets, et non une session TLS ordinaire. Un firewall ou un proxy d’entreprise qui inspecte ou termine HTTPS peut donc toujours le reconnaître et le bloquer. WireGuard a besoin d’un wrapper comme wstunnel ou udp2raw pour traverser le même réseau. Cela ajoute un processus à exécuter et à maintenir à jour. Notez le conflit : si un serveur web utilise déjà TCP 443 sur cette adresse IP, l’un des deux devra être déplacé.

Vous utilisez déjà une autorité de certification. OpenVPN s’authentifie avec des certificats X.509. Il s’intègre donc dans une PKI (public key infrastructure) que vous exploitez déjà. Les certificats expirent automatiquement. Pour révoquer un certificat, il suffit de l’ajouter à une certificate revocation list que le serveur lit via crl-verify. WireGuard n’utilise ni certificats, ni expiration, ni certificate revocation list. Pour supprimer un peer, vous devez modifier la configuration du serveur et la recharger. Avec dix peers, cela ne pose pas de problème. Avec quatre cents peers et une obligation d’audit, le modèle fondé sur les certificats vous apporte un réel avantage.

Vous avez besoin d’utilisateurs nommés, et pas uniquement de clés. OpenVPN peut déléguer l’authentification à un système externe avec auth-user-pass-verify ou avec un plugin comme openvpn-plugin-auth-pam.so. C’est ainsi que l’on ajoute LDAP ou un second facteur à usage unique. WireGuard ne connaît pas la notion d’utilisateur. Une clé est présente dans la configuration ou elle ne l’est pas. Si votre exigence est « Sara doit saisir un code affiché sur son téléphone », WireGuard ne peut pas l’exprimer seul.

Vous avez besoin de la couche 2 ou d’un client pour un système ancien. OpenVPN avec dev tap établit un bridge de trames Ethernet. Cela est utile pour les protocoles de broadcast et les anciens jeux en réseau local. WireGuard fonctionne uniquement en couche 3, et cela ne changera pas. OpenVPN propose également des clients pour du matériel et des systèmes d’exploitation qui n’auront jamais d’application WireGuard. Ces deux raisons deviennent moins fréquentes. De plus, dev tap est incompatible avec DCO. Le bridge impose donc le chemin lent.

Ce que les deux configurations vous coûtent réellement

Une identité WireGuard se crée avec une seule commande. Les parenthèses sont importantes, car elles définissent le mode du fichier avant la création de la clé :

(umask 077; wg genkey > private.key)
wg pubkey < private.key > public.key

L’équivalent OpenVPN est une autorité de certification dont vous êtes désormais responsable pendant toute la durée d’utilisation du VPN :

sudo apt install -y easy-rsa
make-cadir ~/openvpn-ca
cd ~/openvpn-ca
./easyrsa init-pki
./easyrsa build-ca
./easyrsa gen-req server nopass
./easyrsa sign-req server server

Aucune des deux listes n’est partiale. L’autorité de certification vous apporte la gestion de l’expiration et de la révocation. En contrepartie, vous devez protéger une clé privée pendant des années, penser à son renouvellement et reconstruire l’infrastructure si vous la perdez. Si vous n’utilisez pas ces fonctions, vous les payez pour rien. La procédure WireGuard complète, avec le forwarding, le NAT (network address translation) et les échecs de handshake qui peuvent vous faire perdre un après-midi, est décrite dans le guide pour auto-héberger un VPN WireGuard sur votre VPS.

Ce que chaque solution exige de votre pare-feu

WireGuard nécessite exactement une règle entrante pour UDP, sur le port indiqué dans ListenPort :

sudo ufw allow 51820/udp
sudo ufw status verbose

OpenVPN nécessite par défaut UDP 1194, ou TCP 443 si vous avez choisi cette option. Dans les deux cas, vous devez ensuite activer le forwarding IP et ajouter une règle de NAT source, car Linux supprime les paquets qui ne lui sont pas destinés. Cette partie est identique pour les deux protocoles. C’est aussi la cause de la plupart des signalements du type « le tunnel se connecte, mais Internet ne fonctionne pas ». Si ufw ne vous est pas familier, commencez par les bases du pare-feu ufw sur un VPS, et n’oubliez pas que la plupart des fournisseurs proposent un second pare-feu réseau dans leur panneau de contrôle : une règle ajoutée sur le serveur ne sert à rien si le paquet n’atteint jamais le serveur. Comprendre ce qu’est un port et comment Linux écoute sur un port accélère ces deux vérifications.

Comment choisir, en un paragraphe

Utilisez WireGuard, sauf si vous pouvez nommer précisément ce qu’il ne peut pas faire pour vous. Si vous avez besoin de TCP 443 pour contourner un réseau restrictif, utilisez OpenVPN sur ce port et envisagez d’exécuter les deux : ils utilisent des ports différents et coexistent sur un même serveur sans conflit. Si vous avez besoin de comptes par utilisateur ou d’un second facteur, n’essayez pas de faire gérer ces fonctions à WireGuard. Ajoutez plutôt une couche d’identité au-dessus. Un serveur de contrôle Headscale auto-hébergé utilise WireGuard en dessous et ajoute le modèle de comptes, la distribution des clés et l’approbation des appareils que WireGuard seul vous laisse gérer.

Migrer depuis OpenVPN sans interruption de service

Il n’existe pas de conversion. La PKI d’OpenVPN ne devient pas des clés WireGuard, car WireGuard n’utilise pas de certificats à convertir. Chaque client reçoit une nouvelle paire de clés, générée de la même manière que celle du serveur.

Effectuez la migration en parallèle au lieu de basculer directement. WireGuard sur UDP 51820 et OpenVPN sur 1194 peuvent fonctionner simultanément sur le même serveur. Activez donc wg0, vérifiez son fonctionnement avec sudo wg show en affichant un latest handshake récent, puis migrez les clients un par un. Lorsque la liste des pairs OpenVPN ne change plus, arrêtez le service avec sudo systemctl disable --now openvpn-server@server. Conservez les fichiers de l’autorité de certification jusqu’à ce que vous soyez certain de ne plus en avoir besoin. Il est impossible de recréer un client révoqué si l’autorité de certification a été supprimée.

Un élément ne peut réellement pas être transféré : les comptes associés aux noms d’utilisateur et aux mots de passe, ainsi que l’historique des révocations qui leur est associé. Déterminez où ces informations seront conservées avant d’arrêter l’ancien serveur, et non après.

FAQ

WireGuard est-il plus rapide qu’OpenVPN ?

Sur un serveur Ubuntu 24.04 standard, oui, et avec une nette différence, car WireGuard chiffre les données dans le kernel, tandis qu’OpenVPN 2.6 fait passer chaque paquet par un processus en userspace. Avec OpenVPN 2.7 et le module kernel ovpn de Linux 6.16, le chemin de données passe également dans le kernel, et les deux solutions sont dans la même catégorie. Mesurez les performances de votre propre installation avec iperf3 à travers le tunnel au lieu de faire confiance à un chiffre publié sur un blog, car sur un VPS, la limite vient généralement du CPU ou du quota de bande passante.

WireGuard peut-il fonctionner sur le port TCP 443 ?

Pas seul. WireGuard fonctionne uniquement en UDP par conception, et aucun mode TCP n’est prévu. Pour traverser un réseau qui n’autorise que TCP 443, encapsulez-le dans un tunnel comme wstunnel ou udp2raw, ce qui ajoute un processus à exécuter et à maintenir des deux côtés. Si cette restriction est habituelle dans votre environnement de travail, OpenVPN avec proto tcp-server et port 443 est la solution la plus simple sur un réseau qui filtre uniquement selon le port. Toutefois, un proxy qui inspecte HTTPS peut toujours le détecter et le bloquer.

OpenVPN n’est-il plus sécurisé ?

Non. Un OpenVPN récent utilisant un chiffrement AEAD tel que AES-256-GCM, avec tls-crypt activé, constitue un VPN fiable. L’intérêt de WireGuard repose sur un autre point : OpenVPN contient beaucoup plus de code et beaucoup plus d’options. Il offre donc à un administrateur fatigué davantage de possibilités de mal le configurer. Moins de choix signifie moins de mauvaises configurations.

Lequel choisir pour un VPN personnel sur un VPS ?

WireGuard. Une paire de clés par appareil, un fichier de configuration d’environ dix lignes, un seul port UDP ouvert et un handshake qui se termine avant même que vous remarquiez qu’il a commencé. Choisissez OpenVPN uniquement si vous vous connectez régulièrement depuis des réseaux qui bloquent l’UDP, ou si vous devez vous intégrer à une autorité de certification ou à un annuaire d’utilisateurs déjà en place.