WireGuard ou OpenVPN : lequel auto-héberger ?

La réponse courte

Pour une seule personne qui exécute un serveur VPN sur son propre VPS, le choix entre WireGuard et OpenVPN ne fait guère débat : 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 cas d’usage réels. Si aucun ne vous concerne, vous n’en avez pas besoin.

Ces quatre cas d’usage 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és avec un mot de passe ou un second facteur, et fonctionner en mode bridge de couche 2. La suite présente les éléments qui justifient cette recommandation et précise le point exact à partir duquel chaque exception commence à vous concerner.

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

Le code est suffisamment compact pour être lu. Le projet WireGuard évalue l’implémentation de son protocole à environ 4,000 lignes de code. OpenVPN dépasse 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 noyau. WireGuard fait partie du noyau Linux principal depuis la version 5.6. Ubuntu 24.04 et Debian 13 l’intègrent donc sans compilation. Les paquets sont chiffrés là où ils se trouvent déjà, dans l’espace noyau, sans copie vers un processus de l’espace utilisateur, puis retour. Vérifiez ce point avant toute autre chose :

sudo modprobe wireguard && echo ok

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

Il n’y a rien à négocier. WireGuard utilise une seule suite cryptographique fixe : ChaCha20-Poly1305 pour les données, avec des clés Curve25519. Il n’existe 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. Cela apporte de la flexibilité, mais c’est aussi là que se produisent les erreurs de configuration. Un serveur configuré avec data-ciphers AES-256-GCM:AES-128-CBC reviendra sans difficulté à un chiffrement CBC pour un client qui ne propose rien de mieux, et aucun élément du journal ne signalera ce comportement comme un problème.

Le port ne répond pas. Un paquet WireGuard qui échoue au contrôle d’authentification du message est supprimé sans aucune réponse. Ainsi, nmap -sU -p 51820 renvoie open|filtered, qu’un service soit à l’écoute ou non. Un serveur OpenVPN en mode TCP termine la négociation TCP avant de déterminer que l’accès est refusé. 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 pair WireGuard est identifié par sa clé publique, et non par son adresse. Votre ordinateur portable passe de votre réseau domestique à un hotspot mobile, envoie une seule poignée de main depuis la nouvelle adresse, puis le serveur met à jour le 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 généralement la session TLS complète, puis en établit une nouvelle. C’est pourquoi la pause à l’ouverture du capot est perceptible avec OpenVPN, mais pas avec WireGuard.

Vitesse en 2026 : l'écart s'est réduit

Pendant des années, l'argument honnête en faveur de la vitesse é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. Ce n'est plus toute la réalité, et une comparaison qui l'ignore est obsolète.

OpenVPN 2.7 est sorti en février 2026 avec la prise en charge du module kernel ovpn, intégré à Linux 6.16. Il s'agit de DCO (data channel offload) : le control channel reste dans l'espace utilisateur, tandis que le chemin des données principales passe dans le kernel, comme WireGuard le 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 d'une catégorie différente. Vérifiez ce que vous utilisez réellement :

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

En juillet 2026, une installation standard d'Ubuntu 24.04 LTS fournit OpenVPN 2.6, et non 2.7. Le module ovpn nécessite la version 2.7. Avec cette release, vous ne bénéficiez de l'offload qu'au moyen de l'ancien paquet openvpn-dco-dkms, qui compile un module out-of-tree pour votre kernel en cours d'exécution et doit donc être recompilé à chaque mise à niveau du kernel. WireGuard ne comporte pas ce composant supplémentaire.

Lisez attentivement les restrictions de DCO avant de le considérer comme une raison de continuer à utiliser OpenVPN. Il prend uniquement en charge les tunnels de Layer 3, accepte uniquement 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 la flexibilité qui constituait précisément l'argument d'OpenVPN. Un OpenVPN rapide est un OpenVPN configuré pour ressembler à WireGuard.

Ne vous fiez à aucun chiffre de débit publié, y compris ceux de cette page. Sur un VPS, la limite vient généralement de la capacité CPU ou réseau allouée, plutôt que du protocole. Mesurez vos propres performances avec iperf3 exécuté dans le tunnel, puis de nouveau en dehors du tunnel, et comparez les deux résultats.

Là où OpenVPN reste pertinent

