Les protocoles VPN : WireGuard, OpenVPN, IKEv2 et les autres

Par La rédaction de Mon-Adresse-IP.net·Publié le 21 août 2026·

Derrière le bouton « connexion » de votre application VPN se cache un protocole de tunnel, et ce choix technique décide de votre débit, de la stabilité du tunnel quand vous changez de réseau et de sa capacité à passer un pare-feu. Ce guide compare les protocoles réellement rencontrés en 2026, avec leurs contreparties honnêtes.

Pourquoi le protocole compte

Un VPN combine deux choses distinctes : un service (des serveurs, une politique de journalisation, une juridiction) et un protocole de tunnel. Le premier détermine à qui vous faites confiance ; le second détermine ce que vous ressentez au quotidien. Les comparatifs commerciaux insistent sur le service et survolent le protocole, alors que c'est lui qui explique la plupart des déceptions concrètes.

Quatre propriétés dépendent directement du protocole choisi.

• La vitesse et la latence. Chaque paquet subit un chiffrement, une encapsulation et un surcoût d'en-tête. Un protocole compact traité dans le noyau du système consomme beaucoup moins de ressources qu'un protocole traité en espace utilisateur, différence particulièrement visible sur un téléphone, un boîtier NAS ou un routeur.
• La stabilité en itinérance. Quand votre téléphone passe du Wi-Fi domestique à la 4G, votre adresse source change. Certains protocoles reprennent la session en quelques millisecondes, d'autres imposent une renégociation complète, avec une coupure de plusieurs secondes qui interrompt un appel ou un transfert.
• La résistance au blocage. Un réseau d'entreprise, un hôtel ou un opérateur peut filtrer certains ports ou reconnaître la signature d'un tunnel. Selon le protocole, votre connexion passe, rame ou échoue silencieusement. Notre référence des ports TCP et UDP précise quels numéros sont concernés.
• La surface d'attaque. Le code qui traite des paquets venus d'Internet avant toute authentification est le plus critique d'un système. Sa taille est un indicateur imparfait mais réel de la difficulté à l'auditer.

Ce guide suppose acquis le fonctionnement général d'un tunnel ; si le sujet est nouveau pour vous, commencez par notre guide sur les VPN, puis revenez ici pour le détail technique. Et gardez à l'esprit que le protocole ne change jamais l'adresse vue par les sites : cela dépend uniquement du serveur de sortie, comme l'explique notre page sur les méthodes pour masquer son adresse IP.

Le tableau comparatif

Les dates indiquent la première publication ou la normalisation du protocole. Les appréciations de vitesse et de résistance sont relatives : elles comparent les protocoles entre eux, pas à une connexion sans tunnel.

WireGuard en détail

WireGuard est né d'un constat simple : les protocoles existants étaient devenus trop gros pour être vérifiés. Sa réponse tient en une contrainte de conception : réduire la quantité de code exposé au réseau à ce qu'une poignée de relecteurs peut lire intégralement. L'implémentation de référence tient en quelques milliers de lignes, contre plusieurs centaines de milliers pour une pile OpenVPN complète une fois sa bibliothèque TLS comptée. Elle a été intégrée au noyau Linux en 2020, ce qui lui donne un avantage de performance structurel : les paquets n'ont plus à faire l'aller-retour vers l'espace utilisateur.

Une cryptographie non négociable

WireGuard n'offre aucun choix d'algorithme. Le chiffrement authentifié est assuré par ChaCha20-Poly1305, l'échange de clés par Curve25519, le hachage par BLAKE2s, la poignée de main suivant le cadre du protocole Noise. Il n'existe pas de phase de négociation, donc pas de possibilité de rétrograder la session vers un algorithme faible, ni de configuration qui affaiblirait le tunnel par inadvertance. Le prix de ce parti pris : si une primitive venait à être affaiblie, la correction passerait par une nouvelle version du protocole, pas par un simple réglage.

Discrétion et reprise instantanée

Un serveur WireGuard ne répond pas aux paquets non authentifiés : pour un scanner, le port semble fermé. Chaque paquet reçu et validé met à jour l'adresse du correspondant. C'est ce détail qui explique la sensation de fluidité : quand votre téléphone quitte le Wi-Fi pour la 5G, le premier paquet valide reçu de la nouvelle adresse suffit à poursuivre la session, sans renégociation. Une visioconférence marque à peine une hésitation là où d'autres protocoles imposent une reconnexion visible.

