Configuration de WireGuard sous Windows

Ce guide explique comment configurer un tunnel VPN WireGuard entre deux machines Windows : un serveur WireGuard s'exécutant sur un hôte Windows distant, par exemple un VPS Windows, et un client WireGuard s'exécutant sur votre ordinateur Windows local. Une fois le tunnel actif, les deux machines échangent des données via une connexion privée chiffrée, et vous pouvez éventuellement acheminer tout le trafic du client par le serveur.

La configuration de base crée un tunnel entre le serveur et le client. Pour acheminer tout le trafic Internet du client par le serveur, il faut également activer le NAT sur le serveur ; voir « Configuration du NAT sur le serveur pour le tunnel complet ».

Pour simplifier la génération des clés, ce guide crée les configurations du serveur et du client dans une seule application WireGuard, puis déploie chaque fichier de configuration sur la machine à laquelle il appartient. La configuration du serveur s'exécute sur le serveur et celle du client sur le client. Le serveur et le client sont toujours des machines distinctes. La même procédure sert à ajouter autant de clients supplémentaires que nécessaire.

Avant de commencer, installez la dernière version de WireGuard depuis la page d'installation de WireGuard sur le serveur et sur le client, et assurez-vous de disposer des droits d'administrateur sur chaque machine.

La configuration de ce guide se présente ainsi :

Serveur (IP publique, écoute sur UDP 51820)
Adresse du tunnel 10.0.0.1/24
        |
        |  tunnel WireGuard chiffré
        |
Client
Adresse du tunnel 10.0.0.2/32

Création de la configuration du serveur

Exécutez C:\Program Files\WireGuard\wireguard.exe, cliquez sur Add tunnel et choisissez Add empty tunnel. WireGuard génère automatiquement une paire de clés. La clé publique affichée en haut de la fenêtre est la clé publique du serveur. Vous en aurez besoin plus tard pour configurer le client.

Donnez un nom au tunnel et renseignez la section Interface avec la clé privée du serveur, le port sur lequel WireGuard écoutera et l'adresse interne que le serveur utilisera à l'intérieur du tunnel.

[Interface]
PrivateKey = # clé privée du serveur WireGuard
ListenPort = # port sur lequel WireGuard écoutera
Address = # adresse IP interne du serveur WireGuard, par exemple 10.0.0.1/24

Utilisez un sous-réseau privé pour le réseau du tunnel et conservez le serveur et tous les clients dans la même plage. Un choix courant est 10.0.0.1/24 pour le serveur et 10.0.0.2/32, 10.0.0.3/32, etc., pour chaque client. Le serveur utilise le préfixe /24 afin de considérer toute la plage du tunnel comme joignable via l'interface WireGuard. Chaque client utilise /32, car un client représente une adresse unique et non un sous-réseau. Un client configuré en /24 supposerait que toute la plage se trouve sur sa propre interface et n'enverrait pas dans le tunnel le trafic destiné aux autres adresses du tunnel.

La configuration du serveur n'affiche pas la case Block untunneled traffic (kill-switch). Cette option n'apparaît que dans une configuration client qui achemine tout le trafic par le tunnel ; voir « Création de la configuration du client ».

Pour ajouter une couche de sécurité supplémentaire, vous pouvez associer une clé pré-partagée à chaque pair (peer). Générez-la une seule fois et ajoutez la même ligne à la section [Peer] correspondante, sur le serveur comme sur le client :

PresharedKey = # clé pré-partagée, identique sur le serveur et sur le client

Vous pouvez générer la clé avec l'outil wg fourni avec WireGuard :

"C:\Program Files\WireGuard\wg.exe" genpsk

Création de la configuration du client

Cliquez sur Add tunnel et choisissez Add empty tunnel une seconde fois, cette fois pour le client. La clé publique affichée pour ce tunnel est la clé publique du client, dont le serveur a besoin pour accepter le client.

Renseignez la configuration du client :

[Interface]
PrivateKey = # clé privée du client WireGuard
Address = # adresse IP interne du client WireGuard, par exemple 10.0.0.2/32
DNS = 1.1.1.1, 1.0.0.1
[Peer]
PublicKey = # clé publique du serveur WireGuard
AllowedIPs = # 0.0.0.0/0 pour un tunnel complet, ou 10.0.0.0/24 pour un tunnel fractionné (split tunnel)
Endpoint = # adresse IP publique et port du serveur WireGuard
PersistentKeepalive = 25

