WireGuard et VPN maillés, fonctionnement, AllowedIPs et limites

WireGuard est un VPN (Virtual Private Network) de couche 3 : il transporte des paquets IP (Internet Protocol) dans des datagrammes UDP (User Datagram Protocol), avec une poignée de primitives fixes et une idée centrale, lier des adresses à des clés. Cette page complète le panorama de VPN, tunnels, bastions et interconnexions protégées sans le refaire : elle traite ce qui sépare WireGuard d’IPsec (Internet Protocol Security) avec IKEv2 (Internet Key Exchange version 2) et d’OpenVPN, puis les réseaux maillés bâtis dessus. Position tenue tout du long : WireGuard est un excellent plan de données et rien d’autre, et la sécurité d’un « VPN moderne » se décide dans la couche qui distribue les clés.

→ Lire l’explication complète de la marmotte

Le protocole WireGuard : poignée de main Noise et primitives fixes

WireGuard bâtit sa poignée de main sur Noise, un cadre de composition d’échanges Diffie-Hellman, avec le motif IK : la clé statique de l’initiateur part immédiatement dans le premier message (chiffrée), celle du répondeur est connue d’avance. La variante retenue, IKpsk2, mélange une clé pré-partagée au moment du second message. Un aller-retour, deux messages, et l’initiateur émet des données dès la réponse reçue.

À lire dans le schéma : deux messages suffisent, le cookie n’apparaît que sous charge, et le répondeur reste muet tant que l’initiateur n’a pas prouvé par un premier paquet qu’il détient la clé de session.

Primitives fixes, zéro négociation. Curve25519 pour l’échange Diffie-Hellman, ChaCha20-Poly1305 pour le chiffrement authentifié (détaillé dans chiffrement par flot : état, compteurs et réutilisation interdite), BLAKE2s pour le hachage et les codes d’authentification, SipHash24 pour les tables de hachage internes, HKDF (HMAC-based Key Derivation Function, HMAC signifiant Hash-based Message Authentication Code) pour dériver les clés. Aucune liste de suites, aucun repli : une attaque par dégradation n’a rien à dégrader. Règle générale des protocoles à options : une suite faible laissée négociable finit négociée, par l’équipement que personne n’ose mettre à jour.

La facture de cette absence d’agilité cryptographique arrive le jour où une primitive tombe : pas de paramètre à basculer, il faut une nouvelle version du protocole, incompatible avec l’ancienne, déployée sur tous les pairs. Contrainte d’architecture : un parc WireGuard doit pouvoir être mis à jour en bloc, ce qui écarte les équipements dont le micrologiciel ne bouge plus.

Clé pré-partagée. Optionnelle, 32 octets, une par couple de pairs, elle ajoute un secret symétrique à la dérivation des clés. Cible : l’adversaire qui enregistre aujourd’hui pour déchiffrer le jour où Curve25519 cédera à un calculateur quantique. Deux limites. Elle est statique : sa fuite ultérieure annule la protection sur tout le trafic enregistré. Et c’est un secret de plus à distribuer et à faire tourner. Des projets comme Rosenpass la renouvellent par un échange post-quantique externe ; c’est un composant posé à côté de WireGuard, pas WireGuard.

Renouvellement et confidentialité persistante. Chaque poignée de main tire des clés éphémères neuves ; elle est relancée toutes les deux minutes environ tant que du trafic circule, et une session âgée de trois minutes n’est plus acceptée. Voler une clé statique demain ne déchiffre donc pas les captures d’hier. Nuance : l’identité de l’initiateur, chiffrée vers la clé statique du répondeur, n’a pas cette propriété ; qui obtient plus tard la clé privée du répondeur sait qui s’est présenté.

Horodatage anti-rejeu. Le premier message porte un horodatage chiffré, et le répondeur refuse toute valeur inférieure ou égale à la dernière reçue de ce pair. Aucune synchronisation d’horloge entre pairs n’est requise, mais un équipement sans horloge sauvegardée qui redémarre dans le passé est refusé jusqu’à ce que son heure dépasse l’ancienne. Si sa synchronisation NTP (Network Time Protocol) passe par le tunnel, le serpent se mord la queue.

Cryptokey routing : AllowedIPs, table de routage et filtre d’origine

