WireGuard, OpenVPN et IKEv2/IPsec : les protocoles comparés

La page d'accueil décrit le fonctionnement d'un VPN au niveau du paquet : une interface virtuelle, de l'encapsulation, un serveur qui réémet le trafic. Le protocole est la pièce qui définit comment le tunnel s'établit, comment les clés sont négociées et comment les paquets sont formatés. Trois protocoles couvrent aujourd'hui la quasi-totalité des usages, et leurs différences ont des conséquences concrètes sur la performance, la fiabilité et la résistance au filtrage.

WireGuard

WireGuard est le plus récent des trois. Son code tient en quelques milliers de lignes, contre des centaines de milliers pour ses concurrents, ce qui réduit d'autant la surface d'audit et le risque de faille. Il s'appuie sur le cadre cryptographique Noise, avec un jeu d'algorithmes figé : échange de clés X25519, chiffrement authentifié ChaCha20-Poly1305, hachage BLAKE2s. Il n'y a rien à négocier, donc pas de risque de dégradation vers un algorithme faible ; le prix à payer est qu'une évolution cryptographique impose une nouvelle version du protocole.

WireGuard ne fonctionne qu'en UDP. Son établissement tient en un aller-retour, et il n'a pas de notion de « connexion » au sens classique : chaque pair est identifié par sa clé publique, et un pair peut changer d'adresse IP source sans interruption — le serveur met simplement à jour l'endpoint associé à la clé dès qu'il reçoit un paquet authentifié. C'est ce qui rend le roaming transparent : passer du Wi-Fi aux données mobiles ne coupe pas le tunnel. Le concept central est le « cryptokey routing » : à chaque clé publique de pair est associée une liste de plages d'adresses (AllowedIPs) qui sert à la fois de filtre en entrée et de table de routage en sortie.

OpenVPN

OpenVPN existe depuis le début des années 2000 et reste la référence en matière de souplesse. Il sépare un canal de contrôle, protégé par TLS — avec toute la machinerie de certificats que cela implique —, et un canal de données chiffré. Il s'appuie sur une bibliothèque cryptographique externe (OpenSSL ou mbedTLS), ce qui lui donne l'agilité mais aussi la surface d'attaque de cette bibliothèque.

Sa grande force est la configurabilité : il fonctionne en UDP ou en TCP, sur n'importe quel port — le 443 est courant pour se fondre dans le trafic HTTPS —, accepte des scripts, des greffons d'authentification, et le déplacement de session (--float). Historiquement, il souffrait de performances limitées parce que tout le traitement se faisait dans l'espace utilisateur sur un seul fil d'exécution ; la fonction récente de délestage du canal de données vers le noyau (Data Channel Offload) réduit fortement cet écart. Un point de vigilance : la compression, autrefois activée par défaut, a été à l'origine d'une attaque par oracle (VORACLE) et doit rester désactivée.

IKEv2/IPsec

IKEv2 est le protocole de négociation de clés ; IPsec, plus précisément le mode ESP, est ce qui chiffre et encapsule les paquets. L'établissement se fait en deux échanges — l'un pour négocier les paramètres et le secret partagé, l'autre pour authentifier les pairs. Son atout majeur est l'intégration : la plupart des systèmes d'exploitation et des systèmes mobiles savent le parler sans logiciel tiers, et l'extension MOBIKE gère le changement d'adresse, ce qui en fait un bon choix sur téléphone.

Son point faible est la traversée des réseaux filtrants : IKE utilise les ports UDP 500 et 4500, bien connus, et l'encapsulation NAT-T ajoute sa propre couche. Un pare-feu qui veut bloquer les VPN commence souvent par fermer ces ports. IKEv2 est donc rapide et stable dans un environnement ouvert, mais peu discret.

Les protocoles hérités