La valeur Endpoint doit être l'adresse IP publique réelle du serveur, accompagnée du port défini dans ListenPort côté serveur, et non l'adresse interne du tunnel. Pour vous aider à choisir la valeur de AllowedIPs, consultez la section « Comprendre AllowedIPs » ci-dessous.

Les lignes DNS et PersistentKeepalive sont facultatives. DNS définit les serveurs DNS utilisés lorsque le tunnel est actif, ce qui permet d'éviter les problèmes de résolution de noms après la connexion. Vous pouvez utiliser des résolveurs publics tels que 1.1.1.1, 1.0.0.1 ou 8.8.8.8, 8.8.4.4, ou le serveur DNS du réseau VPN lui-même. PersistentKeepalive = 25 envoie un petit paquet toutes les 25 secondes et aide à maintenir la connexion ouverte lorsque le client se trouve derrière un NAT.

Lorsque la configuration du client comporte un seul [Peer] et que son AllowedIPs contient 0.0.0.0/0 (ou ::/0), l'éditeur de tunnel affiche la case Block untunneled traffic (kill-switch) sous le champ de configuration. Avec un tunnel fractionné, par exemple AllowedIPs = 10.0.0.0/24, la case n'apparaît pas du tout.

Le kill-switch est activé par défaut dès que vous saisissez 0.0.0.0/0. Tant que le tunnel est actif, les règles du pare-feu n'autorisent que le trafic passant par le tunnel, le trafic de bouclage (loopback), le DHCP et la découverte de voisins IPv6. Tout le reste est bloqué, y compris les appareils de votre réseau local tels que les imprimantes et les NAS. Si la ligne DNS est définie, les requêtes DNS ne sont autorisées que vers les serveurs qui y figurent.

Décocher la case ne se contente pas de désactiver un paramètre. L'éditeur réécrit AllowedIPs : 0.0.0.0/0 devient 0.0.0.0/1, 128.0.0.0/1, et ::/0 devient ::/1, 8000::/1. Tout le trafic Internet continue de passer par le tunnel, mais les règles de pare-feu de blocage ne sont pas créées. Cocher de nouveau la case rétablit 0.0.0.0/0.

Copiez les clés et l'Endpoint avec le plus grand soin. Une clé mal saisie ou un Endpoint erroné est la cause la plus fréquente d'échec de connexion d'un tunnel.

Ajout du client au serveur

Rouvrez la configuration du serveur et ajoutez une section [Peer] pour le client, en utilisant la clé publique du client obtenue à l'étape précédente.

[Peer]
PublicKey = # clé publique du client WireGuard
AllowedIPs = # adresse IP interne du client

Dans la configuration du serveur, AllowedIPs joue deux rôles. Il indique au serveur quelle adresse de tunnel appartient à ce client, et il sert de liste de routage : tout paquet adressé à ces plages est chiffré et envoyé à ce pair. Pour un client unique, il s'agit de son adresse de tunnel, par exemple 10.0.0.2/32. Si le client doit aussi rendre un réseau local accessible via le tunnel, ajoutez également ce sous-réseau ici, par exemple 10.0.0.2/32, 192.168.1.0/24. Répétez cette étape pour chaque client supplémentaire.

Configuration du Pare-feu Windows sur le serveur

Le serveur doit accepter le trafic WireGuard entrant sur son port UDP. Ouvrez le Pare-feu Windows Defender avec fonctions avancées de sécurité, sélectionnez Règles de trafic entrant et cliquez sur Nouvelle règle. Choisissez Port et cliquez sur Suivant. Sélectionnez UDP, saisissez le port WireGuard, par exemple 51820, et cliquez sur Suivant. Si vous utilisez plusieurs ports, séparez-les par des virgules, par exemple 51820, 51821. Sélectionnez Autoriser la connexion et cliquez sur Suivant. Sélectionnez les profils auxquels la règle s'applique. Si le serveur est hébergé dans un centre de données, le profil Public suffit généralement ; sinon, laissez les profils Domaine, Privé et Public sélectionnés. Cliquez sur Suivant, donnez à la règle un nom explicite tel que WireGuard UDP 51820, puis cliquez sur Terminer.