Chaque pair est identifié par sa clé publique, et à chaque clé publique est attachée une liste de préfixes, AllowedIPs. Cette liste travaille dans les deux sens. En sortie, l’adresse de destination est cherchée parmi les AllowedIPs de tous les pairs, au préfixe le plus long, et le pair trouvé désigne la clé de chiffrement. En entrée, une fois le paquet déchiffré et authentifié, son adresse source interne doit appartenir aux AllowedIPs du pair émetteur, sinon il est jeté sans bruit.

Un pair ne peut donc pas usurper l’adresse d’un autre dans le tunnel : l’adresse est liée à la clé. C’est l’idée la plus élégante du protocole, et la source de ses erreurs les plus régulières.

Deux tables, pas une. AllowedIPs choisit le pair, la table de routage du système choisit l’interface. wg-quick installe les routes correspondantes ; wg seul ne le fait pas, et les autres intégrations pas toujours. Un préfixe sans route système n’est jamais émis ; une route sans préfixe correspondant donne un paquet refusé à l’émission (sous Linux, l’erreur « Required key not available » dit exactement cela). Le raisonnement général est dans décision de chemin et routes.
Chevauchements. Sur une interface, un préfixe appartient à un seul pair. L’attribuer à un second le retire du premier, sans erreur ni avertissement. Deux préfixes de longueurs différentes cohabitent et le plus long gagne, ce qui est voulu et surprend quand même.
0.0.0.0/0 posé sans y penser. Côté client, c’est un tunnel intégral, et sans ::/0 le trafic IPv6 continue de sortir à côté. Côté concentrateur, donner 0.0.0.0/0 à un pair l’autorise à émettre avec n’importe quelle adresse source et aspire vers lui tout ce qui sort par l’interface sans préfixe plus précis chez un autre pair.
AllowedIPs pris pour un pare-feu. Le nom ment un peu : c’est un filtre sur l’adresse source interne, point. Ni destination, ni port, ni protocole. Un pair admis avec un /32 atteint tout ce que la passerelle accepte de router. Le filtrage se fait sur l’interface du tunnel, avec le pare-feu de l’hôte (principes dans filtrage, segmentation et NAC).
Routage dynamique. AllowedIPs est statique. Pour laisser un protocole de routage choisir le chemin, le montage qui tient est une interface par pair avec des AllowedIPs larges : le filtre d’origine est alors neutralisé et doit être compensé par du filtrage explicite.

Exemple : lire AllowedIPs sur un concentrateur et deux pairs

À regarder dans la topologie : un concentrateur joignable sur Internet, un poste nomade A et une passerelle B qui route le réseau 10.20.0.0/24 depuis l’arrière d’un NAT (Network Address Translation). Le paquet représenté va de A vers un serveur du site.

Côté concentrateur, toute la politique d’adressage tient dans deux lignes AllowedIPs :

# /etc/wireguard/wg0.conf sur le concentrateur (lu par wg-quick)
[Interface]
Address = 10.99.0.1/24
ListenPort = 51820
# Clé privée lue dans un fichier séparé (droits 0600), jamais écrite ici
PostUp = wg set %i private-key /etc/wireguard/wg0.key

[Peer]
# Poste A : une adresse, rien d'autre
PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=
AllowedIPs = 10.99.0.2/32

[Peer]
# Passerelle B : son adresse de tunnel ET le réseau qu'elle route
PublicKey = TrMvSoP4jYQlY6RIzBgbssQqY3vxI2Pi+y71lOWWXX0=
AllowedIPs = 10.99.0.3/32, 10.20.0.0/24

Lecture, dans l’ordre. Sur A, le concentrateur est le seul pair et ses AllowedIPs (10.99.0.0/24 et 10.20.0.0/24) couvrent la destination 10.20.0.15 : le paquet part chiffré vers lui. Le concentrateur déchiffre, vérifie que la source 10.99.0.2 figure dans la liste de A, puis route : la destination tombe dans 10.20.0.0/24, attribué à B, et le paquet repart chiffré avec la session de B. Si A forge une source en 10.20.0.50, le paquet meurt au concentrateur. Si A vise une autre interface du concentrateur, AllowedIPs n’a aucun avis : au pare-feu de dire non.