Vous devez sortir par le port TCP 443. WireGuard utilise uniquement UDP, volontairement, et aucun mode TCP n'est prévu. Un réseau d'hôtel ou un proxy d'entreprise qui n'autorise que TCP 443 laissera passer OpenVPN configuré avec proto tcp-server et port 443, car ce trafic ressemble à une session TLS ordinaire. WireGuard a besoin d'un wrapper tel que 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 doit ê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 (infrastructure à clés publiques) que vous exploitez déjà. Les certificats expirent automatiquement. Pour révoquer un certificat, vous l'ajoutez à une liste de révocation des certificats que le serveur lit via crl-verify. WireGuard n'utilise ni certificats, ni expiration, ni liste de révocation. Pour supprimer un peer, vous devez modifier la configuration du serveur et la recharger. Avec 10 peers, cela convient. Avec 400 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, pas uniquement de clés. OpenVPN peut déléguer l'authentification à un système externe avec auth-user-pass-verify ou à un plugin tel que openvpn-plugin-auth-pam.so. C'est ainsi que vous ajoutez LDAP ou un second facteur à mot de passe à usage unique. WireGuard ne connaît pas la notion d'utilisateur. Une clé figure dans la configuration ou n'y figure pas. Si votre exigence est que « Sara saisisse un code reçu 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 LAN. WireGuard fonctionne uniquement en couche 3, et cela ne changera pas. OpenVPN possède également des clients pour du matériel et des systèmes d'exploitation qui n'auront jamais d'application WireGuard. Ces deux raisons perdent de leur importance. De plus, dev tap est incompatible avec DCO. Vous utilisez donc le chemin le plus lent lorsque vous activez le bridge.

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

Une identité WireGuard tient en une commande. Les parenthèses sont importantes, car elles définissent les permissions 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 de vie 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 biaisée. L’autorité de certification vous apporte l’expiration et la révocation. En contrepartie, vous devez protéger une clé privée pendant des années, penser au renouvellement et reconstruire l’infrastructure si vous la perdez. Si vous n’utilisez pas ces fonctionnalités, 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 présentée dans le guide pour auto-héberger un VPN WireGuard sur votre VPS.

Ce que chacun demande à votre firewall

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 utilise UDP 1194 par défaut, ou TCP 443 si vous avez choisi cette option. Les deux nécessitent ensuite l’activation de l’IP forwarding et une règle de source NAT, car un système Linux abandonne les paquets qui ne lui sont pas destinés. Cette configuration est identique pour les deux protocoles. C’est aussi la cause de la plupart des signalements du type « le tunnel se connecte, mais il n’y a pas d’accès à Internet ». Si ufw vous est peu familier, commencez par les bases du firewall ufw sur un VPS. N’oubliez pas que la plupart des fournisseurs exécutent un second firewall 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 préciser 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 utilisateur ou d’un second facteur, ne cherchez pas à imposer cette fonction à 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’a aucun certificat à 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é avec une autorité de certification que vous avez supprimée.

Un élément ne peut réellement pas être transféré : vos comptes utilisant un nom d’utilisateur et un mot de passe, ainsi que l’historique des révocations qui leur est associé. Déterminez où ces éléments seront gérés 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 espace utilisateur. Avec OpenVPN 2.7 et le module kernel ovpn de Linux 6.16, le chemin de traitement des données passe également par le kernel, et les deux solutions sont dans la même catégorie. Mesurez vos propres performances avec iperf3 à travers le tunnel au lieu de vous fier à un chiffre trouvé sur un blog, car sur un VPS, la limite vient généralement de votre CPU ou de votre quota de bande passante.

WireGuard peut-il fonctionner sur le port TCP 443 ?

Pas seul. WireGuard utilise uniquement 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 tel que wstunnel ou udp2raw. Cela ajoute un processus à exécuter et à maintenir à jour 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.

OpenVPN est-il désormais peu sécurisé ?

Non. Un OpenVPN à jour, avec un chiffrement AEAD tel que AES-256-GCM et tls-crypt activé, constitue un VPN fiable. L’argument en faveur de WireGuard repose sur un autre point : OpenVPN contient beaucoup plus de code et beaucoup plus d’options. Il offre donc à un administrateur fatigué beaucoup plus de façons de le configurer incorrectement. Moins de choix signifie moins d’erreurs possibles.

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 port UDP ouvert et une négociation qui se termine avant même que vous remarquiez qu’elle a commencé. Choisissez OpenVPN uniquement si vous vous connectez régulièrement depuis des réseaux qui bloquent UDP, ou si vous devez utiliser une autorité de certification ou un annuaire d’utilisateurs déjà existant.