Cette règle de trafic entrant n'est nécessaire que sur le serveur, car c'est lui qui reçoit les connexions entrantes. Sur un VPS, vérifiez également que votre hébergeur autorise le trafic UDP entrant sur ce port au niveau du réseau, et pas seulement dans le Pare-feu Windows.

Exportation et déploiement des configurations

Lorsque les deux configurations sont prêtes, cliquez sur Export all tunnels to zip, choisissez un emplacement et enregistrez.

Ouvrez l'archive pour y trouver les fichiers de configuration de tous les tunnels. Placez la configuration du serveur sur le serveur et remettez à chaque client son propre fichier de configuration. Si la machine contient de nombreux tunnels, vous pouvez aussi exporter un seul tunnel depuis son menu contextuel. L'exportation vers un fichier zip est pratique lorsque les deux tunnels ont été créés sur la même machine, comme dans ce guide. Si vous créez chaque configuration directement sur son propre hôte, l'exportation n'est pas nécessaire et vous pouvez copier le fichier de configuration manuellement.

Sur le serveur, sélectionnez la configuration du serveur et cliquez sur Activate.

Sur le client, cliquez sur Add Tunnel, sélectionnez le fichier de configuration du client et ouvrez-le.

Cliquez ensuite sur Activate.

Le premier client est maintenant configuré. Ajoutez d'autres clients de la même manière : créez un nouveau tunnel vide pour chaque client et ajoutez à la configuration du serveur une section [Peer] correspondante, avec la clé publique et l'adresse de tunnel de ce client, comme décrit dans « Ajout du client au serveur ».

Vérification de la connexion

Après l'activation du tunnel, Windows peut afficher l'adaptateur WireGuard comme « Pas d'accès réseau » ou « Pas d'accès Internet » dans le Centre Réseau et partage. C'est un comportement attendu, car Windows ne traite pas les adaptateurs de tunnel VPN comme des connexions Internet standard, et cela n'affecte pas le tunnel. Windows détermine cet état à l'aide de son test de connectivité, qui interroge des URL Microsoft spécifiques ; l'avertissement peut donc aussi apparaître si ces requêtes sont bloquées ou non résolues par votre DNS, même lorsque le tunnel fonctionne.

Pour confirmer que le tunnel fonctionne, vérifiez son état dans le client WireGuard. Un tunnel actif affiche l'état Active ainsi que des compteurs de transfert de données. Si les compteurs augmentent, le tunnel fait passer du trafic.

Sur le serveur, vous pouvez aussi vérifier que WireGuard écoute sur son port UDP lorsque le tunnel est actif :

netstat -ano | findstr 51820

Dans PowerShell, l'équivalent est :

Get-NetUDPEndpoint -LocalPort 51820

Remplacez 51820 par votre port WireGuard. Si rien n'est renvoyé, le tunnel n'est pas actif ou le port diffère de celui défini dans la configuration du serveur.

Ensuite, ouvrez l'invite de commandes et envoyez un ping à l'adresse interne du tunnel du serveur :

ping 10.0.0.1

Remplacez 10.0.0.1 par l'adresse IP interne réelle que vous avez définie pour le serveur. Si le serveur répond, le trafic passe par le tunnel. En l'absence de réponse, vérifiez d'abord le handshake : le Pare-feu Windows de Windows Server bloque le ping entrant par défaut, donc l'absence de réponse ne signifie pas toujours que le tunnel est hors service.

Si le client utilise AllowedIPs = 0.0.0.0/0, vous pouvez également confirmer que le trafic est acheminé par le tunnel :

tracert 8.8.8.8

Le premier saut doit être l'adresse IP interne du serveur WireGuard.

Vérification du handshake WireGuard

Le handshake est l'indicateur le plus utile pour diagnostiquer une connexion WireGuard. Dans l'application WireGuard, ouvrez le tunnel et surveillez le champ Latest handshake. Sur un tunnel qui fonctionne, le handshake apparaît quelques secondes après l'activation, puis se met à jour périodiquement pendant le transfert de données. Si le tunnel est inactif, un certain temps peut s'écouler entre deux handshakes ; un court intervalle est donc normal. Si le champ reste vide, les pairs ne parviennent pas à se joindre, ce qui indique généralement un Endpoint incorrect, un port UDP fermé ou des clés qui ne correspondent pas.