Trois conditions hors fichier, oubliées à tour de rôle : le transfert IP activé sur le concentrateur et sur B ; côté B, un PersistentKeepalive vers le concentrateur et, dans les AllowedIPs que B attribue au concentrateur, le préfixe 10.99.0.0/24 ; sur le site, une route de retour vers 10.99.0.0/24 passant par B. Dernier point, structurel : en étoile, le concentrateur déchiffre et rechiffre tout. Le trafic entre A et B n’est pas chiffré de bout en bout, et un concentrateur compromis le lit en entier.

Silence. Un message de poignée de main n’obtient de réponse que si son premier code d’authentification (mac1) est valide, ce qui suppose de connaître la clé publique du répondeur. Le reste est jeté : ni bannière, ni erreur. Un balayage ne distingue pas un port WireGuard d’un port filtré. Limite : une clé publique circule dans des fichiers de configuration, ce n’est pas un secret au sens fort. Ce silence réduit l’exposition, il n’authentifie personne.

Cookie. Une poignée de main coûte des calculs sur courbe elliptique, de quoi épuiser un processeur avec des messages forgés. Sous charge, le répondeur ne traite plus le message et renvoie un cookie lié à l’adresse source ; l’initiateur doit émettre un nouveau message portant un second code (mac2) calculé à partir de ce cookie. L’attaquant doit alors recevoir du trafic à l’adresse qu’il annonce : l’usurpation d’adresse tombe et la limitation de débit par source devient possible.

Itinérance. Chaque pair retient comme adresse de l’autre la source du dernier paquet authentifié. Changer de réseau ne casse rien. Corollaire à ne pas rater : l’adresse d’un pair n’est pas un paramètre de sécurité, et qui détient la clé privée se connecte de n’importe où. Restreindre par adresse source reste le travail du pare-feu en amont.

PersistentKeepalive. WireGuard est muet au repos. Derrière un NAT ou un pare-feu à états, l’association UDP expire et le pair devient injoignable de l’extérieur jusqu’à sa prochaine émission (mécanique décrite dans NAT, translations et publication). PersistentKeepalive, désactivé par défaut, envoie périodiquement un paquet vide authentifié ; la documentation suggère 25 secondes. À poser du côté qui est derrière le NAT, pas partout par réflexe : sur un mobile, cela se paie en batterie.

Encapsulation et MTU. En-tête IP externe (20 octets en IPv4, 40 en IPv6), UDP (8), WireGuard (32, étiquette d’authentification comprise) : 60 ou 80 octets. D’où le MTU (Maximum Transmission Unit) par défaut de 1420 octets sur l’interface, calculé pour le pire cas sur un lien à 1500. Sur un lien déjà réduit ou un tunnel dans un tunnel, 1420 est trop grand, et la découverte du MTU de chemin repose sur des messages ICMP (Internet Control Message Protocol) que bien des pare-feu jettent. Symptôme classique : la poignée de main passe, les petits paquets aussi, les gros transferts gèlent. Remède : abaisser le MTU de l’interface ou plafonner la taille des segments TCP (Transmission Control Protocol) sur la passerelle ; le diagnostic est détaillé dans résolution locale et ICMP.

Pas de repli TCP. C’est voulu : un tunnel TCP qui transporte du TCP empile deux mécanismes de retransmission qui se marchent dessus (voir UDP, TCP et leurs comportements). Sur un réseau qui ne laisse sortir que le web, WireGuard ne passe pas. Tout contournement (enrobage de l’UDP, relais d’un produit maillé) est un ajout externe, avec sa propre surface d’attaque.

Implémentations de WireGuard : noyau Linux, espace utilisateur et prérequis

WireGuard est intégré au noyau Linux depuis la version 5.6 (2020). Il existe aussi dans le noyau d’OpenBSD et de FreeBSD, et sous Windows via le pilote WireGuardNT. En espace utilisateur : wireguard-go, implémentation officielle en Go utilisée par les clients macOS, iOS et Android quand le noyau n’offre rien, et BoringTun, écrite en Rust par Cloudflare. Les produits maillés embarquent en général une implémentation en espace utilisateur dans leur agent : l’état du tunnel se lit alors avec l’outil du produit, pas avec wg.

Prérequis à vérifier avant tout dessin : une implémentation disponible et maintenue sur chaque plateforme du parc ; un port UDP joignable sur au moins un des deux pairs de chaque tunnel ; le transfert IP activé sur les passerelles ; un plan d’adressage sans chevauchement entre sites et tunnel (voir IPv4, CIDR et plans d’adressage) ; un canal authentifié pour échanger les clés publiques, car WireGuard n’en fournit aucun.