Les contreparties, sans complaisance

Le point de vie privée mérite d'être expliqué, car il est régulièrement passé sous silence. Dans WireGuard, un correspondant est identifié par sa clé publique, à laquelle le serveur associe une adresse interne fixe : par exemple 10.8.0.42. Chez un fournisseur commercial, cela signifie que le serveur peut relier toutes vos sessions entre elles, tant que la même clé est utilisée. Le protocole seul n'oublie donc rien. Les fournisseurs sérieux compensent par des mécanismes documentés : attribution dynamique de l'adresse interne à chaque connexion, rotation régulière des clés, table des correspondants tenue en mémoire vive seulement, séparation entre l'identifiant d'abonnement et la clé de tunnel. Ces mesures sont extérieures au protocole : il faut donc vérifier qu'elles existent, plutôt que supposer que « WireGuard protège ».

OpenVPN en détail

Publié en 2001, OpenVPN est le vétéran du domaine. Il fonctionne partout, sur des systèmes que les protocoles récents ignorent, et deux décennies d'exposition publique lui ont valu une quantité de relectures qu'aucun nouveau venu ne peut revendiquer. Sa force est aussi sa faiblesse : il est extrêmement configurable, donc extrêmement configurable de travers.

Techniquement, OpenVPN sépare deux canaux : un canal de contrôle qui utilise TLS pour authentifier les extrémités et échanger les clés, et un canal de données qui transporte le trafic chiffré, aujourd'hui en AES-256-GCM ou ChaCha20-Poly1305. Cette architecture explique sa souplesse : certificats, clés partagées, authentification à double facteur, tout est possible.

UDP ou TCP : ce que le choix change concrètement

En UDP, généralement sur le port 1194, OpenVPN laisse la gestion des pertes à la connexion transportée. Si un paquet disparaît, seule la couche transportée retransmet. Le comportement est sain et le débit reste correct même sur une liaison imparfaite.

En TCP, le tunnel garantit lui-même la livraison des paquets… qui contiennent déjà des connexions TCP garantissant leur propre livraison. En cas de perte, les deux couches retransmettent et réduisent leur fenêtre simultanément. Le phénomène est connu sous le nom de TCP dans TCP : le débit ne baisse pas progressivement, il s'effondre. Sur une ligne fibre stable, la différence se remarque à peine ; sur un partage de connexion mobile en zone mal couverte, elle est spectaculaire.

Se faire passer pour du HTTPS

Le vrai argument d'OpenVPN aujourd'hui est sa capacité à franchir un réseau hostile. Configuré en TCP sur le port 443, il emprunte le port de tous les sites web : un filtrage par numéro de port le laisse passer, et l'option tls-crypt chiffre en plus le canal de contrôle, ce qui masque la signature de sa poignée de main. Soyons précis sur la limite : ce n'est pas du HTTPS. Les paquets OpenVPN portent leur propre en-tête avant la partie TLS, et il n'y a pas de nom de domaine annoncé comme dans une vraie négociation web. Un filtrage sommaire est trompé ; une inspection profonde correctement entraînée ne l'est pas.

IKEv2/IPsec, le protocole de la mobilité

IKEv2 n'est pas un protocole de tunnel complet : c'est le mécanisme qui négocie les clés, le transport des données étant assuré par IPsec. Normalisé en 2005, il est pris en charge nativement par Windows, macOS, iOS et Android : aucune application tierce n'est nécessaire, ce qui limite le nombre de composants à qui vous accordez un accès privilégié au réseau.

Son atout décisif est l'extension MOBIKE, publiée en 2006. Elle permet à un client de changer d'adresse IP et de continuer à utiliser la même association de sécurité, sans renégocier. C'est exactement le scénario du téléphone qui sort de la maison : le Wi-Fi disparaît, la 4G prend le relais, l'adresse source change, et le tunnel continue. Un téléchargement en cours ne s'interrompt pas.

Sa faiblesse est symétrique de sa force. IKEv2 utilise les ports UDP 500 et 4500, deux numéros parfaitement identifiables et couramment filtrés par les portails captifs d'hôtels, les réseaux d'entreprise et les Wi-Fi d'établissements scolaires. Aucun déguisement n'est prévu par défaut. Certaines implémentations savent basculer sur TCP 443, mais cette capacité n'est ni universelle ni activée d'office. Sur un réseau Wi-Fi public restrictif, IKEv2 est souvent le premier protocole à échouer.