Trois protocoles plus anciens circulent encore et méritent d'être situés. PPTP est obsolète : son chiffrement, adossé à MS-CHAPv2, est considéré comme cassé depuis 2012, et il ne devrait plus jamais être utilisé. L2TP seul ne chiffre rien ; il n'a de sens qu'associé à IPsec, auquel cas il n'apporte rien de plus qu'IKEv2/IPsec tout en étant plus lourd. SSTP encapsule le trafic VPN dans du TLS sur le port 443, ce qui le rend discret, mais il est essentiellement lié à l'écosystème Windows et repose sur une pile propriétaire peu auditée. Aucun de ces trois n'est un choix recommandable aujourd'hui face à WireGuard, OpenVPN ou IKEv2.

UDP ou TCP : un choix qui compte

Encapsuler du TCP dans un tunnel TCP provoque un phénomène d'emballement : les deux couches de contrôle de congestion et de retransmission se superposent, et sur une liaison qui perd des paquets, le débit peut s'effondrer au lieu de se dégrader progressivement. C'est pourquoi l'UDP est préférable dès que le réseau le permet. Le tunnel en TCP reste utile pour une seule raison : traverser un réseau qui ne laisse passer que le trafic web sur les ports 80 et 443.

MTU et fragmentation

Chaque protocole ajoute sa propre surcharge d'en-tête : de l'ordre de 60 octets pour WireGuard, un peu plus pour OpenVPN selon la configuration, et une quantité variable pour IPsec selon le mode. Si l'interface tunnel conserve une MTU de 1500, les paquets pleins débordent une fois encapsulés et doivent être fragmentés, avec à la clé des pertes et des blocages. Les clients corrects abaissent la MTU de l'interface — souvent autour de 1420 pour WireGuard — et réécrivent la taille de segment TCP annoncée. Un tunnel qui « marche pour les petites pages mais bloque les gros téléchargements » est presque toujours un problème de MTU mal gérée.

Empreinte de code et sécurité

La taille du code n'est pas un détail académique : elle conditionne la capacité à auditer, la fréquence des vulnérabilités et le temps de correction. WireGuard, avec sa base réduite et son intégration au noyau Linux, part avec un avantage structurel. OpenVPN et la pile IKEv2/IPsec, plus anciens et plus vastes, ont connu davantage de failles au fil des ans, ce qui n'en fait pas des protocoles peu sûrs — ils restent solides quand ils sont à jour — mais impose une discipline de mise à jour plus stricte.

Performances

Dans la plupart des mesures, WireGuard arrive en tête pour le débit et la latence, grâce à son exécution dans le noyau et à un chiffrement léger sur les processeurs sans accélération matérielle. OpenVPN sans délestage noyau reste en retrait, surtout sur des liens très rapides ; avec le délestage, l'écart se resserre nettement. IKEv2/IPsec se situe entre les deux et bénéficie de l'accélération AES quand le matériel la fournit. Les chiffres exacts dépendent du processeur, du système et de la liaison : il faut mesurer soi-même, avec et sans tunnel, à la même heure.

Comment choisir

Pour un usage général sur un client moderne : WireGuard, pour ses performances, son roaming et sa simplicité, en acceptant qu'il soit facilement identifiable sur le réseau. Pour traverser un réseau restrictif ou se fondre dans le trafic HTTPS : OpenVPN en TCP sur le port 443, ou WireGuard derrière une couche d'obfuscation. Sur mobile, quand on veut le protocole natif sans application tierce : IKEv2/IPsec. Le meilleur protocole dépend du réseau que l'on doit traverser, pas d'un classement absolu.

Ce qu'il faut retenir

WireGuard est rapide, moderne et compact mais visible ; OpenVPN est souple et discret mais historiquement plus lourd ; IKEv2/IPsec est natif et stable mais dépendant de ports bien connus. Le protocole détermine la forme du tunnel ; ce qu'il contient relève de la cryptographie du tunnel, et la manière dont le trafic y entre dépend du routage du client.