Vous pouvez aussi vérifier le handshake en ligne de commande avec l'outil wg fourni avec WireGuard :

wg show

La sortie répertorie chaque pair avec l'heure de son dernier handshake et ses compteurs de transfert.

Comprendre AllowedIPs

La valeur AllowedIPs de la configuration du client détermine quel trafic est envoyé par le tunnel. En bref, sur le client, AllowedIPs définit quels paquets sont envoyés dans le tunnel, tandis que sur le serveur, il définit quels paquets sont acceptés de la part d'un client donné et où ils sont routés.

Une valeur de 0.0.0.0/0 achemine tout le trafic par le tunnel, y compris la navigation Internet ordinaire. Utilisez-la si vous souhaitez une protection complète du trafic. Pour que ce trafic atteigne Internet, le serveur doit le traduire. Voir « Configuration du NAT sur le serveur pour le tunnel complet » ci-dessous.

Une valeur telle que 10.0.0.0/24 n'achemine par le tunnel que le trafic du réseau interne, tandis que le trafic Internet ordinaire continue d'utiliser la connexion normale. Utilisez-la lorsque vous n'avez besoin d'accéder qu'à des ressources précises du réseau distant.

Vous pouvez indiquer plusieurs sous-réseaux séparés par des virgules, par exemple 10.0.0.0/24, 192.168.1.0/24.

Accès au réseau local lorsque le tunnel est actif

Avec un tunnel fractionné, par exemple AllowedIPs = 10.0.0.0/24, le réseau local continue de fonctionner normalement et rien n'a besoin d'être modifié. Les étapes ci-dessous s'appliquent à un tunnel complet.

L'option la plus simple consiste à décocher la case Block untunneled traffic (kill-switch) dans l'éditeur de tunnel du client. L'éditeur remplace 0.0.0.0/0 par 0.0.0.0/1, 128.0.0.0/1. Votre sous-réseau local, par exemple 192.168.1.0/24, dispose d'une route plus spécifique via l'adaptateur physique ; Windows envoie donc le trafic du réseau local directement vers le réseau local, tandis que le trafic Internet passe toujours par le tunnel. Le compromis est que rien ne bloque le trafic si le tunnel tombe.

Si vous voulez être certain que le trafic du réseau local n'entre jamais dans le tunnel, excluez explicitement la plage locale de AllowedIPs. Par exemple, la valeur suivante couvre toutes les adresses IPv4 sauf 192.168.0.0/16 :

AllowedIPs = 0.0.0.0/1, 128.0.0.0/2, 192.0.0.0/9, 192.128.0.0/11, 192.160.0.0/13, 192.169.0.0/16, 192.170.0.0/15, 192.172.0.0/14, 192.176.0.0/12, 192.192.0.0/10, 193.0.0.0/8, 194.0.0.0/7, 196.0.0.0/6, 200.0.0.0/5, 208.0.0.0/4, 224.0.0.0/3

Si votre réseau local utilise une plage différente, telle que 10.x.x.x ou 172.16.x.x, calculez la liste pour cette plage à l'aide d'un calculateur AllowedIPs, et assurez-vous que le sous-réseau du tunnel y figure toujours. Cette valeur ne contenant pas de route /0, le kill-switch n'est pas disponible avec elle.

Info Évitez d'utiliser le même sous-réseau pour le tunnel et pour le réseau local. Si votre réseau domestique est 10.0.0.0/24, choisissez une autre plage pour le tunnel, par exemple 10.8.0.0/24.

Pour accéder à un réseau situé derrière le serveur, par exemple un réseau local de bureau 192.168.10.0/24, le serveur n'a besoin d'aucune entrée supplémentaire, car il possède déjà une route vers son propre réseau local. Sur le client, ajoutez-le à AllowedIPs dans la section [Peer], par exemple AllowedIPs = 10.0.0.0/24, 192.168.10.0/24. Le serveur doit également transférer et traduire ce trafic ; voir « Configuration du NAT sur le serveur pour le tunnel complet ». Les appareils de ce réseau répondent à l'adresse LAN du serveur ; le NAT sur le serveur est donc le moyen le plus simple de faire revenir les réponses par le tunnel.

Configuration du NAT sur le serveur pour le tunnel complet