Dernier point de vigilance : IKEv2 accepte une authentification par certificat ou par clé partagée. Les configurations d'entreprise anciennes utilisent parfois une clé partagée commune à tous les postes, ce qui affaiblit considérablement l'ensemble. Vérifiez, dans les réglages système de votre appareil, que la connexion s'appuie sur un certificat.

Les protocoles à éviter

PPTP : définitivement hors service

Conçu au milieu des années 1990, PPTP reste le protocole le plus simple à configurer, et c'est tout ce qu'on peut lui accorder. Son authentification MS-CHAPv2 a été publiquement cassée en 2012 : la démonstration a montré que la sécurité de l'échange se ramenait à celle d'une unique clé DES, à la portée d'un service de calcul en ligne. Autrement dit, quiconque capture le trafic peut, avec un effort modeste, remonter à la clé et lire la session. Un tunnel PPTP ne protège rien. Il pose en outre un problème pratique : il transporte les données via le protocole GRE, qui n'est pas du TCP ni de l'UDP et traverse mal les équipements de traduction d'adresses. Il ne devrait plus jamais être proposé ni sélectionné.

L2TP seul : aucun chiffrement

Point souvent ignoré : L2TP ne chiffre rien. C'est un protocole d'encapsulation, rien de plus. Toute la sécurité vient d'IPsec, ajouté par-dessus ; l'appellation correcte est donc L2TP/IPsec. Un menu de routeur proposant « L2TP » sans mention d'IPsec décrit un tunnel en clair, lisible par toute personne placée sur le chemin. Même correctement associé à IPsec, l'ensemble reste lourd : double encapsulation, davantage d'en-têtes, davantage de ports à ouvrir, et de nombreuses configurations grand public s'appuient sur une clé partagée publiée dans la documentation du fournisseur.

SSTP : un seul éditeur aux commandes

SSTP transporte le trafic dans une session TLS sur le port 443, ce qui lui donne une bonne capacité à franchir les pare-feu. Le problème n'est pas cryptographique mais structurel : le protocole est l'œuvre d'un unique éditeur, sa mise en œuvre de référence est fermée, et son support hors de l'écosystème Windows repose sur des implémentations tierces au suivi inégal. Vous ne pouvez ni vérifier le code, ni compter sur une communauté large pour détecter un défaut. Il hérite par ailleurs du problème de TCP dans TCP.

Pourquoi ces protocoles survivent-ils ?

Trois raisons, toutes prosaïques. D'abord la compatibilité : des routeurs, des automates industriels et des systèmes d'exploitation qui ne recevront jamais de mise à jour ne savent parler que PPTP ou L2TP. Ensuite l'inertie des interfaces : une liste déroulante ancienne coûte plus cher à retirer qu'à laisser, et le retrait déclenche des appels au support. Enfin l'argument commercial : afficher « 6 protocoles pris en charge » se vend mieux que « 2 protocoles, les bons ». Un menu qui propose encore PPTP ne trahit pas nécessairement un service dangereux ; il indique surtout que la longueur de la liste a primé sur la clarté du conseil.

Les protocoles propriétaires des fournisseurs

Plusieurs services commerciaux proposent aujourd'hui un protocole « maison », présenté comme plus rapide ou plus discret. La motivation technique est réelle et légitime : dans les pays qui filtrent activement Internet, la signature d'un tunnel standard est détectée, puis bloquée. Un protocole conçu pour ressembler à du trafic web quelconque, ou pour varier ses motifs de paquets, permet effectivement de rester joignable là où WireGuard et IKEv2 échouent. Dans la pratique, la plupart de ces protocoles sont des surcouches d'obscurcissement appliquées à une base connue, plutôt que des constructions cryptographiques entièrement nouvelles.

Le problème de fond tient en une phrase : on ne peut pas vérifier ce qu'on ne peut pas lire. Un protocole fermé ne bénéficie ni de la relecture publique, ni des analyses universitaires, ni des outils d'audit indépendants dont profitent les standards ouverts. Quand un audit externe existe, il porte souvent sur une version figée à une date donnée, sans possibilité pour un tiers de reproduire l'examen. S'ajoute une dépendance : un protocole propriétaire ne fonctionne qu'avec l'application de son éditeur, ce qui exclut les clients libres et rend le changement de service plus coûteux.

