WireGuard Windows setup
Ce guide explique comment configurer un tunnel VPN WireGuard entre deux machines Windows : un serveur WireGuard exécuté sur un hôte Windows distant, par exemple un VPS Windows, et un client WireGuard exécuté 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 à travers le serveur.
Pour simplifier la génération des clés, ce guide crée à la fois la configuration du serveur et celle du client au sein d'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. Le même processus permet d'ajouter un nombre quelconque de clients supplémentaires.
Avant de commencer, installez la dernière version de WireGuard depuis la page d'installation officielle (https://www.wireguard.com/install/) à la fois 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 :
Server (public IP, listening on UDP 51820) Tunnel address 10.0.0.1/24 | | encrypted WireGuard tunnel | Client Tunnel address 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, lors de la configuration du client.
Donnez un nom au tunnel et remplissez 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 = # private key of the WireGuard server ListenPort = # port that WireGuard will listen on Address = # internal IP address of the WireGuard server, for example 10.0.0.1/24
Utilisez un sous-réseau privé pour le réseau du tunnel et maintenez 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, et ainsi de suite pour chaque client. Le serveur utilise un préfixe /24, de sorte qu'il considère toute la plage du tunnel comme accessible via l'interface WireGuard. Chaque client utilise /32, car un client représente une seule adresse et non un sous-réseau. Un client défini sur /24 supposerait que toute la plage se trouve sur sa propre interface et n'enverrait pas dans le tunnel le trafic destiné à d'autres adresses du tunnel.
Dans l'éditeur de tunnel, sous le champ de configuration, vous pouvez éventuellement activer Block untunneled traffic (kill-switch), qui bloque tout trafic sortant en dehors du tunnel, et définir une Pre-shared key, qui ajoute une couche de sécurité supplémentaire. Les deux options sont facultatives. Consultez la section « Comprendre AllowedIPs » pour savoir quand le kill-switch est utile et ce qu'il bloque.
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.
Remplissez la configuration du client :
[Interface] PrivateKey = # private key of the WireGuard client Address = # internal IP address of the WireGuard client, for example 10.0.0.2/32 DNS = 1.1.1.1, 1.0.0.1 [Peer] PublicKey = # public key of the WireGuard server AllowedIPs = # 0.0.0.0/0 for a full tunnel, or 10.0.0.0/24 for a split tunnel Endpoint = # public IP address and port of the WireGuard server PersistentKeepalive = 25
L'Endpoint doit être l'adresse IP publique réelle du serveur, accompagnée du port défini dans le ListenPort du serveur, et non l'adresse interne du tunnel. Pour vous aider à choisir la valeur d'AllowedIPs, consultez la section « Comprendre AllowedIPs » ci-dessous.
Les lignes DNS et PersistentKeepalive sont facultatives. DNS définit les serveurs DNS utilisés tant que le tunnel est actif, ce qui évite les problèmes de résolution de noms après la connexion. Vous pouvez utiliser des résolveurs publics comme 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.
Copiez les clés et l'Endpoint avec beaucoup de soin. Une clé mal saisie ou un Endpoint incorrect est la cause la plus fréquente d'échec de connexion d'un tunnel.
Ajout du client au serveur
Ouvrez de nouveau la configuration du serveur et ajoutez une section [Peer] pour le client, en utilisant la clé publique du client de l'étape précédente.
[Peer] PublicKey = # public key of the WireGuard client AllowedIPs = # internal IP address of the client
Dans la configuration du serveur, AllowedIPs a deux rôles. Elle indique au serveur quelle adresse du tunnel appartient à ce client et agit comme une liste de routage : tout paquet adressé à ces plages est chiffré et envoyé à ce peer. Pour un seul client, il s'agit de son adresse de tunnel, par exemple 10.0.0.2/32. Si le client doit également rendre un réseau local accessible à travers le tunnel, ajoutez aussi 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 sécurité avancée, 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, indiquez-les séparés 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 clair comme WireGuard UDP 51820, puis cliquez sur Terminer.
Cette règle entrante n'est nécessaire que sur le serveur, car c'est le serveur qui reçoit les connexions entrantes. Sur un VPS, assurez-vous é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 trouver les fichiers de configuration de tous les tunnels. Placez la configuration du serveur sur le serveur et donnez à 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 à la main.
Sur le serveur, sélectionnez la configuration du serveur et cliquez sur Activer.
Sur le client, cliquez sur Add Tunnel, sélectionnez le fichier de configuration du client et ouvrez-le.
Cliquez ensuite sur Activer.
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 ».
Warning: Si vous configurez WireGuard sur un serveur distant via une session RDP, lisez la section « Comprendre AllowedIPs » avant d'activer un tunnel qui achemine tout le trafic. Une configuration avec AllowedIPs = 0.0.0.0/0 peut rediriger le propre trafic du serveur dans le tunnel et couper votre connexion RDP.
Vérification de la connexion
Après l'activation du tunnel, Windows peut afficher l'adaptateur WireGuard comme « Aucun accès réseau » ou « Aucun accès Internet » dans le Centre Réseau et partage. Il s'agit d'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 au moyen de sa vérification de connectivité, qui sonde certaines URL Microsoft ; l'avertissement peut donc aussi apparaître si ces sondages sont bloqués ou non résolus 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 Actif ainsi que des compteurs de transfert de données. Si les compteurs augmentent, le tunnel transmet du trafic.
Sur le serveur, vous pouvez également confirmer que WireGuard écoute sur son port UDP pendant que 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. Les réponses confirment que le tunnel fonctionne.
Si le client utilise AllowedIPs = 0.0.0.0/0, vous pouvez aussi confirmer que le trafic est acheminé à travers 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 lors du diagnostic d'une connexion WireGuard. Dans l'application WireGuard, ouvrez le tunnel et observez 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 les handshakes, une courte pause est donc normale. Si le champ reste vide, les peers 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 peer avec l'heure de son dernier handshake et ses compteurs de transfert.
Comprendre AllowedIPs
La valeur AllowedIPs dans la configuration du client décide quel trafic est envoyé à travers le tunnel. En bref, sur le client AllowedIPs définit quels paquets sont envoyés dans le tunnel, tandis que sur le serveur elle définit quels paquets sont acceptés d'un client donné et où ils sont routés.
AllowedIPs = 0.0.0.0/0 achemine tout le trafic à travers le tunnel, y compris la navigation Internet ordinaire. Utilisez-le lorsque vous voulez une protection totale du trafic. Pour que ce trafic atteigne Internet, le serveur doit le traduire. Consultez « Configuration du NAT sur le serveur pour le tunneling complet » ci-dessous.
AllowedIPs = 10.0.0.0/24 achemine uniquement le trafic du réseau interne à travers le tunnel, tandis que le trafic Internet ordinaire continue d'utiliser la connexion habituelle. Utilisez-le lorsque vous n'avez besoin d'atteindre que des ressources spécifiques du réseau distant.
Vous pouvez indiquer plusieurs sous-réseaux séparés par des virgules, par exemple AllowedIPs = 10.0.0.0/24, 192.168.1.0/24.
Tip: L'option Block untunneled traffic (kill-switch) de l'éditeur de tunnel produit son plein effet avec AllowedIPs = 0.0.0.0/0. Elle bloque tout ce qui circulerait en dehors du tunnel, ce qui bloque aussi le réseau local. Si vous avez besoin d'accéder à des imprimantes ou à d'autres appareils du réseau local, laissez le kill-switch désactivé.
Warning: Définir AllowedIPs = 0.0.0.0/0 envoie chaque connexion à travers le tunnel. Si vous appliquez cela sur un serveur distant que vous gérez via RDP, la session RDP peut se couper au moment où le tunnel devient actif, car le trafic du serveur est redirigé. Sur un serveur atteint via RDP, routez uniquement les sous-réseaux dont vous avez besoin et testez avec une valeur d'AllowedIPs restreinte avant de passer à 0.0.0.0/0.
Configuration du NAT sur le serveur pour le tunneling complet
Si les clients utilisent AllowedIPs = 0.0.0.0/0 et que vous voulez que leur trafic atteigne réellement Internet via le serveur, le serveur doit traduire les adresses WireGuard internes vers 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 ce qui suit, en utilisant le sous-réseau du tunnel que vous avez attribué au serveur :
New-NetNat -Name WireGuardNAT -InternalIPInterfaceAddressPrefix 10.0.0.0/24
Remplacez 10.0.0.0/24 par votre sous-réseau de tunnel et assurez-vous que le préfixe couvre chaque adresse de client que vous attribuez. Un client en dehors de cette plage, par exemple 10.0.1.2, ne serait pas pris en compte par cette règle. Vous pouvez consulter les règles actives à tout moment :
Get-NetNat
Pour supprimer la règle NAT ultérieurement, 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 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-le à l'interface externe qui transporte le trafic Internet et à l'interface WireGuard, en utilisant leurs noms réels obtenus avec Get-NetIPInterface.
Info: New-NetNat nécessite Windows 10, Windows 11 ou Windows Server 2016 et versions ultérieures, et sur certains systèmes, il nécessite l'activation de la fonctionnalité Hyper-V, même si vous n'utilisez pas Hyper-V par ailleurs. Sur certaines offres VPS, Hyper-V ne peut pas être activé, ce qui bloque cette méthode. Le fait que New-NetNat seul suffise ou que le transfert IP doive également être activé peut dépendre de la version de Windows, alors vérifiez-le sur votre serveur lorsque le tunneling complet ne fonctionne pas.
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 sur le serveur. Confirmez que les clés publiques sont correctement copiées entre les configurations du serveur et du client. Assurez-vous que l'Endpoint dans 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 transmet pas de données. Vérifiez qu'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.
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 les handshakes, les erreurs et les événements de connexion au fur et à mesure qu'ils se produisent. Vous pouvez exporter le journal depuis cet onglet si vous devez le partager.
Démarrage automatique de WireGuard après un redémarrage du serveur
Pour que le tunnel continue de fonctionner après les redémarrages, installez-le en tant que service Windows. Lorsqu'un tunnel est installé en tant que service, il démarre automatiquement après un redémarrage. Ouvrez l'Invite de commandes ou PowerShell en tant qu'administrateur et exécutez ce qui suit, en utilisant le chemin de votre fichier de configuration du serveur :
wireguard /installtunnelservice "C:\Program Files\WireGuard\wg_server.conf"
Après l'installation, le tunnel apparaît dans la liste des Services Windows sous le nom WireGuard Manager, avec l'état En cours d'exécution et le type de démarrage Automatique, ce qui confirme qu'il démarrera de lui-même après un redémarrage.
N'exécutez cette commande qu'une seule fois, pas à chaque démarrage. Activer le tunnel depuis l'application WireGuard installe normalement le même service, donc dans bien des cas il suffit de l'activer une fois. Pour supprimer le service ultérieurement, utilisez le nom du tunnel, qui correspond au 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 suivie de nouveau de la commande d'installation.
Info: Comme le tunnel s'exécute en tant que service, une tâche distincte dans le Planificateur de tâches n'est pas nécessaire.
Redémarrez le serveur et confirmez que le tunnel démarre de lui-même.