Ce que WireGuard ne fait pas : identité, révocation, journaux et clés statiques

WireGuard ne fait pas d’authentification d’utilisateur comme un tournevis ne fait pas de café : ce n’est pas un oubli, c’est le périmètre. Ce qui manque, par conception :

Authentification d’utilisateur et MFA (Multi-Factor Authentication). WireGuard authentifie une clé, donc un fichier sur un appareil. Un poste volé et déverrouillé est un pair légitime. L’identité de la personne vient d’ailleurs : bastion, application, ou couche de gestion qui conditionne la distribution des clés à une authentification.
Lien avec un annuaire ou un fournisseur d’identité. Désactiver un compte ne ferme aucun tunnel.
Attribution d’adresses et distribution de configuration. Adresses, routes et résolveurs de noms sont statiques, écrits à la main ou par un outil.
Révocation centralisée. Ni liste de révocation, ni expiration : il faut retirer la clé publique de chaque pair qui la connaît. Un seul endroit en étoile, tous les nœuds en maillage. Bon côté : ce retrait coupe la session en cours immédiatement, là où la révocation d’un certificat laisse souvent vivre les sessions établies.
Journal de connexions. L’état exposé se limite, par pair, à la dernière poignée de main, au dernier point de terminaison et aux compteurs d’octets. Aucun événement de connexion, de déconnexion ou d’échec ; les tentatives rejetées ne laissent rien par défaut.
Dissimulation du trafic. Type de message lisible dans le premier octet, messages de poignée de main de taille fixe : une inspection de paquets identifie WireGuard sans effort.

Reste la clé privée : 32 octets en base64 dans un fichier, sans phrase de passe ni, dans les implémentations de référence, de stockage sur jeton matériel. Ce que cela exige en exploitation :

Droits et coffre. Fichier lisible par le seul compte d’administration, hors du dépôt de configuration, ou clé tirée d’un coffre au démarrage.
Une clé par appareil, générée sur l’appareil. Une clé partagée interdit l’attribution et la révocation ciblée ; une clé générée par un serveur puis envoyée au poste a déjà voyagé.
Rotation. Aucune expiration native, donc un calendrier et un inventaire (clé publique, appareil, responsable). Tourner une clé, c’est générer une nouvelle paire et pousser la clé publique à tous les pairs concernés ; la clé pré-partagée suit le même régime.
Supervision. Collecter par clé publique l’âge de la dernière poignée de main et les compteurs. Alerter sur un pair absent de l’inventaire, sur un point de terminaison inattendu pour une passerelle fixe, sur un pair muet depuis longtemps (candidat au retrait). Attention : une interface configurée est « montée » même si le pair est injoignable, et une poignée de main ancienne sur un tunnel au repos n’est pas une panne. Seule une sonde à travers le tunnel prouve qu’il fonctionne.
Sauvegarde et reprise. Restaurer la clé d’une passerelle évite de retoucher tous ses pairs, au prix d’une copie du secret dans les sauvegardes (à chiffrer). Pour un poste, ne rien sauvegarder : régénérer et réenrôler.

Réseaux maillés au-dessus de WireGuard : coordinateur, traversée de NAT et relais

Additionner ce qui précède : inventaire, distribution des clés publiques, adresses, routes, révocation, identité. Au-delà d’une poignée de pairs, quelqu’un écrit cette couche. Reste à savoir si c’est un script hérité que plus personne ne relit ou un produit. En maillage complet, chaque nœud doit connaître tous les autres : la configuration à la main ne survit pas à la deuxième dizaine.

Les produits de réseau maillé (Tailscale, NetBird, Netmaker ; Headscale comme coordinateur auto-hébergé compatible avec les clients Tailscale) ajoutent trois briques. Un plan de contrôle, le coordinateur : chaque nœud s’y authentifie, y publie sa clé publique et en reçoit celles des autres avec leurs adresses et les règles d’accès ; les clés privées ne quittent pas les nœuds. Une traversée de NAT : chaque nœud découvre son adresse vue de l’extérieur, le coordinateur échange ces candidates, et les deux côtés émettent en même temps pour ouvrir leurs associations. Des relais, pour les cas où cela échoue (certains NAT, UDP filtré) : ils transportent des paquets WireGuard déjà chiffrés, souvent dans une connexion TLS (Transport Layer Security) qui passe là où l’UDP ne passe pas.