La position raisonnable n'est ni le rejet ni l'enthousiasme. Traitez ces protocoles comme un outil de contournement à activer quand les protocoles standards sont bloqués, et non comme le réglage par défaut. Deux questions permettent de trancher : la spécification est-elle publiée ? Un audit indépendant, daté et consultable, a-t-il porté sur ce protocole précis ? Si les réponses sont négatives, l'obscurcissement reste utile pour la disponibilité, pas pour la confiance. Lorsque le vrai besoin est la résistance à la censure plutôt que la vitesse, le réseau Tor et ses transports enfichables constituent une réponse dont le fonctionnement, lui, est entièrement public.

Choisir en pratique, par usage

Le bon réflexe n'est pas de chercher « le meilleur protocole » mais de partir de votre situation. Voici l'arbre de décision que nous appliquons.

1. Usage quotidien sur une connexion fixe WireGuard, sans hésitation. Débit maximal, latence minimale, configuration lisible. Vérifiez simplement que votre fournisseur documente la façon dont il gère les adresses internes et les clés.
2. Téléphone, trajets, alternance Wi-Fi et réseau mobile WireGuard ou IKEv2. Les deux reprennent une session interrompue, IKEv2 avec l'avantage d'être intégré au système, donc sans application supplémentaire au démarrage. Sur batterie, le tunnel intégré au système consomme généralement moins.
3. Réseau restrictif : entreprise, hôtel, aéroport, campus OpenVPN en TCP sur le port 443, ou le mode d'obscurcissement de votre service. C'est le cas où la lenteur est un compromis acceptable : un tunnel lent vaut mieux qu'un tunnel qui ne s'établit pas.
4. Appareil ancien, routeur, téléviseur, console OpenVPN si l'appareil sait l'exécuter. Sinon, ne rabattez pas sur PPTP : installez plutôt le tunnel sur le routeur en amont, ou renoncez au VPN pour cet appareil. Un tunnel cassé donne un faux sentiment de sécurité, ce qui est pire que pas de tunnel du tout.
5. Serveur personnel loué ou machine à la maison WireGuard. Sa configuration tient en quelques lignes, il démarre instantanément et sa consommation de ressources est négligeable, y compris sur un micro-ordinateur monocarte.

Vérifier le protocole réellement actif prend quelques secondes. Sous Linux, l'état d'un tunnel WireGuard et la date de sa dernière poignée de main s'affichent directement ; sous Windows, l'adaptateur virtuel apparaît dans la liste des interfaces.

wg show                 # tunnels WireGuard : pairs, dernier handshake, volumes
ip -brief addr          # interfaces : wg0, tun0 (OpenVPN), ipsec0 (IPsec)
ipconfig /all           # Windows : repérer la carte du tunnel et son suffixe DNS

Le nom de l'interface est un indice fiable : wg0 pour WireGuard, tun0 ou tap0 pour OpenVPN, une interface de type IPsec pour IKEv2. Si aucune interface de ce genre n'apparaît alors que l'application affiche « connecté », c'est que seul le navigateur est concerné : vous utilisez en réalité un proxy, pas un VPN, et le reste de vos applications sort en clair.

Monter son propre serveur VPN

Installer son propre serveur est un excellent projet, à condition de savoir ce qu'on en attend. La confusion sur ce point est massive : elle mérite d'être levée sans détour.

Ce que cela apporte réellement

• L'accès à votre réseau domestique depuis l'extérieur. Vos fichiers, votre serveur multimédia, l'interface de votre domotique deviennent joignables en déplacement sans exposer le moindre service sur Internet. C'est de loin la meilleure raison de le faire.
• La confiance dans l'opérateur du serveur. C'est vous. Aucune politique de journalisation à croire sur parole, aucune juridiction à examiner.
• Un chiffrement fiable sur les réseaux partagés. Depuis un Wi-Fi d'hôtel, tout votre trafic rentre chez vous chiffré, ce qui neutralise l'interception locale.
• Un apprentissage concret. Routage, pare-feu, résolution de noms : on comprend vraiment ces sujets en les mettant en œuvre.

Ce que cela n'apporte pas

