WireGuard en détail : fonctionnement et histoire

Avant WireGuard, on avait le choix entre IPsec et OpenVPN. IPsec est une vaste famille de normes aux innombrables options, et le faire dialoguer entre équipements de marques différentes est notoirement pénible. OpenVPN tourne en espace utilisateur et s'appuie sur une énorme bibliothèque TLS : souple, mais lent. Dans les deux cas, le code est si volumineux que presque personne ne peut l'auditer en entier.

WireGuard prend le contre-pied : faire une seule chose, et la faire bien. Dans le système, il apparaît comme une carte réseau virtuelle (par exemple wg0). Vous lui attribuez votre clé privée et les clés publiques de quelques pairs ; tout paquet envoyé vers elle est chiffré puis expédié, et les paquets reçus en ressortent déchiffrés. Le reste (routage, pare-feu, attribution d'adresses) est confié aux outils déjà présents dans le système.

Ce qu'il refuse délibérément de faire est tout aussi clair : pas de négociation d'algorithmes, pas de gestion d'identifiants et de mots de passe, pas d'attribution d'adresses, pas de camouflage du trafic. Ces fonctions sont soit considérées comme des sources de failles, soit laissées aux outils de plus haut niveau.

Dans WireGuard, chaque appareil possède une paire de clés, et sa clé publique est son identité, un peu comme avec SSH : chacun inscrit la clé publique de l'autre dans sa configuration, et la confiance est établie. Ni certificat, ni identifiant, ni mot de passe.

Pour chaque pair, la configuration contient une ligne d'« adresses autorisées » (AllowedIPs), qui joue dans les deux sens. À l'envoi, le paquet est chiffré avec la clé publique du pair dont la plage autorisée contient l'adresse de destination, puis lui est envoyé. À la réception, une fois le paquet déchiffré, WireGuard vérifie que l'adresse source se trouve bien dans la plage autorisée de ce pair ; sinon, le paquet est jeté. C'est ce qu'on appelle le routage par clés cryptographiques (cryptokey routing) : table de routage et contrôle d'accès ne font plus qu'un.

Ainsi, déclarer 0.0.0.0/0 comme adresses autorisées d'un pair revient à lui confier tout le trafic : c'est le VPN « global » au sens habituel. N'y mettre qu'une plage de réseau interne signifie que seul le trafic vers cette plage passe par le tunnel.

Avant de communiquer pour la première fois, deux appareils échangent une poignée de main : l'initiateur envoie un paquet, le destinataire en renvoie un, et c'est terminé. Les deux côtés disposent alors de clés de session valables pour un temps limité. La poignée de main repose sur le framework Noise : les clés à long terme des deux parties servent à l'authentification mutuelle, et des clés éphémères assurent la confidentialité persistante (forward secrecy). Même si une clé privée à long terme fuit un jour, le trafic enregistré auparavant reste indéchiffrable.

Les clés de session sont renouvelées automatiquement toutes les quelques minutes, de façon invisible pour l'utilisateur, et sans aucune « reconnexion ».

Les algorithmes sont imposés : Curve25519 pour l'échange de clés, ChaCha20-Poly1305 pour le chiffrement des données, BLAKE2s pour le hachage. Pas de négociation, donc pas d'attaque par rétrogradation : un attaquant ne peut pas pousser les deux côtés vers un algorithme plus faible. Si l'un de ces algorithmes était un jour cassé, la solution serait de publier une nouvelle version du protocole qui remplace l'ensemble, et non d'ajouter une option.

On peut en outre ajouter une clé prépartagée, qui se combine au mécanisme à clés publiques pour parer à la menace que les futurs ordinateurs quantiques feraient peser sur les algorithmes à clé publique.

• UDP uniquement : WireGuard chiffre chaque paquet séparément et le place dans un paquet UDP. Ne pas utiliser TCP est un choix délibéré : faire passer du TCP dans du TCP, c'est avoir deux couches qui retransmettent, et elles se freinent mutuellement dès qu'il y a des pertes.
• Silence face aux inconnus : aucun paquet non authentifié ne reçoit de réponse. Pour qui scanne les ports, celui-ci semble fermé, et rien n'indique que WireGuard tourne derrière.
• Itinérance : WireGuard ne connaît pas de « connexion », seulement des clés publiques. Si un pair change d'adresse (un téléphone qui passe du Wi‑Fi aux données mobiles), il suffit que son paquet suivant soit authentifié pour que les réponses partent automatiquement vers la nouvelle adresse. Le tunnel ne tombe donc pas quand on change de réseau.
• Discrétion : quand il n'y a rien à envoyer, le tunnel ne génère aucun trafic, d'où une très faible consommation sur téléphone. Ce n'est que lorsqu'un appareil se trouve derrière un routeur et doit rester joignable en permanence qu'il faut activer le maintien de connexion (PersistentKeepalive), qui envoie un petit paquet toutes les quelques dizaines de secondes pour conserver la correspondance sur le routeur.

• Il tourne dans le noyau : sous Linux, WireGuard est un module du noyau, et les paquets n'ont pas à faire l'aller-retour entre le noyau et un programme utilisateur. OpenVPN tourne traditionnellement en espace utilisateur, et chaque paquet fait un détour de plus.
• Des algorithmes adaptés à tous les processeurs : ChaCha20 n'a pas besoin d'instructions d'accélération matérielle, ce qui l'avantage nettement sur les puces sans instructions AES, comme celles des téléphones et des routeurs.
• Une poignée de main courte : un aller-retour et les données peuvent passer, l'établissement est presque instantané.
• Peu de code : le chemin est court, et toutes les optimisations possibles portent sur les quelques étapes critiques.
• Attention : tout cela concerne le coût du protocole et de son implémentation. Sur une liaison internationale, le débit réel dépend surtout des pertes de paquets sur la ligne et de l'attitude de l'opérateur envers l'UDP.

• Vers 2015 : Jason A. Donenfeld commence à développer WireGuard et le rend public, d'abord sous forme de module noyau Linux indépendant.
• 2017 : l'article décrivant sa conception est publié à la conférence de sécurité réseau NDSS, et le protocole fait ensuite l'objet de plusieurs vérifications formelles indépendantes. À la même époque, des fournisseurs VPN comme Mullvad commencent à proposer des connexions WireGuard.
• 2018 : Linus Torvalds, le créateur de Linux, salue son code sur la liste de diffusion en disant que, comparé à OpenVPN et IPsec, c'est une véritable œuvre d'art. La phrase le fait connaître dans tout le milieu des développeurs.
• 2019 : Cloudflare publie BoringTun, une implémentation en espace utilisateur écrite en Rust, et utilise WireGuard pour son service WARP ; NordVPN lance NordLynx, basé sur WireGuard ; Tailscale démarre aussi à cette période avec WireGuard comme plan de données.
• Mars 2020 : WireGuard entre officiellement dans la branche principale du noyau avec Linux 5.6, en même temps que sort la version 1.0. Depuis, les grandes distributions Linux l'intègrent d'origine, sans module à ajouter. La même année, OpenBSD l'intègre aussi à son noyau.
• 2021 : Windows reçoit une implémentation en mode noyau, WireGuardNT, nettement plus performante que l'ancienne version en espace utilisateur ; FreeBSD obtient ensuite la sienne.
• Aujourd'hui : Windows, macOS, Linux, iOS et Android ont tous un client officiel, les systèmes de routeurs et de NAS comme OpenWrt ou Synology le prennent généralement en charge d'origine, et la grande majorité des VPN commerciaux le proposent par défaut ou en option.

• Aucune distribution des clés : chaque nouvel appareil impose d'inscrire sa clé publique dans la configuration des autres. Au-delà de quelques appareils, cela devient ingérable : c'est précisément la raison d'être d'outils comme Tailscale.
• Aucune attribution dynamique d'adresses : l'adresse interne de chaque pair est figée dans la configuration ; il n'y a pas de mécanisme à la OpenVPN qui « attribue une adresse à la connexion ». Les VPN commerciaux qui l'utilisent doivent ajouter leur propre couche par-dessus.
• Un point sensible pour la vie privée : le serveur doit mémoriser la dernière adresse publique de chaque pair pour pouvoir lui répondre. Les fournisseurs qui promettent de ne conserver aucun journal doivent donc prendre des mesures supplémentaires (effacement régulier, double traduction d'adresses, etc.).
• UDP uniquement : sur un réseau qui bloque ou bride l'UDP, il ne passe pas ou devient très lent. Pour le faire passer par TCP ou par le port 443, il faut l'envelopper dans un autre outil.
• Aucun camouflage : le format et la taille des paquets de poignée de main et de données ont une signature fixe, très facile à identifier. Il a été conçu pour la sécurité et la simplicité, pas pour résister à la censure.
• Aucune notion de compte : le protocole ignore identifiants, mots de passe et dates d'expiration ; il ne reconnaît que des clés publiques.

• Volume de code : quelques milliers de lignes pour le cœur de WireGuard ; OpenVPN avec sa bibliothèque TLS, comme les diverses implémentations d'IPsec, se comptent en centaines de milliers.
• Transport : WireGuard n'utilise que l'UDP ; OpenVPN accepte les deux et peut passer en TCP 443, sur le même port que le trafic HTTPS ; IPsec utilise son propre numéro de protocole et l'UDP 500 / 4500.
• Configuration : quelques lignes par pair pour WireGuard ; OpenVPN a un fichier de configuration aux nombreuses options, mais très souple ; IPsec est le plus complexe.
• Performances : sur un réseau propre, WireGuard est généralement le plus rapide et le plus économe ; les versions récentes d'OpenVPN ont aussi une accélération dans le noyau (DCO), et l'écart se réduit.
• Fonctions : authentification par identifiant et mot de passe, envoi dynamique d'adresses et de routes, passage en TCP : OpenVPN fait tout cela nativement, alors que WireGuard doit s'appuyer sur un système externe.
• Compatibilité : OpenVPN, plus ancien, est reconnu par presque tous les vieux routeurs, NAS et appareils embarqués ; WireGuard est désormais courant sur les systèmes récents, mais pas forcément présent sur les anciens.

• Tailscale : ajoute à WireGuard la connexion par compte, la distribution des clés, la traversée de NAT et les relais pour en faire un réseau maillé automatique, voir Tailscale en détail. Headscale en est une implémentation open source du serveur de contrôle.
• Netmaker, NetBird, Firezone, etc. : d'autres produits de réseau maillé ou de « zéro confiance » sur le même modèle, WireGuard pour le plan de données et leur propre plan de gestion.
• Cloudflare WARP : un client WireGuard grand public qui fait entrer le trafic dans le réseau de Cloudflare.
• Les variantes maison des VPN commerciaux : NordLynx et d'autres, qui ajoutent à WireGuard une couche d'attribution d'adresses et de protection de la vie privée.
• AmneziaWG et autres variantes : elles modifient les en-têtes et ajoutent du remplissage pour masquer la signature fixe de WireGuard sur les réseaux très surveillés ; elles ne sont pas compatibles avec les clients WireGuard standard.

• Tout dépend d'abord de l'UDP : de nombreux réseaux fixes et mobiles brident l'UDP à fort débit. Résultat : rapide juste après la connexion, puis plus lent au bout d'un moment, ou nettement saccadé aux heures de pointe du soir.
• Une connexion directe vers l'étranger est facile à repérer : la poignée de main de WireGuard a une signature fixe, qui peut être identifiée et perturbée sur les liaisons internationales. Cela se traduit par une poignée de main qui n'aboutit pas, ou par un trafic qui s'arrête après un moment. C'est la conséquence directe d'un protocole sans camouflage.
• Un réseau entre appareils situés en Chine (bureau et domicile, téléphone et NAS) ne passe pas par les liaisons internationales et échappe généralement à ce problème ; seuls comptent alors le bridage de l'UDP et le taux de réussite de la traversée de NAT.
• Il convient donc surtout aux réseaux maillés et à l'accès à distance. Pour franchir la frontière de façon stable et durable, il faut l'associer à une méthode camouflée ou capable de passer par TCP / TLS ; la comparaison des protocoles est dans Comparatif des protocoles VPN.

La rubrique Privé de LeoTun s'appuie sur Tailscale, dont le plan de données est WireGuard : c'est lui qui chiffre et transporte aussi bien les tunnels entre vos appareils que ceux vers les serveurs de sortie de chaque région. Vous n'avez ni clés à générer ni configuration à écrire : le client s'en charge dès que vous vous connectez avec votre compte du site. Le mode d'emploi est dans Privé (Tailscale) : de quoi s'agit-il, et l'accès se fait depuis la page Privé.

En dehors de Privé, le même compte donne accès à des méthodes qui ne dépendent pas de l'UDP : Cisco (AnyConnect) passe par TLS, OpenVPN peut passer par TCP, et Hiddify (Hysteria2) est conçu pour résister aux pertes de paquets. Si Privé est lent et instable sur votre réseau, il suffit de changer de méthode, voir Quelle méthode de connexion pour quelle situation.