À lire dans le schéma : le coordinateur ne touche jamais au trafic, le relais ne peut pas le lire, mais c’est le coordinateur qui décide quelles clés chaque nœud accepte.

Le coordinateur ne voit ni clé privée ni contenu. Il voit qui parle à qui, et surtout il distribue les clés publiques : un coordinateur compromis, un compte d’administration détourné ou un fournisseur d’identité piégé en amont peut ajouter un pair, lui attribuer des routes, réécrire les règles. Le chiffrement de bout en bout tient toujours ; il protège avec le plus grand sérieux une conversation avec le mauvais interlocuteur.

Conséquences pour le placement de la confiance :

Traiter le coordinateur comme une autorité de certification. Même niveau de protection, comptes d’administration sous authentification forte, journal des modifications exporté, alerte sur tout ajout de nœud.
Auto-héberger déplace la confiance, sans la supprimer. On échange la dépendance à un éditeur contre la charge de durcir, mettre à jour et tenir disponible le service. Selon le produit, les tunnels établis survivent en général à une panne du coordinateur ; les nouveaux enrôlements et les changements de règles, non.
Retirer au coordinateur le monopole de l’admission. Certains produits font signer les clés des nouveaux nœuds par des nœuds déjà approuvés (Tailnet Lock chez Tailscale). Quand la fonction existe, l’activer.
Ne pas confondre le produit et le protocole. Règles d’accès, authentification unique, expiration des clés de nœud, relais : fonctions du produit. Changer de produit, c’est tout refaire, WireGuard ou pas.

Ces produits se vendent sous l’étiquette Zero Trust ; la plaquette dit « sans périmètre », l’architecture dit que le périmètre a déménagé dans une base de clés publiques. Le débat de fond est dans Le VPN d’entreprise est-il mort ?.

WireGuard face à IPsec/IKEv2 et OpenVPN : choisir par cas d’usage

Le compromis central tient en une ligne : WireGuard échange des fonctions contre un cœur réduit et lisible. On gagne une surface d’attaque minuscule avant authentification (pas de négociation, pas d’analyseur de certificats exposé), de bonnes performances et une configuration qui tient sur un écran. On paie tout ce qui touche à l’identité et au cycle de vie, à reconstruire ailleurs.

Critère	WireGuard	IPsec/IKEv2	OpenVPN
Négociation cryptographique	aucune, primitives fixes	suites négociées, profil à verrouiller	suites TLS négociées
Authentification	clés publiques brutes, clé pré-partagée optionnelle	certificats, clés pré-partagées, EAP (Extensible Authentication Protocol) pour l’utilisateur	certificats, identifiant et mot de passe, greffons
Interopérabilité entre constructeurs	partielle	la référence : tout pare-feu le parle	client logiciel partout, rare en natif sur équipement
Transport	UDP seul	UDP et protocole dédié	UDP ou TCP
Base de code à auditer	réduite	vaste, options innombrables	vaste, plus une bibliothèque TLS

Certificats contre clés brutes. Une PKI (Public Key Infrastructure) apporte expiration, révocation, attributs d’identité et délégation. Les clés brutes n’apportent rien de tout cela, et rien à analyser avant authentification non plus. Sans couche de gestion, c’est un recul d’exploitation ; avec, c’est la couche de gestion qui joue le rôle de la PKI.

Analyses formelles. Le protocole a fait l’objet de travaux publiés : vérification symbolique avec Tamarin par Donenfeld et Milner, analyse calculatoire par Dowling et Paterson, preuve mécanisée avec CryptoVerif par Lipp, Blanchet et Bhargavan. Ces résultats portent sur le protocole, pas sur une implémentation, encore moins sur le coordinateur d’un produit maillé.

Performances. L’implémentation noyau répartit le chiffrement sur plusieurs cœurs, et ChaCha20 est rapide sans accélération matérielle. Sur du matériel qui accélère AES (Advanced Encryption Standard) ou déporte IPsec sur la carte réseau, IPsec fait jeu égal ou mieux. Mesurer sur son propre matériel avant d’en faire un argument.