Si les clients utilisent AllowedIPs = 0.0.0.0/0 et que vous souhaitez que leur trafic atteigne réellement Internet via le serveur, ce dernier doit traduire les adresses WireGuard internes en sa propre adresse externe. Sous Windows, cela se fait avec la commande New-NetNat, et non avec les scripts PostUp et PostDown utilisés sous Linux.

Ouvrez PowerShell en tant qu'administrateur sur le serveur et exécutez la commande suivante, en utilisant le sous-réseau de tunnel attribué au serveur :

New-NetNat -Name WireGuardNAT -InternalIPInterfaceAddressPrefix 10.0.0.0/24

Remplacez 10.0.0.0/24 par le sous-réseau de votre tunnel et assurez-vous que le préfixe couvre toutes les adresses de clients que vous attribuez. Un client situé en dehors de cette plage, par exemple 10.0.1.2, ne correspondrait pas à cette règle. Vous pouvez consulter les règles actives à tout moment :

Get-NetNat

Pour supprimer ultérieurement la règle NAT, exécutez :

Remove-NetNat -Name WireGuardNAT

Si les clients se connectent et que le handshake réussit, mais que leur trafic Internet ne passe toujours pas par le serveur, activez le transfert IP (IP forwarding) sur les interfaces impliquées dans le routage et testez à nouveau. La forme exacte dépend de la version de Windows, par exemple :

Set-NetIPInterface -InterfaceAlias "Ethernet" -Forwarding Enabled

Appliquez-la à l'interface externe qui transporte le trafic Internet ainsi qu'à l'interface WireGuard, en utilisant leurs noms réels obtenus avec Get-NetIPInterface.

Dépannage

Le tunnel est actif, mais il n'y a pas de connexion au serveur. Vérifiez que le port UDP de WireGuard, par exemple 51820, est ouvert dans le pare-feu du serveur. Confirmez que les clés publiques ont été copiées correctement entre les configurations du serveur et du client. Assurez-vous que l'Endpoint de la configuration du client pointe vers l'adresse IP publique réelle du serveur, et non vers l'adresse interne du tunnel.

Le DNS ne fonctionne pas après la connexion. Ajoutez un serveur DNS à la section Interface du client :

[Interface]
PrivateKey = ...
Address = ...
DNS = 1.1.1.1, 1.0.0.1

Les compteurs de paquets n'augmentent pas. Le tunnel ne fait pas passer de données. Vérifiez que AllowedIPs est correctement défini des deux côtés, que les adresses WireGuard internes n'entrent pas en conflit avec le réseau local existant et que le ListenPort n'est pas déjà utilisé par une autre application.

La case du kill-switch ne se décoche pas. L'éditeur ne réécrit AllowedIPs que s'il peut lire toute la configuration. Vérifiez que la section [Peer] contient une clé publique valide copiée depuis le serveur et que chaque paramètre se trouve sur sa propre ligne, puis réessayez.

Vous avez besoin de plus de détails pour diagnostiquer un problème. Ouvrez le tunnel dans l'application WireGuard et consultez l'onglet Log, qui enregistre en temps réel les handshakes, les erreurs et les événements de connexion. Vous pouvez en exporter le journal si vous devez le partager.

Démarrage automatique de WireGuard après un redémarrage du serveur

Pour que le tunnel reste actif après les redémarrages, installez-le en tant que service Windows. Lorsqu'un tunnel est installé comme service, il démarre automatiquement après un redémarrage. Ouvrez l'invite de commandes ou PowerShell en tant qu'administrateur et exécutez la commande suivante, en utilisant le chemin de votre fichier de configuration du serveur :

wireguard /installtunnelservice "C:\Program Files\WireGuard\wg_server.conf"

Exécutez cette commande une seule fois, et non à chaque démarrage. L'activation du tunnel depuis l'application WireGuard installe normalement le même service ; dans de nombreux cas, une seule activation suffit donc. Pour supprimer le service ultérieurement, utilisez le nom du tunnel, c'est-à-dire le nom du fichier de configuration sans l'extension .conf.

wireguard /uninstalltunnelservice wg_server

Pour redémarrer le service, par exemple après avoir modifié la configuration, exécutez la commande de désinstallation, puis de nouveau la commande d'installation.

Redémarrez le serveur et vérifiez que le tunnel démarre de lui-même.