Cela ne masque pas votre adresse IP. Quand vous vous connectez à votre serveur domestique depuis un café et que vous naviguez à travers ce tunnel, votre trafic ressort par votre ligne : les sites voient l'adresse publique de votre domicile, c'est-à-dire l'adresse la plus directement rattachée à vous. Vous avez protégé la portion locale du trajet, et rendu votre navigation plus identifiable au bout de la chaîne, pas moins.

Le raisonnement vaut aussi pour un serveur loué chez un hébergeur. L'adresse est alors différente de la vôtre, mais elle est utilisée par vous seul : pas de mélange avec d'autres abonnés, un contrat de location à votre nom, et une adresse identifiée comme appartenant à un centre de données. Vous avez échangé la confiance envers un fournisseur de VPN contre la confiance envers un hébergeur, et perdu l'anonymat par le nombre. Là encore, si l'objectif est de ne pas être distingué dans la foule, l'outil adapté est Tor, pas un tunnel personnel.

L'obstacle technique : être joignable depuis l'extérieur

Un serveur VPN à domicile suppose que votre box possède une adresse IPv4 publique et que vous puissiez y rediriger le port du tunnel, par exemple le 51820 en UDP pour WireGuard. Deux difficultés se présentent en France.

La première est le partage d'adresse : de plus en plus d'abonnés, en fibre comme en 4G ou 5G, se voient attribuer une adresse IPv4 mutualisée entre plusieurs clients. Aucune redirection de port n'est alors possible depuis l'interface de la box. Notre guide sur le CGNAT explique comment détecter cette situation en comparant l'adresse affichée par la box à celle vue depuis Internet, et quelles options existent : chez plusieurs opérateurs, l'espace abonné permet de demander une adresse dédiée, parfois sous l'appellation IP fixe.

La seconde est l'adresse changeante : la plupart des offres grand public attribuent une adresse dynamique, susceptible de changer après une coupure ou un redémarrage. Un service de nom dynamique, souvent intégré aux box, résout le problème en associant un nom stable à l'adresse du moment. Une fois ces deux points réglés, la redirection elle-même est décrite dans notre guide ouvrir un port sur sa box.

Les fuites qui annulent tout

Un protocole irréprochable ne protège que ce qui passe dans le tunnel. Quatre défauts de configuration très courants laissent une partie du trafic sortir à côté, et aucun protocole n'y remédie de lui-même.

Fuite DNS	Le système continue d'interroger le résolveur de votre opérateur au lieu de celui du tunnel. Le contenu des pages est chiffré, mais la liste des sites visités reste visible de votre fournisseur d'accès. Le DNS chiffré (DoH et DoT) et un changement de résolveur limitent le risque.
Fuite IPv6	Le cas le plus fréquent aujourd'hui. Si le tunnel ne route que l'IPv4 alors que votre ligne fournit une connectivité IPv6, tout site joignable en IPv6 est atteint hors tunnel, avec votre adresse réelle. Vérifiez que la configuration route bien ::/0, ou désactivez l'IPv6 pendant la session.
Fuite WebRTC	Le navigateur peut révéler vos adresses locales et publiques à une page web, indépendamment du tunnel. Notre test de fuite WebRTC le vérifie en une seconde.
Absence de coupe-circuit	Si le tunnel tombe, le système bascule sur la connexion normale sans prévenir. Les applications continuent d'émettre, avec votre adresse réelle. Un kill switch bloque tout trafic hors tunnel tant que celui-ci n'est pas rétabli.

Sur une configuration WireGuard gérée par wg-quick, le coupe-circuit s'obtient par une règle de pare-feu qui rejette tout paquet ne sortant pas par l'interface du tunnel. La documentation officielle en donne la forme suivante, à placer dans le fichier de configuration.

PostUp  = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) \
          -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) \
          -m addrtype ! --dst-type LOCAL -j REJECT
# %i est remplacé par le nom de l'interface, wg0 par exemple.

Un dernier rappel : aucun protocole ne vous rend anonyme. Le tunnel protège le transport ; il ne touche ni à vos comptes connectés, ni aux cookies, ni à l'empreinte de votre navigateur, qui vous reconnaît sans avoir besoin de votre adresse IP. Le protocole est un élément d'une chaîne, et c'est toujours le maillon le plus faible qui décide du résultat.

Questions fréquentes