Conformité. L’ANSSI (Agence nationale de la sécurité des systèmes d’information) publie des recommandations de sécurité consacrées à IPsec. Quand un cadre contractuel ou réglementaire impose un produit qualifié ou une liste fermée d’algorithmes, WireGuard n’a aucune marge puisque rien n’y est négociable : c’est le texte applicable et le catalogue de produits qu’il faut lire, pas une page de documentation.

Verdict par cas d’usage :

Site à site entre équipements hétérogènes, ou gérés par deux organisations : IPsec/IKEv2. L’interopérabilité prime, et les pièges sont connus (voir tunnels GRE (Generic Routing Encapsulation) et IPsec site à site et TLS, VPN et IPsec).
Site à site entre passerelles maîtrisées des deux côtés : WireGuard, avec filtrage explicite sur l’interface.
Accès d’administration : WireGuard en première porte (port invisible, surface minime), une clé par poste d’administration, et un bastion derrière pour l’identité et la traçabilité.
Petite structure, poignée de pairs : WireGuard nu en étoile, configuration versionnée sans les clés privées.
Flotte de postes nomades : jamais WireGuard nu. Produit maillé si la confiance placée dans un coordinateur est acceptable et outillée ; sinon IKEv2 ou OpenVPN adossé au fournisseur d’identité. OpenVPN garde un avantage net : passer en TCP sur les réseaux hostiles à l’UDP.

🐝 Ce qui arrive si on s’en passe

Sans tunnel authentifié par des clés propres à chaque appareil, les services d’administration finissent exposés tels quels, visibles au premier balayage, ou cachés derrière un secret commun à toute une équipe : aucune connexion n’est alors attribuable à un appareil, et retirer un accès revient à changer le secret de tout le monde. Sans inventaire reliant chaque clé publique à un appareil et à un responsable, la révocation devient une fouille de fichiers, et un pair oublié garde son accès indéfiniment puisqu’une clé statique n’expire pas. Sans surveillance de ce que distribue le coordinateur, un pair ajouté par un tiers reçoit des routes légitimes, et rien dans le plan de données ne le distingue des autres.

🦫 Explication de la marmotte 🍫

Chaque appareil fabrique deux clés liées : une secrète qu’il garde, une publique qu’il donne aux appareils avec lesquels il doit parler. Avant d’échanger, deux appareils s’envoient un message chacun. Ces deux messages prouvent que chacun possède sa clé secrète et servent à calculer une clé temporaire, remplacée toutes les deux minutes environ : voler une clé temporaire ne permet de lire que quelques minutes d’échanges. Chaque appareil tient aussi une liste qui dit quelle clé publique a le droit d’utiliser quelles adresses. Cette liste sert deux fois : elle décide à qui envoyer un message, et elle fait rejeter un message reçu qui prétend venir d’une adresse non prévue. Un message qui ne vient pas d’une clé connue ne reçoit aucune réponse. Le logiciel s’arrête là, volontairement. Il ne vérifie pas qui est assis devant l’écran, ne distribue pas les réglages, ne tient pas de registre des connexions et ne sait pas retirer une clé partout d’un coup. Quand les appareils sont nombreux, un service central s’en charge : il annonce à chacun les clés publiques des autres et aide deux appareils à se joindre directement. Si ce service est piraté, il peut présenter un intrus comme un membre légitime. Enfin, si le réseau bloque le type de messages utilisé, rien ne passe, sauf par un serveur intermédiaire qui recopie les messages sans pouvoir les lire.

Pages voisines

La citent

WireGuard et VPN maillés, fonctionnement, AllowedIPs et limites

Elle cite

: les deux pages se citent l’une l’autre.

WireGuard et VPN maillés, fonctionnement, AllowedIPs et limites

WireGuard et VPN maillés, fonctionnement, AllowedIPs et limites

Le protocole WireGuard : poignée de main Noise et primitives fixes

Cryptokey routing : AllowedIPs, table de routage et filtre d’origine

Exemple : lire AllowedIPs sur un concentrateur et deux pairs

Comportement réseau de WireGuard : UDP, cookie, itinérance et MTU

Implémentations de WireGuard : noyau Linux, espace utilisateur et prérequis

Ce que WireGuard ne fait pas : identité, révocation, journaux et clés statiques

Réseaux maillés au-dessus de WireGuard : coordinateur, traversée de NAT et relais

WireGuard face à IPsec/IKEv2 et OpenVPN : choisir par cas d’usage

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines