{"id":66,"date":"2026-06-11T20:33:02","date_gmt":"2026-06-11T20:33:02","guid":{"rendered":"https:\/\/shattered.io\/fr\/2026\/06\/11\/vpn-wireguard-linux\/"},"modified":"2026-06-11T20:34:22","modified_gmt":"2026-06-11T20:34:22","slug":"vpn-wireguard-linux","status":"publish","type":"post","link":"https:\/\/shattered.io\/fr\/2026\/06\/11\/vpn-wireguard-linux\/","title":{"rendered":"VPN WireGuard sur Linux : 12 \u00e9tapes, 30 min [2026]"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">Un VPN auto-h\u00e9berg\u00e9 avec <strong>WireGuard<\/strong> chiffre tout votre trafic, contourne la censure r\u00e9seau et vous rend votre vie priv\u00e9e pour le prix d&#8217;un petit serveur, environ 5 \u20ac par mois. L\u00e0 o\u00f9 OpenVPN tra\u00eene 100 000 lignes de code et IPsec en aligne encore davantage, WireGuard tient dans \u00e0 peine 4 000 lignes, ce qui le rend plus rapide, plus simple \u00e0 auditer et bien plus facile \u00e0 configurer. Fusionn\u00e9 dans le noyau Linux 5.6 le 29 mars 2020, il est aujourd&#8217;hui pr\u00e9sent par d\u00e9faut sur toutes les distributions modernes. NordVPN (NordLynx) et Mullvad s&#8217;appuient sur lui pour leurs offres commerciales.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ce tutoriel vous guide pas \u00e0 pas, en 12 \u00e9tapes et environ 30 minutes, pour d\u00e9ployer votre propre serveur WireGuard sur un VPS Ubuntu 24.04 ou Debian 12, y connecter vos ordinateurs et vos t\u00e9l\u00e9phones, et durcir l&#8217;installation contre les fuites DNS. Tout est test\u00e9 pour 2026, avec les commandes exactes, des exemples de sortie r\u00e9els et une section de d\u00e9pannage compl\u00e8te. Aucune connaissance pr\u00e9alable des VPN n&#8217;est requise, mais une aisance avec la ligne de commande Linux aide.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"pourquoi-choisir-wireguard-pour-un-vpn-en-2026\">Pourquoi choisir WireGuard pour un VPN en 2026<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">WireGuard a red\u00e9fini ce qu&#8217;on attend d&#8217;un protocole VPN. Sa philosophie tient en un mot : la simplicit\u00e9. Le code source complet du module noyau repr\u00e9sente environ 4 000 lignes, contre des dizaines de milliers pour OpenVPN et plusieurs centaines de milliers pour la pile IPsec\/StrongSwan. Cette compacit\u00e9 n&#8217;est pas qu&#8217;une coquetterie d&#8217;ing\u00e9nieur. Moins de code signifie moins de surface d&#8217;attaque, des audits de s\u00e9curit\u00e9 plus rapides et bien moins de bugs exploitables. Des cryptographes ont relu le protocole, qui s&#8217;appuie sur des primitives modernes et \u00e9prouv\u00e9es.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">C\u00f4t\u00e9 cryptographie, WireGuard fait des choix tranch\u00e9s et n&#8217;offre aucune option \u00e0 configurer, ce qui \u00e9limine les erreurs de param\u00e9trage. L&#8217;\u00e9change de cl\u00e9s utilise <strong>Curve25519<\/strong> (ECDH), le chiffrement authentifi\u00e9 repose sur <strong>ChaCha20-Poly1305<\/strong>, le hachage sur <strong>BLAKE2s<\/strong>, et la protection contre le d\u00e9ni de service sur <strong>SipHash24<\/strong>. La d\u00e9rivation de cl\u00e9s passe par HKDF. Contrairement \u00e0 OpenVPN, vous ne choisissez pas votre suite de chiffrement : tout le monde utilise la m\u00eame, la meilleure disponible. Si une faille \u00e9tait d\u00e9couverte dans une primitive, WireGuard pr\u00e9voit un m\u00e9canisme de versionnage pour migrer l&#8217;ensemble du r\u00e9seau.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La performance ach\u00e8ve de convaincre. WireGuard tourne dans l&#8217;espace noyau, ce qui \u00e9vite les co\u00fbteux changements de contexte entre l&#8217;espace utilisateur et le noyau que subit OpenVPN. Sur des tests publi\u00e9s par Protectli sous OPNsense, WireGuard atteint 2,18 \u00e0 4,15 Gbit\/s selon le mat\u00e9riel, tandis qu&#8217;OpenVPN plafonne entre 816 Mbit\/s et 1,09 Gbit\/s dans les m\u00eames conditions. L&#8217;analyse de Zenarmor r\u00e9sume un d\u00e9bit sup\u00e9rieur d&#8217;environ 15 % et une latence inf\u00e9rieure d&#8217;environ 20 % par rapport \u00e0 IPsec. Les chiffres exacts varient selon le processeur, le MTU et la taille des paquets, mais la tendance est constante : WireGuard est le protocole le plus rapide sur la quasi-totalit\u00e9 des configurations.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Dernier atout, l&#8217;exp\u00e9rience utilisateur. Le concept de \u00ab cryptokey routing \u00bb associe chaque cl\u00e9 publique \u00e0 une plage d&#8217;adresses IP autoris\u00e9es, ce qui rend la configuration d\u00e9clarative et lisible. Un fichier de configuration WireGuard tient en une dizaine de lignes au format INI, l\u00e0 o\u00f9 une configuration OpenVPN \u00e9quivalente en demande souvent plus de cinquante, r\u00e9parties dans plusieurs fichiers de certificats. Cette lisibilit\u00e9 est pr\u00e9cieuse quand vous g\u00e9rez vous-m\u00eame votre infrastructure.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"wireguard-contre-openvpn-et-ipsec-le-comparatif\">WireGuard contre OpenVPN et IPsec : le comparatif<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Avant de mettre les mains dans le cambouis, situons WireGuard face aux deux protocoles historiques. Le tableau ci-dessous synth\u00e9tise les diff\u00e9rences structurelles qui expliquent pourquoi tant de fournisseurs et d&#8217;administrateurs ont migr\u00e9 vers WireGuard depuis 2022. Gardez en t\u00eate que les d\u00e9bits d\u00e9pendent du mat\u00e9riel : ils servent \u00e0 illustrer un ordre de grandeur, pas \u00e0 promettre un r\u00e9sultat exact sur votre serveur.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Crit\u00e8re<\/th><th>WireGuard<\/th><th>OpenVPN<\/th><th>IPsec\/IKEv2<\/th><\/tr><\/thead><tbody><tr><td>Lignes de code<\/td><td>\u2248 4 000<\/td><td>\u2248 100 000<\/td><td>\u2248 400 000+<\/td><\/tr><tr><td>D\u00e9bit (test Protectli)<\/td><td>2,18 \u00e0 4,15 Gbit\/s<\/td><td>0,82 \u00e0 1,09 Gbit\/s<\/td><td>1,87 \u00e0 2,25 Gbit\/s<\/td><\/tr><tr><td>Espace d&#8217;ex\u00e9cution<\/td><td>Noyau<\/td><td>Espace utilisateur<\/td><td>Noyau<\/td><\/tr><tr><td>Transport<\/td><td>UDP uniquement<\/td><td>UDP ou TCP<\/td><td>UDP (ESP)<\/td><\/tr><tr><td>Cryptographie<\/td><td>Fixe (ChaCha20-Poly1305)<\/td><td>Configurable (OpenSSL)<\/td><td>Configurable<\/td><\/tr><tr><td>Port par d\u00e9faut<\/td><td>51820\/UDP<\/td><td>1194\/UDP<\/td><td>500 et 4500\/UDP<\/td><\/tr><tr><td>Temps de configuration<\/td><td>\u2248 10 lignes<\/td><td>50+ lignes<\/td><td>\u00c9lev\u00e9<\/td><\/tr><tr><td>Reconnexion (roaming)<\/td><td>Transparente<\/td><td>Lente<\/td><td>Moyenne<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">La colonne \u00ab reconnexion \u00bb m\u00e9rite une explication. WireGuard est sans \u00e9tat au sens o\u00f9 il ne maintient pas de session permanente : chaque paquet porte les informations n\u00e9cessaires pour \u00eatre rout\u00e9 vers le bon pair. Quand votre t\u00e9l\u00e9phone passe du Wi-Fi \u00e0 la 5G, la connexion bascule instantan\u00e9ment sans ren\u00e9gociation. C&#8217;est un confort d\u00e9terminant pour un usage mobile, l\u00e0 o\u00f9 OpenVPN impose souvent une reconnexion visible de plusieurs secondes.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">L&#8217;unique transport UDP est \u00e0 la fois une force et une limite. Une force, car UDP \u00e9vite le probl\u00e8me de \u00ab TCP sur TCP \u00bb qui d\u00e9grade les d\u00e9bits d&#8217;OpenVPN en mode TCP. Une limite, car certains r\u00e9seaux d&#8217;entreprise ou h\u00f4tels bloquent l&#8217;UDP non standard. Si vous devez traverser ces r\u00e9seaux, vous combinerez WireGuard avec un outil d&#8217;obfuscation comme <code>udp2raw<\/code> ou un tunnel TCP, sujet que nous \u00e9voquerons dans les conseils avanc\u00e9s. Pour comprendre comment le chiffrement de transport prot\u00e8ge vos \u00e9changes au quotidien, notre article sur <a href=\"\/fr\/https-et-tls\/\">HTTPS et TLS<\/a> pose des bases utiles.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"prerequis-et-versions-necessaires\">Pr\u00e9requis et versions n\u00e9cessaires<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">R\u00e9unissez ces \u00e9l\u00e9ments avant de commencer. Les versions indiqu\u00e9es sont celles valid\u00e9es pour ce tutoriel en juin 2026 ; des versions plus r\u00e9centes fonctionneront sans difficult\u00e9 puisque WireGuard est int\u00e9gr\u00e9 au noyau.<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>Un serveur (VPS) Linux<\/strong> avec une adresse IP publique : Ubuntu 24.04 LTS ou Debian 12, noyau 5.6 ou sup\u00e9rieur. Un petit VPS \u00e0 1 vCPU et 1 Go de RAM suffit largement (offres \u00e0 partir de 4 \u00e0 5 \u20ac par mois chez la plupart des h\u00e9bergeurs europ\u00e9ens).<\/li><li><strong>Un acc\u00e8s root ou sudo<\/strong> sur ce serveur, via SSH.<\/li><li><strong>Le paquet wireguard<\/strong> version 1.0.x (outils <code>wg<\/code> et <code>wg-quick<\/code>), disponible dans les d\u00e9p\u00f4ts officiels.<\/li><li><strong>Un client<\/strong> : application WireGuard officielle pour Windows, macOS, Linux, iOS (App Store) ou Android (Google Play \/ F-Droid), toutes en version stable 2026.<\/li><li><strong>Le port UDP 51820<\/strong> ouvert et rout\u00e9 jusqu&#8217;\u00e0 votre serveur (\u00e0 v\u00e9rifier chez votre h\u00e9bergeur si un pare-feu externe existe).<\/li><li><strong>Environ 30 minutes<\/strong> et une connaissance de base de la ligne de commande Linux (\u00e9diter un fichier, lancer un service).<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">V\u00e9rifiez d&#8217;embl\u00e9e la version de votre noyau, car WireGuard a besoin du support int\u00e9gr\u00e9 (5.6+) pour fonctionner sans module externe. Sur la quasi-totalit\u00e9 des VPS r\u00e9cents, c&#8217;est acquis.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>$ uname -r\n6.8.0-31-generic\n\n$ lsb_release -d\nDescription:    Ubuntu 24.04.1 LTS<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"etape-1-preparer-le-serveur-et-mettre-a-jour-le-systeme\">\u00c9tape 1 : Pr\u00e9parer le serveur et mettre \u00e0 jour le syst\u00e8me<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Connectez-vous \u00e0 votre VPS en SSH, puis mettez \u00e0 jour la liste des paquets et le syst\u00e8me. Un syst\u00e8me \u00e0 jour \u00e9vite les conflits de d\u00e9pendances et corrige les failles connues avant m\u00eame d&#8217;exposer un nouveau service au r\u00e9seau. Travaillez en tant qu&#8217;utilisateur disposant de <code>sudo<\/code>, jamais directement en root pour vos op\u00e9rations quotidiennes.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Se connecter au serveur\nssh utilisateur@VOTRE_IP_PUBLIQUE\n\n# Mettre \u00e0 jour les d\u00e9p\u00f4ts et le syst\u00e8me\nsudo apt update &amp;&amp; sudo apt upgrade -y\n\n# Identifier l'interface r\u00e9seau publique (souvent eth0 ou ens3)\nip route list default\n# default via 203.0.113.1 dev eth0 proto static<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Notez le nom de l&#8217;interface publique affich\u00e9 apr\u00e8s <code>dev<\/code> dans la derni\u00e8re commande. Dans cet exemple, c&#8217;est <code>eth0<\/code>, mais sur de nombreux VPS modernes elle s&#8217;appelle <code>ens3<\/code>, <code>enp1s0<\/code> ou similaire. Vous en aurez besoin \u00e0 l&#8217;\u00e9tape 6 pour la r\u00e8gle de NAT. Notez aussi votre adresse IP publique, que les clients utiliseront comme point de terminaison (endpoint). Si vous ne la connaissez pas, r\u00e9cup\u00e9rez-la ainsi :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>$ curl -4 ifconfig.co\n203.0.113.42<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Profitez de cette \u00e9tape pour durcir votre acc\u00e8s SSH si ce n&#8217;est pas d\u00e9j\u00e0 fait : d\u00e9sactivez l&#8217;authentification par mot de passe au profit des cl\u00e9s, et changez \u00e9ventuellement le port par d\u00e9faut. Un serveur VPN devient une porte d&#8217;entr\u00e9e vers tout votre trafic ; il m\u00e9rite une hygi\u00e8ne de s\u00e9curit\u00e9 irr\u00e9prochable. Notre guide sur la <a href=\"\/fr\/securite-des-mots-de-passe\/\">s\u00e9curit\u00e9 des mots de passe<\/a> d\u00e9taille pourquoi les cl\u00e9s valent toujours mieux qu&#8217;un mot de passe, aussi long soit-il.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"etape-2-installer-wireguard\">\u00c9tape 2 : Installer WireGuard<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">L&#8217;installation se r\u00e9sume \u00e0 un seul paquet. Sur Ubuntu et Debian, le paquet <code>wireguard<\/code> tire automatiquement les outils en espace utilisateur (<code>wireguard-tools<\/code>, qui fournit <code>wg<\/code> et <code>wg-quick<\/code>). Le module noyau, lui, est d\u00e9j\u00e0 pr\u00e9sent puisqu&#8217;il fait partie du noyau Linux depuis la version 5.6.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Installer WireGuard et ses outils\nsudo apt install wireguard wireguard-tools -y\n\n# V\u00e9rifier que les binaires sont disponibles\nwg --version\n# wireguard-tools v1.0.20210914 - https:\/\/git.zx2c4.com\/wireguard-tools\/\n\n# V\u00e9rifier que le module noyau se charge\nsudo modprobe wireguard &amp;&amp; echo \"Module WireGuard OK\"\n# Module WireGuard OK<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Si la commande <code>wg --version<\/code> renvoie un num\u00e9ro, vous \u00eates pr\u00eat. Sur un noyau ant\u00e9rieur \u00e0 5.6 (rare en 2026, sauf syst\u00e8mes tr\u00e8s anciens), il faudrait installer le module DKMS via <code>wireguard-dkms<\/code>, mais ce cas est devenu marginal. Sur les conteneurs LXC ou OpenVZ non privil\u00e9gi\u00e9s, le module noyau peut \u00eatre absent et inaccessible ; vous devrez alors utiliser l&#8217;impl\u00e9mentation en espace utilisateur <code>wireguard-go<\/code> ou demander \u00e0 votre h\u00e9bergeur un noyau compatible. V\u00e9rifiez ce point avant d&#8217;aller plus loin si vous \u00eates sur un VPS tr\u00e8s bas de gamme.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"etape-3-generer-les-cles-cryptographiques-du-serveur\">\u00c9tape 3 : G\u00e9n\u00e9rer les cl\u00e9s cryptographiques du serveur<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">WireGuard repose sur une paire de cl\u00e9s Curve25519 par pair. Le serveur a la sienne, chaque client a la sienne. La cl\u00e9 priv\u00e9e ne doit jamais quitter la machine qui la d\u00e9tient ; seule la cl\u00e9 publique est partag\u00e9e. G\u00e9n\u00e9rons d&#8217;abord la paire du serveur, en restreignant imm\u00e9diatement les permissions pour que personne d&#8217;autre que root ne puisse lire la cl\u00e9 priv\u00e9e.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Se placer dans le dossier de config et durcir l'umask\ncd \/etc\/wireguard\numask 077\n\n# G\u00e9n\u00e9rer la cl\u00e9 priv\u00e9e puis en d\u00e9river la cl\u00e9 publique\nwg genkey | sudo tee server_private.key | wg pubkey | sudo tee server_public.key\n\n# Afficher les deux cl\u00e9s (\u00e0 conserver pour la config)\necho \"Privee serveur : $(sudo cat server_private.key)\"\necho \"Publique serveur : $(sudo cat server_public.key)\"<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">La sortie ressemble \u00e0 ceci (vos cl\u00e9s seront diff\u00e9rentes, ce sont des cha\u00eenes en base64 de 44 caract\u00e8res) :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Privee serveur : 4Hn9c0xJ2vQpL8mZ3kF7sT1yB6dW0aR5eN2uG8hK4M=\nPublique serveur : xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">L&#8217;<code>umask 077<\/code> garantit que les fichiers cr\u00e9\u00e9s ne sont lisibles que par leur propri\u00e9taire. C&#8217;est crucial : quiconque obtient la cl\u00e9 priv\u00e9e du serveur peut d\u00e9chiffrer le trafic et usurper son identit\u00e9. Pour aller plus loin sur la s\u00e9curit\u00e9, vous pouvez ajouter une <strong>cl\u00e9 pr\u00e9-partag\u00e9e<\/strong> (PresharedKey) entre chaque paire de pairs, qui ajoute une couche de protection sym\u00e9trique utile contre une future attaque quantique sur Curve25519. G\u00e9n\u00e9rez-la avec <code>wg genpsk<\/code> et nous verrons o\u00f9 l&#8217;ins\u00e9rer \u00e0 l&#8217;\u00e9tape 5.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"etape-4-activer-le-routage-ip-avec-sysctl\">\u00c9tape 4 : Activer le routage IP avec sysctl<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Pour que votre serveur fasse transiter le trafic des clients vers Internet (le r\u00f4le d&#8217;un VPN \u00ab full tunnel \u00bb), il doit se comporter en routeur. Par d\u00e9faut, Linux ne transmet pas les paquets d&#8217;une interface \u00e0 l&#8217;autre. Activons donc le forwarding IPv4 (et IPv6 si vous l&#8217;utilisez) de fa\u00e7on persistante.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Activer le forwarding de fa\u00e7on permanente\necho 'net.ipv4.ip_forward=1' | sudo tee \/etc\/sysctl.d\/99-wireguard.conf\necho 'net.ipv6.conf.all.forwarding=1' | sudo tee -a \/etc\/sysctl.d\/99-wireguard.conf\n\n# Appliquer imm\u00e9diatement sans red\u00e9marrer\nsudo sysctl --system\n\n# V\u00e9rifier la valeur\nsysctl net.ipv4.ip_forward\n# net.ipv4.ip_forward = 1<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Le r\u00e9sultat <code>net.ipv4.ip_forward = 1<\/code> confirme que le serveur acheminera d\u00e9sormais les paquets entre l&#8217;interface WireGuard et l&#8217;interface publique. Si vous n&#8217;avez pas besoin d&#8217;IPv6, vous pouvez omettre la seconde ligne, mais l&#8217;activer \u00e9vite les fuites d&#8217;adresse IPv6 r\u00e9elle lorsque vos clients ont une connectivit\u00e9 IPv6 native. Nous reviendrons sur ce risque de fuite \u00e0 l&#8217;\u00e9tape 11. Placer la directive dans un fichier d\u00e9di\u00e9 sous <code>\/etc\/sysctl.d\/<\/code> plut\u00f4t que dans <code>\/etc\/sysctl.conf<\/code> garde votre configuration propre et facile \u00e0 retirer.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"etape-5-rediger-la-configuration-du-serveur-wg0-conf\">\u00c9tape 5 : R\u00e9diger la configuration du serveur (wg0.conf)<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Voici le c\u0153ur du dispositif. Cr\u00e9ez le fichier <code>\/etc\/wireguard\/wg0.conf<\/code>. Le nom <code>wg0<\/code> deviendra le nom de l&#8217;interface r\u00e9seau virtuelle. La section <code>[Interface]<\/code> d\u00e9crit le serveur lui-m\u00eame : sa cl\u00e9 priv\u00e9e, son adresse dans le r\u00e9seau du tunnel et le port d&#8217;\u00e9coute. Nous choisissons le sous-r\u00e9seau priv\u00e9 <code>10.8.0.0\/24<\/code> pour le VPN, avec le serveur en <code>10.8.0.1<\/code>.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># \/etc\/wireguard\/wg0.conf  (sur le SERVEUR)\n[Interface]\nAddress = 10.8.0.1\/24\nListenPort = 51820\nPrivateKey = 4Hn9c0xJ2vQpL8mZ3kF7sT1yB6dW0aR5eN2uG8hK4M=\n\n# Regles de NAT appliquees au demarrage et a l'arret du tunnel\nPostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE\nPostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE\n\n# Les pairs (clients) seront ajoutes ci-dessous a l'etape 9<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Remplacez <code>PrivateKey<\/code> par la cl\u00e9 priv\u00e9e du serveur g\u00e9n\u00e9r\u00e9e \u00e0 l&#8217;\u00e9tape 3, et <code>eth0<\/code> par le nom r\u00e9el de votre interface publique relev\u00e9 \u00e0 l&#8217;\u00e9tape 1. Les jetons <code>%i<\/code> sont remplac\u00e9s automatiquement par <code>wg-quick<\/code> par le nom de l&#8217;interface (<code>wg0<\/code>). Les lignes <code>PostUp<\/code> et <code>PostDown<\/code> cr\u00e9ent et suppriment proprement les r\u00e8gles de pare-feu et de NAT en m\u00eame temps que le tunnel, ce qui \u00e9vite de laisser des r\u00e8gles orphelines.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si vous avez g\u00e9n\u00e9r\u00e9 une cl\u00e9 pr\u00e9-partag\u00e9e \u00e0 l&#8217;\u00e9tape 3, elle ne se place pas ici mais dans chaque bloc <code>[Peer]<\/code>, via la directive <code>PresharedKey<\/code>, et doit \u00eatre identique des deux c\u00f4t\u00e9s. Sauvegardez le fichier, puis v\u00e9rifiez ses permissions : il contient votre cl\u00e9 priv\u00e9e et ne doit \u00eatre lisible que par root.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo chmod 600 \/etc\/wireguard\/wg0.conf\nsudo ls -l \/etc\/wireguard\/wg0.conf\n# -rw------- 1 root root 412 juin 11 14:22 \/etc\/wireguard\/wg0.conf<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"etape-6-configurer-le-nat-avec-iptables-ou-nftables\">\u00c9tape 6 : Configurer le NAT avec iptables ou nftables<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Le NAT (masquerade) r\u00e9\u00e9crit l&#8217;adresse source des paquets des clients pour qu&#8217;ils semblent provenir du serveur, condition indispensable pour qu&#8217;Internet sache o\u00f9 renvoyer les r\u00e9ponses. \u00c0 l&#8217;\u00e9tape 5, nous avons plac\u00e9 la r\u00e8gle iptables directement dans <code>PostUp<\/code>, ce qui est la m\u00e9thode la plus simple et la plus portable. Si vous pr\u00e9f\u00e9rez g\u00e9rer le NAT s\u00e9par\u00e9ment, ou si votre distribution utilise nftables (devenu le d\u00e9faut sur Debian 12 et Ubuntu r\u00e9cents), voici les \u00e9quivalents.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Variante nftables (a placer dans PostUp\/PostDown ou un fichier dedie)\n# Creer la table et la chaine de NAT\nsudo nft add table ip wireguard\nsudo nft 'add chain ip wireguard postrouting { type nat hook postrouting priority 100 ; }'\nsudo nft add rule ip wireguard postrouting oifname \"eth0\" masquerade\n\n# Verifier la regle\nsudo nft list table ip wireguard<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Le tableau suivant clarifie le r\u00f4le de chaque r\u00e8gle de filtrage, une source fr\u00e9quente de confusion pour qui d\u00e9bute avec le routage Linux.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>R\u00e8gle<\/th><th>Cha\u00eene<\/th><th>R\u00f4le<\/th><\/tr><\/thead><tbody><tr><td>FORWARD -i wg0 ACCEPT<\/td><td>filter<\/td><td>Autorise le trafic entrant depuis le tunnel<\/td><\/tr><tr><td>FORWARD -o wg0 ACCEPT<\/td><td>filter<\/td><td>Autorise le trafic sortant vers le tunnel<\/td><\/tr><tr><td>POSTROUTING MASQUERADE<\/td><td>nat<\/td><td>R\u00e9\u00e9crit l&#8217;IP source vers l&#8217;IP publique<\/td><\/tr><tr><td>INPUT 51820\/udp ACCEPT<\/td><td>filter<\/td><td>Laisse passer les paquets WireGuard entrants<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Important : ne m\u00e9langez pas iptables et nftables sur le m\u00eame syst\u00e8me, car les deux peuvent entrer en conflit et cr\u00e9er des comportements impr\u00e9visibles. Choisissez une approche et tenez-vous-y. Sur Ubuntu 24.04, <code>iptables<\/code> est en r\u00e9alit\u00e9 une fa\u00e7ade (<code>iptables-nft<\/code>) au-dessus de nftables, donc la syntaxe iptables de l&#8217;\u00e9tape 5 fonctionne parfaitement et reste la plus simple pour la majorit\u00e9 des installations.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"etape-7-ouvrir-le-pare-feu-et-demarrer-le-service-systemd\">\u00c9tape 7 : Ouvrir le pare-feu et d\u00e9marrer le service systemd<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Si vous utilisez le pare-feu UFW (fr\u00e9quent sur Ubuntu), autorisez le port WireGuard et le SSH avant de d\u00e9marrer le tunnel, sinon vous risquez de vous verrouiller hors du serveur. Puis lancez le service via l&#8217;unit\u00e9 systemd <code>wg-quick@wg0<\/code>, qui lit votre <code>wg0.conf<\/code> et monte l&#8217;interface automatiquement.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Ouvrir les ports necessaires\nsudo ufw allow 22\/tcp comment 'SSH'\nsudo ufw allow 51820\/udp comment 'WireGuard'\nsudo ufw enable\n\n# Demarrer WireGuard et l'activer au demarrage\nsudo systemctl enable --now wg-quick@wg0\n\n# Verifier l'etat du service\nsudo systemctl status wg-quick@wg0 --no-pager<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Une sortie saine ressemble \u00e0 ceci, avec <code>active (exited)<\/code> qui est normal pour ce type d&#8217;unit\u00e9 oneshot :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>\u25cf wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0\n     Loaded: loaded (\/lib\/systemd\/system\/wg-quick@.service; enabled)\n     Active: active (exited) since Thu 2026-06-11 14:25:03 UTC\n    Process: 1843 ExecStart=\/usr\/bin\/wg-quick up wg0 (code=exited, status=0)<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Confirmez que l&#8217;interface est bien mont\u00e9e et que WireGuard \u00e9coute sur le bon port :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>$ sudo wg show\ninterface: wg0\n  public key: xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=\n  private key: (hidden)\n  listening port: 51820\n\n$ ip addr show wg0\n4: wg0: &lt;POINTOPOINT,NOARP,UP,LOWER_UP&gt; mtu 1420 qdisc noqueue state UNKNOWN\n    inet 10.8.0.1\/24 scope global wg0<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Aucun pair n&#8217;appara\u00eet encore, c&#8217;est normal : nous n&#8217;avons pas de client. Notez au passage le MTU de 1420 choisi automatiquement, un point que nous affinerons dans les r\u00e9glages avanc\u00e9s.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"etape-8-generer-les-cles-et-la-configuration-du-client\">\u00c9tape 8 : G\u00e9n\u00e9rer les cl\u00e9s et la configuration du client<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Chaque appareil client a sa propre paire de cl\u00e9s. Vous pouvez g\u00e9n\u00e9rer la paire sur le serveur par commodit\u00e9, mais l&#8217;approche la plus s\u00fbre est de la g\u00e9n\u00e9rer sur le client lui-m\u00eame, afin que sa cl\u00e9 priv\u00e9e ne transite jamais par le r\u00e9seau. Pour ce tutoriel, g\u00e9n\u00e9rons-la sur le serveur pour aller vite, puis nous transf\u00e9rerons uniquement la configuration finale au client.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Sur le serveur, generer la paire du premier client\ncd \/etc\/wireguard\nwg genkey | tee client1_private.key | wg pubkey > client1_public.key\n\necho \"Privee client1 : $(cat client1_private.key)\"\necho \"Publique client1 : $(cat client1_public.key)\"\n# Privee client1 : aF3kP9wQ2mL7nZ8xR5tY1bV6cD0eG4hJ8uN2sK7iM0=\n# Publique client1 : Hx7kLp2nQ9wZ4mR8tY1bV6cD0eG3hJ5uN8sK2iA9Bg=<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Cr\u00e9ez maintenant le fichier de configuration du client. Il refl\u00e8te celui du serveur en miroir : la section <code>[Interface]<\/code> d\u00e9crit le client (sa cl\u00e9 priv\u00e9e, son adresse <code>10.8.0.2<\/code> dans le tunnel, le serveur DNS \u00e0 utiliser), et la section <code>[Peer]<\/code> d\u00e9crit le serveur (sa cl\u00e9 publique, son point de terminaison public et les plages \u00e0 router).<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># client1.conf  (a transferer sur l'appareil CLIENT)\n[Interface]\nPrivateKey = aF3kP9wQ2mL7nZ8xR5tY1bV6cD0eG4hJ8uN2sK7iM0=\nAddress = 10.8.0.2\/24\nDNS = 1.1.1.1, 1.0.0.1\n\n[Peer]\nPublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=\nEndpoint = 203.0.113.42:51820\nAllowedIPs = 0.0.0.0\/0, ::\/0\nPersistentKeepalive = 25<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">La valeur <code>AllowedIPs = 0.0.0.0\/0, ::\/0<\/code> c\u00f4t\u00e9 client signifie \u00ab route tout mon trafic, IPv4 et IPv6, dans le tunnel \u00bb : c&#8217;est le mode full tunnel, qui masque votre IP et chiffre tout. Si vous vouliez seulement acc\u00e9der au r\u00e9seau priv\u00e9 du serveur (split tunnel), vous mettriez ici uniquement <code>10.8.0.0\/24<\/code>. Le <code>DNS = 1.1.1.1<\/code> force la r\u00e9solution via un r\u00e9solveur c\u00f4t\u00e9 tunnel, ce qui pr\u00e9vient les fuites DNS. Choisissez un r\u00e9solveur respectueux de la vie priv\u00e9e ; les enjeux sont les m\u00eames que ceux que nous d\u00e9crivons dans notre comparatif <a href=\"\/fr\/proton-mail-vs-tuta\/\">Proton Mail contre Tuta<\/a> sur la minimisation des m\u00e9tadonn\u00e9es.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"etape-9-declarer-le-client-comme-pair-sur-le-serveur\">\u00c9tape 9 : D\u00e9clarer le client comme pair sur le serveur<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Le serveur doit conna\u00eetre la cl\u00e9 publique du client et l&#8217;adresse qui lui est r\u00e9serv\u00e9e dans le tunnel. Ajoutez un bloc <code>[Peer]<\/code> \u00e0 la fin de <code>\/etc\/wireguard\/wg0.conf<\/code>. Notez la diff\u00e9rence essentielle avec le client : c\u00f4t\u00e9 serveur, <code>AllowedIPs<\/code> est restreint \u00e0 l&#8217;adresse unique du client (<code>\/32<\/code>), car ici cette directive sert d&#8217;autorisation et de routage, pas de redirection de trafic.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># A ajouter a la fin de \/etc\/wireguard\/wg0.conf sur le serveur\n[Peer]\n# client1\nPublicKey = Hx7kLp2nQ9wZ4mR8tY1bV6cD0eG3hJ5uN8sK2iA9Bg=\nAllowedIPs = 10.8.0.2\/32<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Vous pouvez recharger la configuration sans couper les connexions existantes gr\u00e2ce \u00e0 la combinaison <code>wg syncconf<\/code>, ce qui est pr\u00e9cieux en production. Voici la commande idiomatique qui applique le nouveau fichier \u00e0 chaud :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Recharger sans interrompre les pairs deja connectes\nsudo wg syncconf wg0 &lt;(wg-quick strip wg0)\n\n# Verifier que le pair apparait\nsudo wg show wg0 peers\n# Hx7kLp2nQ9wZ4mR8tY1bV6cD0eG3hJ5uN8sK2iA9Bg=<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Si vous pr\u00e9f\u00e9rez la simplicit\u00e9 au prix d&#8217;une br\u00e8ve coupure, un <code>sudo systemctl restart wg-quick@wg0<\/code> recharge tout le fichier. La m\u00e9thode <code>syncconf<\/code> reste recommand\u00e9e d\u00e8s que des utilisateurs sont connect\u00e9s. Une erreur classique consiste \u00e0 oublier ce rechargement apr\u00e8s avoir \u00e9dit\u00e9 le fichier : le serveur ignore alors le nouveau client et le handshake \u00e9choue silencieusement.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"etape-10-connecter-le-client-et-verifier-le-handshake\">\u00c9tape 10 : Connecter le client et v\u00e9rifier le handshake<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Transf\u00e9rez le fichier <code>client1.conf<\/code> sur votre appareil. Sur un poste Linux, copiez-le dans <code>\/etc\/wireguard\/<\/code> puis lancez <code>wg-quick up<\/code>. Sur Windows ou macOS, importez le fichier dans l&#8217;application WireGuard officielle. Sur mobile, nous g\u00e9n\u00e9rerons un QR code \u00e0 l&#8217;\u00e9tape 12 pour \u00e9viter de saisir les cl\u00e9s \u00e0 la main.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Sur un client Linux\nsudo cp client1.conf \/etc\/wireguard\/wg0.conf\nsudo wg-quick up wg0\n\n# Tester la connectivite vers le serveur dans le tunnel\nping -c 3 10.8.0.1\n# 64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=12.4 ms\n\n# Afficher l'etat et verifier le dernier handshake\nsudo wg show<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">La ligne d\u00e9cisive est <code>latest handshake<\/code>. Si elle affiche un instant r\u00e9cent, votre tunnel est \u00e9tabli et chiffr\u00e9. Vous devez aussi voir des compteurs <code>transfer<\/code> augmenter \u00e0 mesure que le trafic passe.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>$ sudo wg show\ninterface: wg0\n  public key: Hx7kLp2nQ9wZ4mR8tY1bV6cD0eG3hJ5uN8sK2iA9Bg=\n  private key: (hidden)\n  listening port: 51820\n\npeer: xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=\n  endpoint: 203.0.113.42:51820\n  allowed ips: 0.0.0.0\/0, ::\/0\n  latest handshake: 8 seconds ago\n  transfer: 1.24 MiB received, 320.50 KiB sent<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Si <code>latest handshake<\/code> n&#8217;appara\u00eet jamais, le probl\u00e8me vient presque toujours du pare-feu (port 51820\/UDP ferm\u00e9), d&#8217;une cl\u00e9 mal copi\u00e9e, ou d&#8217;un endpoint erron\u00e9. La section d\u00e9pannage ci-dessous passe ces cas en revue m\u00e9thodiquement.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"etape-11-empecher-les-fuites-dns-et-verifier-votre-ip-publique\">\u00c9tape 11 : Emp\u00eacher les fuites DNS et v\u00e9rifier votre IP publique<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Un tunnel \u00e9tabli ne suffit pas : encore faut-il que tout votre trafic, y compris les requ\u00eates DNS, passe r\u00e9ellement par lui. Une fuite DNS r\u00e9v\u00e8le les sites que vous visitez \u00e0 votre fournisseur d&#8217;acc\u00e8s, an\u00e9antissant l&#8217;int\u00e9r\u00eat du VPN. V\u00e9rifions d&#8217;abord que votre IP publique est bien celle du serveur, puis que le DNS ne fuit pas.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Votre IP publique doit desormais etre celle du serveur (203.0.113.42)\ncurl -4 ifconfig.co\n# 203.0.113.42\n\n# Verifier qu'aucune adresse IPv6 reelle ne fuit\ncurl -6 ifconfig.co 2&gt;\/dev\/null || echo \"Pas de fuite IPv6 (ou IPv6 routee dans le tunnel)\"<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Si <code>curl -4 ifconfig.co<\/code> renvoie l&#8217;adresse de votre serveur, le full tunnel fonctionne. Pour les fuites DNS, rendez-vous sur un service de test comme <code>dnsleaktest.com<\/code> depuis le navigateur du client : tous les serveurs DNS affich\u00e9s doivent correspondre au r\u00e9solveur que vous avez d\u00e9fini (ici 1.1.1.1), et aucun ne doit appartenir \u00e0 votre fournisseur d&#8217;acc\u00e8s. Sur Linux, si vous constatez une fuite malgr\u00e9 la directive <code>DNS =<\/code>, installez le paquet <code>openresolv<\/code> ou <code>resolvconf<\/code>, dont <code>wg-quick<\/code> a besoin pour r\u00e9\u00e9crire <code>\/etc\/resolv.conf<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Les fuites de donn\u00e9es personnelles ne se limitent pas au DNS : une mauvaise configuration de VPN peut exposer bien plus. Notre dossier sur les <a href=\"\/fr\/fuites-de-donnees\/\">fuites de donn\u00e9es<\/a> explique comment des m\u00e9tadonn\u00e9es en apparence anodines suffisent \u00e0 vous identifier. Pour un usage s\u00e9rieux, testez aussi les fuites WebRTC, que votre navigateur peut provoquer ind\u00e9pendamment du VPN.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"etape-12-ajouter-dautres-clients-et-un-qr-code-pour-mobile\">\u00c9tape 12 : Ajouter d&#8217;autres clients et un QR code pour mobile<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ajouter un appareil suit toujours le m\u00eame rituel : g\u00e9n\u00e9rer une paire de cl\u00e9s, attribuer la prochaine adresse libre (10.8.0.3, 10.8.0.4, etc.), cr\u00e9er le fichier client, puis d\u00e9clarer le pair sur le serveur et recharger. Pour les t\u00e9l\u00e9phones, l&#8217;application WireGuard sait importer une configuration en scannant un QR code, ce qui \u00e9vite toute saisie manuelle. Le paquet <code>qrencode<\/code> g\u00e9n\u00e8re ce code directement dans le terminal.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Installer le generateur de QR code\nsudo apt install qrencode -y\n\n# Generer la paire du telephone (client2 = 10.8.0.3)\ncd \/etc\/wireguard\nwg genkey | tee client2_private.key | wg pubkey > client2_public.key\n\n# Creer client2.conf (adapter l'adresse a 10.8.0.3)\n# ... meme structure qu'a l'etape 8 ...\n\n# Afficher le QR code a scanner depuis l'app WireGuard mobile\nqrencode -t ansiutf8 &lt; client2.conf<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Un damier de caract\u00e8res s&#8217;affiche dans votre terminal. Ouvrez l&#8217;application WireGuard sur le t\u00e9l\u00e9phone, choisissez \u00ab Ajouter un tunnel \u00bb, puis \u00ab Scanner un QR code \u00bb, et pointez l&#8217;appareil vers l&#8217;\u00e9cran. La configuration s&#8217;importe en une seconde, cl\u00e9s comprises. N&#8217;oubliez pas d&#8217;ajouter ensuite le bloc <code>[Peer]<\/code> correspondant sur le serveur (avec <code>AllowedIPs = 10.8.0.3\/32<\/code>) et de recharger avec <code>wg syncconf<\/code>, sinon le t\u00e9l\u00e9phone n&#8217;\u00e9tablira aucun handshake.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Veillez \u00e0 ne jamais r\u00e9utiliser la m\u00eame paire de cl\u00e9s pour deux appareils. Chaque pair doit \u00eatre unique, faute de quoi WireGuard m\u00e9lange les routes et la connexion devient instable. Documentez vos attributions d&#8217;adresses dans un simple fichier texte pour ne pas perdre le fil quand votre flotte d&#8217;appareils grandit.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"comprendre-allowedips-et-le-cryptokey-routing\">Comprendre AllowedIPs et le cryptokey routing<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Si un seul concept m\u00e9rite d&#8217;\u00eatre ma\u00eetris\u00e9 dans WireGuard, c&#8217;est <code>AllowedIPs<\/code>. Contrairement \u00e0 ce que son nom sugg\u00e8re, il ne s&#8217;agit pas d&#8217;une simple liste de contr\u00f4le d&#8217;acc\u00e8s. C&#8217;est le pivot du \u00ab cryptokey routing \u00bb, l&#8217;id\u00e9e fondatrice de WireGuard qui associe chaque cl\u00e9 publique \u00e0 un ensemble d&#8217;adresses IP. Cette directive joue deux r\u00f4les selon le sens du trafic.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En r\u00e9ception, <code>AllowedIPs<\/code> agit comme un filtre : un paquet chiffr\u00e9 arrivant d&#8217;un pair n&#8217;est accept\u00e9 que si son adresse source figure dans les <code>AllowedIPs<\/code> d\u00e9clar\u00e9s pour ce pair. Cela emp\u00eache un client d&#8217;usurper l&#8217;adresse d&#8217;un autre. En \u00e9mission, la directive fonctionne comme une table de routage : pour envoyer un paquet vers une adresse donn\u00e9e, WireGuard cherche le pair dont les <code>AllowedIPs<\/code> contiennent cette adresse, puis chiffre le paquet avec la cl\u00e9 de ce pair. C&#8217;est pourquoi c\u00f4t\u00e9 client on \u00e9crit <code>0.0.0.0\/0<\/code> (tout passe par le serveur) et c\u00f4t\u00e9 serveur on \u00e9crit <code>10.8.0.2\/32<\/code> (seul ce client pr\u00e9cis est rout\u00e9 via ce pair).<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Cette \u00e9l\u00e9gance a une cons\u00e9quence pratique : il ne peut y avoir de chevauchement ambigu. Si deux pairs revendiquaient la m\u00eame plage en \u00e9mission, WireGuard ne saurait pas o\u00f9 router. D&#8217;o\u00f9 la r\u00e8gle d&#8217;or : c\u00f4t\u00e9 serveur, chaque client re\u00e7oit une adresse unique en <code>\/32<\/code> (ou <code>\/128<\/code> en IPv6). Si vous voulez router tout un r\u00e9seau distant \u00e0 travers un client (par exemple un site d&#8217;entreprise), vous \u00e9largissez ses <code>AllowedIPs<\/code> \u00e0 ce r\u00e9seau, et vous obtenez un VPN site \u00e0 site sans configuration suppl\u00e9mentaire. Cette m\u00eame logique de correspondance cl\u00e9-identit\u00e9 sous-tend les <a href=\"\/fr\/signatures-numeriques\/\">signatures num\u00e9riques<\/a>, o\u00f9 une cl\u00e9 publique atteste sans ambigu\u00eft\u00e9 de l&#8217;origine d&#8217;un message.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"reglages-avances-mtu-kill-switch-et-keepalive\">R\u00e9glages avanc\u00e9s : MTU, kill switch et keepalive<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Trois r\u00e9glages font la diff\u00e9rence entre un VPN qui marche et un VPN qui marche bien. Le premier est le <strong>MTU<\/strong>. WireGuard ajoute environ 60 octets d&#8217;en-t\u00eate \u00e0 chaque paquet (80 en IPv6). Si le MTU est trop \u00e9lev\u00e9, les paquets sont fragment\u00e9s ou perdus, ce qui se traduit par des connexions qui \u00ab bloquent \u00bb sur certains sites alors que le ping fonctionne. La valeur 1420 convient \u00e0 la plupart des liaisons Internet ; sur des r\u00e9seaux \u00e0 MTU r\u00e9duit (certaines connexions PPPoE, r\u00e9seaux mobiles), descendez \u00e0 1380 voire 1280.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Forcer un MTU dans la section [Interface] du client\n[Interface]\nMTU = 1380\n\n# Diagnostiquer le bon MTU avec ping (option -M do, paquets non fragmentables)\nping -M do -s 1372 -c 2 1.1.1.1<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Le deuxi\u00e8me r\u00e9glage est <code>PersistentKeepalive<\/code>. Quand un client est derri\u00e8re un routeur NAT (cas de tout r\u00e9seau domestique), la table de traduction du routeur oublie le tunnel apr\u00e8s quelques dizaines de secondes d&#8217;inactivit\u00e9, et le serveur ne peut plus joindre le client. En envoyant un petit paquet chiffr\u00e9 toutes les 25 secondes, <code>PersistentKeepalive = 25<\/code> maintient le \u00ab trou \u00bb ouvert dans le NAT. R\u00e9glez-le c\u00f4t\u00e9 client pour les configurations road warrior ; il est inutile c\u00f4t\u00e9 serveur, qui a une IP publique fixe.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Le troisi\u00e8me est le <strong>kill switch<\/strong>, qui coupe tout trafic si le tunnel tombe, \u00e9vitant que votre IP r\u00e9elle ne fuie pendant une micro-coupure. <code>wg-quick<\/code> peut l&#8217;impl\u00e9menter via des r\u00e8gles de pare-feu dans <code>PostUp<\/code>\/<code>PreDown<\/code>, ou plus simplement en posant <code>0.0.0.0\/0<\/code> dans <code>AllowedIPs<\/code> avec la table de routage automatique, qui installe une r\u00e8gle <code>suppress_prefixlength<\/code>. Sur les applications de bureau Windows et macOS, une case \u00ab Block untunneled traffic (kill-switch) \u00bb active cette protection en un clic d\u00e8s que <code>AllowedIPs<\/code> couvre tout le trafic.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"5-pieges-courants-a-eviter\">5 pi\u00e8ges courants \u00e0 \u00e9viter<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ces erreurs reviennent dans la quasi-totalit\u00e9 des demandes d&#8217;aide en ligne. Les conna\u00eetre \u00e0 l&#8217;avance vous \u00e9pargnera des heures de frustration.<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>Oublier d&#8217;activer le forwarding IP.<\/strong> Sans <code>net.ipv4.ip_forward=1<\/code> (\u00e9tape 4), le handshake r\u00e9ussit, le ping vers 10.8.0.1 fonctionne, mais aucun trafic Internet ne passe. Sympt\u00f4me typique d&#8217;un d\u00e9butant qui croit le tunnel cass\u00e9 alors qu&#8217;il manque une seule ligne sysctl.<\/li><li><strong>Mauvais nom d&#8217;interface dans la r\u00e8gle MASQUERADE.<\/strong> Copier-coller <code>eth0<\/code> alors que votre interface s&#8217;appelle <code>ens3<\/code> rend le NAT silencieusement inop\u00e9rant. V\u00e9rifiez toujours avec <code>ip route list default<\/code>.<\/li><li><strong>Confondre cl\u00e9 priv\u00e9e et cl\u00e9 publique.<\/strong> Mettre la cl\u00e9 publique du serveur dans le champ <code>PrivateKey<\/code> du serveur (ou inversement) emp\u00eache tout handshake. Les cl\u00e9s se ressemblent, soyez m\u00e9ticuleux.<\/li><li><strong>AllowedIPs trop large c\u00f4t\u00e9 serveur.<\/strong> Mettre <code>0.0.0.0\/0<\/code> dans le bloc <code>[Peer]<\/code> du serveur fait croire au serveur que tout l&#8217;Internet passe par ce client, ce qui casse le routage des autres pairs. C\u00f4t\u00e9 serveur, restez en <code>\/32<\/code>.<\/li><li><strong>Ne pas recharger apr\u00e8s modification.<\/strong> \u00c9diter <code>wg0.conf<\/code> sans lancer <code>wg syncconf<\/code> ou red\u00e9marrer le service : vos changements restent lettre morte. C&#8217;est la cause num\u00e9ro un des \u00ab j&#8217;ai ajout\u00e9 le client mais il ne se connecte pas \u00bb.<\/li><\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"depannage-8-problemes-frequents-et-leurs-solutions\">D\u00e9pannage : 8 probl\u00e8mes fr\u00e9quents et leurs solutions<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Quand quelque chose ne fonctionne pas, proc\u00e9dez du bas vers le haut : d&#8217;abord le handshake, puis le ping interne, puis le trafic Internet, enfin le DNS. Le tableau ci-dessous couvre les pannes les plus r\u00e9pandues avec une cause probable et une action corrective imm\u00e9diate.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Sympt\u00f4me<\/th><th>Cause probable<\/th><th>Solution<\/th><\/tr><\/thead><tbody><tr><td>Aucun \u00ab latest handshake \u00bb<\/td><td>Port UDP 51820 bloqu\u00e9<\/td><td>Ouvrir 51820\/udp sur le pare-feu serveur et chez l&#8217;h\u00e9bergeur<\/td><\/tr><tr><td>Handshake puis silence<\/td><td>Forwarding IP d\u00e9sactiv\u00e9<\/td><td>V\u00e9rifier <code>sysctl net.ipv4.ip_forward<\/code> (doit valoir 1)<\/td><\/tr><tr><td>Ping 10.8.0.1 OK, pas d&#8217;Internet<\/td><td>R\u00e8gle MASQUERADE absente ou mauvaise interface<\/td><td>Corriger le nom d&#8217;interface dans PostUp, recharger<\/td><\/tr><tr><td>Connexion qui \u00ab bloque \u00bb<\/td><td>MTU trop \u00e9lev\u00e9<\/td><td>Passer MTU \u00e0 1380 ou 1280 c\u00f4t\u00e9 client<\/td><\/tr><tr><td>Fuite DNS d\u00e9tect\u00e9e<\/td><td>resolv.conf non r\u00e9\u00e9crit<\/td><td>Installer <code>openresolv<\/code>, v\u00e9rifier la directive DNS<\/td><\/tr><tr><td>D\u00e9connexions sur mobile<\/td><td>NAT qui expire<\/td><td>Ajouter <code>PersistentKeepalive = 25<\/code> c\u00f4t\u00e9 client<\/td><\/tr><tr><td>\u00ab Address already in use \u00bb<\/td><td>Tunnel d\u00e9j\u00e0 mont\u00e9<\/td><td><code>wg-quick down wg0<\/code> avant de relancer<\/td><\/tr><tr><td>Handshake intermittent<\/td><td>Endpoint ou IP dynamique change<\/td><td>Utiliser un nom DNS dynamique pour l&#8217;endpoint<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Pour diagnostiquer plus finement, deux outils sont vos alli\u00e9s. Le premier est <code>sudo wg show<\/code>, qui r\u00e9v\u00e8le l&#8217;heure du dernier handshake et les octets transf\u00e9r\u00e9s par pair. Le second est <code>tcpdump<\/code> sur le port WireGuard, qui confirme si les paquets atteignent m\u00eame le serveur.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Voir si des paquets WireGuard arrivent sur le serveur\nsudo tcpdump -n -i eth0 udp port 51820\n# 14:31:02.118 IP 198.51.100.7.51820 &gt; 203.0.113.42.51820: UDP, length 148\n\n# Suivre les journaux du noyau pour les erreurs WireGuard\nsudo dmesg | grep -i wireguard<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Si <code>tcpdump<\/code> ne montre aucun paquet entrant alors que le client tente de se connecter, le probl\u00e8me est en amont du serveur : pare-feu de l&#8217;h\u00e9bergeur, NAT du fournisseur, ou endpoint erron\u00e9. Si les paquets arrivent mais qu&#8217;aucun handshake ne se forme, suspectez une cl\u00e9 incorrecte ou une cl\u00e9 pr\u00e9-partag\u00e9e pr\u00e9sente d&#8217;un seul c\u00f4t\u00e9.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"conseils-dexperts-et-bonnes-pratiques-de-securite\">Conseils d&#8217;experts et bonnes pratiques de s\u00e9curit\u00e9<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Un VPN auto-h\u00e9berg\u00e9 concentre \u00e9norm\u00e9ment de confiance : il voit passer tout votre trafic. Jason Donenfeld, le cr\u00e9ateur de WireGuard, a con\u00e7u le protocole autour d&#8217;un principe affich\u00e9 sur le site du projet, \u00eatre aussi simple \u00e0 configurer et d\u00e9ployer qu&#8217;SSH. Cette simplicit\u00e9 ne dispense pas de rigueur. Quelques pratiques \u00e9l\u00e8vent nettement votre niveau de s\u00e9curit\u00e9.<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>Activez les cl\u00e9s pr\u00e9-partag\u00e9es (PresharedKey)<\/strong> entre chaque paire de pairs. G\u00e9n\u00e9r\u00e9es avec <code>wg genpsk<\/code>, elles ajoutent une couche de chiffrement sym\u00e9trique qui prot\u00e8ge pr\u00e9ventivement contre un futur ordinateur quantique capable de casser Curve25519. C&#8217;est gratuit et recommand\u00e9 par le projet pour les d\u00e9ploiements sensibles.<\/li><li><strong>Faites tourner vos cl\u00e9s.<\/strong> Si un appareil est perdu ou vol\u00e9, retirez imm\u00e9diatement son bloc <code>[Peer]<\/code> du serveur et rechargez. Comme chaque appareil a sa propre cl\u00e9, r\u00e9voquer un client n&#8217;affecte pas les autres.<\/li><li><strong>Limitez la surface d&#8217;attaque du serveur.<\/strong> N&#8217;exposez que le port 22 (SSH, id\u00e9alement par cl\u00e9) et 51820 (WireGuard). Fermez tout le reste. Activez les mises \u00e0 jour de s\u00e9curit\u00e9 automatiques avec <code>unattended-upgrades<\/code>.<\/li><li><strong>Surveillez les connexions.<\/strong> Un simple script qui consigne la sortie de <code>wg show<\/code> dans un journal vous alerte sur les handshakes inattendus.<\/li><li><strong>Sauvegardez vos configurations<\/strong> hors du serveur, dans un gestionnaire de secrets chiffr\u00e9. Perdre <code>wg0.conf<\/code> signifie reconfigurer tous vos clients.<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Enfin, posez-vous la question du mod\u00e8le de menace. Un VPN auto-h\u00e9berg\u00e9 sur un VPS commercial cache votre trafic \u00e0 votre fournisseur d&#8217;acc\u00e8s et aux r\u00e9seaux publics, mais votre h\u00e9bergeur, lui, voit votre IP de sortie. Pour l&#8217;anonymat fort, des fournisseurs sans journaux audit\u00e9s comme Mullvad ou l&#8217;usage de Tor r\u00e9pondent \u00e0 des besoins diff\u00e9rents. WireGuard auto-h\u00e9berg\u00e9 excelle pour la confidentialit\u00e9 du transport et l&#8217;acc\u00e8s distant s\u00e9curis\u00e9, pas pour l&#8217;anonymat absolu. Choisissez l&#8217;outil adapt\u00e9 \u00e0 votre objectif r\u00e9el.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"foire-aux-questions-sur-wireguard\">Foire aux questions sur WireGuard<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"wireguard-est-il-vraiment-plus-rapide-quopenvpn\">WireGuard est-il vraiment plus rapide qu&#8217;OpenVPN ?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Oui, dans la quasi-totalit\u00e9 des tests publi\u00e9s. Parce qu&#8217;il s&#8217;ex\u00e9cute dans le noyau et utilise ChaCha20-Poly1305, WireGuard \u00e9vite les co\u00fbteux changements de contexte d&#8217;OpenVPN. Les tests Protectli montrent 2,18 \u00e0 4,15 Gbit\/s pour WireGuard contre 0,82 \u00e0 1,09 Gbit\/s pour OpenVPN sur le m\u00eame mat\u00e9riel. L&#8217;\u00e9cart se creuse sur les processeurs sans acc\u00e9l\u00e9ration AES mat\u00e9rielle, car ChaCha20 reste rapide en logiciel pur.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"wireguard-protege-t-il-mon-anonymat\">WireGuard prot\u00e8ge-t-il mon anonymat ?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">WireGuard chiffre votre trafic et masque votre IP r\u00e9elle aux yeux des sites visit\u00e9s et de votre fournisseur d&#8217;acc\u00e8s. Mais il n&#8217;anonymise pas : votre h\u00e9bergeur VPS voit l&#8217;IP de sortie, et WireGuard conserve par d\u00e9faut la derni\u00e8re adresse IP de chaque pair en m\u00e9moire, ce qui a soulev\u00e9 des d\u00e9bats sur la vie priv\u00e9e. Pour de l&#8217;anonymat fort, Tor ou un fournisseur sans journaux audit\u00e9 r\u00e9pondent mieux au besoin.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"puis-je-utiliser-wireguard-sur-plusieurs-appareils-a-la-fois\">Puis-je utiliser WireGuard sur plusieurs appareils \u00e0 la fois ?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Oui, sans limite pratique. Chaque appareil re\u00e7oit sa propre paire de cl\u00e9s et sa propre adresse dans le tunnel (10.8.0.2, 10.8.0.3, etc.), puis un bloc <code>[Peer]<\/code> d\u00e9di\u00e9 sur le serveur. Ne r\u00e9utilisez jamais la m\u00eame cl\u00e9 pour deux appareils, sous peine d&#8217;instabilit\u00e9. Un VPS modeste g\u00e8re sans peine des dizaines de clients simultan\u00e9s.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"wireguard-est-il-resistant-a-linformatique-quantique\">WireGuard est-il r\u00e9sistant \u00e0 l&#8217;informatique quantique ?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Pas nativement : Curve25519 serait cassable par un ordinateur quantique suffisamment puissant, qui n&#8217;existe pas encore. WireGuard pr\u00e9voit toutefois la directive <code>PresharedKey<\/code>, une cl\u00e9 sym\u00e9trique partag\u00e9e qui rend le tunnel r\u00e9sistant aux attaques quantiques tant qu&#8217;elle reste secr\u00e8te. Pour les d\u00e9ploiements sensibles en 2026, activez-la syst\u00e9matiquement.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"quel-port-et-quel-protocole-wireguard-utilise-t-il\">Quel port et quel protocole WireGuard utilise-t-il ?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">WireGuard utilise exclusivement UDP, sur le port 51820 par d\u00e9faut, que vous pouvez changer via <code>ListenPort<\/code>. Il n&#8217;existe aucun mode TCP, ce qui maximise les performances mais peut poser probl\u00e8me sur les r\u00e9seaux bloquant l&#8217;UDP. Dans ce cas, encapsulez WireGuard dans un tunnel TCP avec des outils comme <code>udp2raw<\/code> ou <code>wstunnel<\/code>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"comment-supprimer-proprement-un-client\">Comment supprimer proprement un client ?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Retirez le bloc <code>[Peer]<\/code> correspondant dans <code>\/etc\/wireguard\/wg0.conf<\/code> sur le serveur, puis rechargez avec <code>sudo wg syncconf wg0 &lt;(wg-quick strip wg0)<\/code>. Le client est imm\u00e9diatement r\u00e9voqu\u00e9 et ne peut plus \u00e9tablir de handshake. Comme chaque appareil poss\u00e8de une cl\u00e9 distincte, cette r\u00e9vocation n&#8217;affecte aucun autre client.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"wireguard-fonctionne-t-il-derriere-un-routeur-domestique-en-nat\">WireGuard fonctionne-t-il derri\u00e8re un routeur domestique en NAT ?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">C\u00f4t\u00e9 client, oui, sans configuration sp\u00e9ciale : ajoutez simplement <code>PersistentKeepalive = 25<\/code> pour maintenir le NAT ouvert. C\u00f4t\u00e9 serveur, il faut une IP publique joignable, ou une redirection du port 51820\/UDP sur votre routeur si vous h\u00e9bergez chez vous. Un serveur derri\u00e8re un NAT sans redirection ne recevra aucune connexion entrante.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"combien-coute-un-vpn-wireguard-auto-heberge\">Combien co\u00fbte un VPN WireGuard auto-h\u00e9berg\u00e9 ?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Le seul co\u00fbt est celui du serveur. Un VPS \u00e0 1 vCPU et 1 Go de RAM, suffisant pour saturer une connexion fibre domestique, se loue de 4 \u00e0 6 \u20ac par mois chez les h\u00e9bergeurs europ\u00e9ens. WireGuard lui-m\u00eame est gratuit et open source sous licence GPLv2. C&#8217;est nettement moins cher qu&#8217;un abonnement VPN commercial sur le long terme, avec un contr\u00f4le total sur vos donn\u00e9es.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"pour-aller-plus-loin\">Pour aller plus loin<\/h3>\n\n\n\n<ul class=\"wp-block-list\"><li><a href=\"\/fr\/https-et-tls\/\">HTTPS et TLS : comment votre connexion est prot\u00e9g\u00e9e<\/a><\/li><li><a href=\"\/fr\/proton-mail-vs-tuta\/\">Proton Mail vs Tuta : 3 \u20ac vs 4,99 \u20ac\/mois [2026]<\/a><\/li><li><a href=\"\/fr\/signal-vs-whatsapp-vs-telegram\/\">Signal vs WhatsApp vs Telegram : 3 Md vs 70 M [2026]<\/a><\/li><li><a href=\"\/fr\/securite-des-mots-de-passe\/\">S\u00e9curit\u00e9 des mots de passe : longueur, hachage et gestionnaires<\/a><\/li><li><a href=\"\/fr\/certificat-ssl-certbot-nginx\/\">Certificat SSL gratuit avec Certbot : 11 \u00e9tapes [2026]<\/a><\/li><li><a href=\"\/fr\/fuites-de-donnees\/\">Fuites de donn\u00e9es : comment elles surviennent et s&#8217;en prot\u00e9ger<\/a><\/li><li><a href=\"\/fr\/security-hub\/\">S\u00e9curit\u00e9 en ligne : le guide complet<\/a><\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Sources et r\u00e9f\u00e9rences externes :<\/strong> <a href=\"https:\/\/www.wireguard.com\/\" target=\"_blank\" rel=\"noopener\">WireGuard.com (projet officiel)<\/a>, <a href=\"https:\/\/www.wireguard.com\/papers\/wireguard.pdf\" target=\"_blank\" rel=\"noopener\">livre blanc technique de WireGuard (PDF)<\/a>, <a href=\"https:\/\/www.wireguard.com\/quickstart\/\" target=\"_blank\" rel=\"noopener\">guide de d\u00e9marrage rapide officiel<\/a>, <a href=\"https:\/\/man7.org\/linux\/man-pages\/man8\/wg-quick.8.html\" target=\"_blank\" rel=\"noopener\">manuel wg-quick(8)<\/a>, <a href=\"https:\/\/mullvad.net\/en\/help\/why-wireguard\" target=\"_blank\" rel=\"noopener\">Mullvad : pourquoi WireGuard<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Un VPN auto-h\u00e9berg\u00e9 avec WireGuard chiffre tout votre trafic, contourne la censure r\u00e9seau et vous rend votre vie priv\u00e9e pour le prix d&#8217;un petit serveur, environ 5 \u20ac par mois.\u2026<\/p>\n","protected":false},"author":3,"featured_media":67,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10,4],"tags":[],"class_list":["post-66","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-10","category-privacy"],"_links":{"self":[{"href":"https:\/\/shattered.io\/fr\/wp-json\/wp\/v2\/posts\/66","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/shattered.io\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/shattered.io\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/shattered.io\/fr\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/shattered.io\/fr\/wp-json\/wp\/v2\/comments?post=66"}],"version-history":[{"count":1,"href":"https:\/\/shattered.io\/fr\/wp-json\/wp\/v2\/posts\/66\/revisions"}],"predecessor-version":[{"id":68,"href":"https:\/\/shattered.io\/fr\/wp-json\/wp\/v2\/posts\/66\/revisions\/68"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/shattered.io\/fr\/wp-json\/wp\/v2\/media\/67"}],"wp:attachment":[{"href":"https:\/\/shattered.io\/fr\/wp-json\/wp\/v2\/media?parent=66"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/shattered.io\/fr\/wp-json\/wp\/v2\/categories?post=66"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/shattered.io\/fr\/wp-json\/wp\/v2\/tags?post=66"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}