Configuration de WireGuard sous Windows

Ce guide explique comment configurer un tunnel VPN WireGuard entre deux machines Windows : un serveur WireGuard fonctionnant sur un hôte Windows distant, par exemple un VPS Windows, et un client WireGuard fonctionnant 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, si vous le souhaitez, acheminer tout le trafic du client via le serveur.

Pour simplifier la génération des clés, ce guide crée les configurations du serveur et du client au sein d'une même 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 s'exécute sur le client. Le serveur et le client sont toujours des machines distinctes. Le même processus est utilisé pour ajouter autant de clients supplémentaires que vous le souhaitez.

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

La configuration décrite dans ce guide se présente comme suit :

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

Lancez C:\Program Files\WireGuard\wireguard.exe, cliquez sur « Ajouter un tunnel », puis choisissez « Ajouter un tunnel vide ». 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 ultérieurement lors de la configuration du 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 = # 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 veillez à ce que le serveur et tous les clients se trouvent dans la même plage d’adresses. Un choix courant consiste à attribuer 10.0.0.1/24 au serveur et 10.0.0.2/32, 10.0.0.3/32, etc. à chaque client. Le serveur utilise un préfixe /24 ; il considère donc l’ensemble de la plage du tunnel comme accessible via l’interface WireGuard. Chaque client utilise un préfixe /32, car un client représente une adresse unique et non un sous-réseau. Un client configuré avec un préfixe /24 considérerait que toute la plage se trouve sur sa propre interface et n’enverrait pas de trafic destiné à d’autres adresses du tunnel via ce dernier.

Dans l’éditeur de tunnel, sous le champ de configuration, vous pouvez, si vous le souhaitez, activer l’option « Bloquer le trafic hors tunnel (kill-switch) », qui bloque tout trafic sortant du tunnel, et définir une « Clé pré-partagée », qui ajoute une couche de sécurité supplémentaire. Ces deux options sont facultatives. Consultez la section « Comprendre les AllowedIPs » pour savoir dans quels cas le kill-switch est utile et ce qu’il bloque.

Création de la configuration du client

Cliquez sur « Ajouter un tunnel » et choisissez « Ajouter un tunnel vide » une deuxième fois, cette fois-ci 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

Le champ « Endpoint » doit correspondre à l’adresse IP publique réelle du serveur, associée au port défini dans le paramètre « ListenPort » du serveur, et non à l’adresse interne du tunnel. Pour obtenir de l’aide sur le choix de la valeur « AllowedIPs », consultez la section « Comprendre les AllowedIPs » ci-dessous.

Les lignes « DNS » et « PersistentKeepalive » sont facultatives. « DNS » définit les serveurs DNS utilisés pendant 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 tels que 1.1.1.1, 1.0.0.1 ou 8.8.8.8, 8.8.4.4, ou encore le serveur DNS du réseau VPN lui-même. PersistentKeepalive = 25 envoie un petit paquet toutes les 25 secondes et permet de maintenir la connexion ouverte lorsque le client se trouve derrière un NAT.

Copiez très soigneusement les clés et le point de terminaison. Une clé mal saisie ou un point de terminaison erroné est la cause la plus fréquente d’échec de connexion au tunnel.

Ajout du client au serveur

Ouvrez à nouveau 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 = # public key of the WireGuard client
AllowedIPs = # internal IP address of the client

Dans la configuration du serveur, AllowedIPs remplit deux fonctions. Il indique au serveur quelle adresse de tunnel appartient à ce client, et il fait office 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 également 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 sécurité avancée, sélectionnez « Règles entrantes », puis cliquez sur « Nouvelle règle ». Choisissez « Port » puis cliquez sur « Suivant ». Sélectionnez « UDP », saisissez le port WireGuard, par exemple 51820, puis 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 » puis 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 tel que « WireGuard UDP 51820 », puis cliquez sur « Terminer ».

Cette règle entrante n’est nécessaire que sur le serveur, car c’est lui 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 « Exporter tous les tunnels au format zip », choisissez un emplacement, puis enregistrez.

Ouvrez l’archive pour trouver les fichiers de configuration de tous les tunnels. Placez la configuration du serveur sur le serveur et attribuez à chaque client son propre fichier de configuration. Si la machine héberge plusieurs tunnels, vous pouvez également exporter un seul tunnel à partir de 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 Activer.

Sur le client, cliquez sur « Ajouter un tunnel », sélectionnez le fichier de configuration du client, puis ouvrez-le.

Cliquez ensuite sur « Activer ».

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

Vérification de la connexion

Une fois le tunnel activé, Windows peut afficher l’adaptateur WireGuard comme « Aucun accès au réseau » ou « Aucun accès à Internet » dans le Centre Réseau et partage. Il s’agit d’un comportement normal, 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 ce statut à l’aide de son test de connectivité, qui interroge des URL Microsoft spécifiques ; l’avertissement peut donc également s’afficher si ces requêtes sont bloquées ou ne sont pas résolues par votre DNS, même lorsque le tunnel fonctionne.

Pour vérifier que le tunnel fonctionne, vérifiez son état dans le client WireGuard. Un tunnel actif affiche le statut « Actif » ainsi que des compteurs de transfert de données. Si les compteurs augmentent, cela signifie que le tunnel achemine du trafic.

Sur le serveur, vous pouvez également vérifier que WireGuard est à l'écoute sur son port UDP tant que le tunnel est actif :

netstat -ano | findstr 51820

Dans PowerShell, la commande équivalente est :

Get-NetUDPEndpoint -LocalPort 51820

Remplacez 51820 par votre port WireGuard. Si aucune réponse n’est renvoyée, cela signifie que le tunnel n’est pas actif ou que le port diffère de celui défini dans la configuration du serveur.

Ensuite, ouvrez l’Invite de commandes et effectuez un ping vers 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 également vérifier que le trafic est acheminé via le tunnel :

tracert 8.8.8.8

Le premier saut doit correspondre à l’adresse IP interne du serveur WireGuard.

Vérification de la poignée de main WireGuard

La poignée de main est l’indicateur le plus utile pour diagnostiquer une connexion WireGuard. Dans l’application WireGuard, ouvrez le tunnel et observez le champ « Dernière poignée de main ». Sur un tunnel opérationnel, la poignée de main 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 peuvent pas se joindre, ce qui indique généralement un Endpoint incorrect, un port UDP fermé ou des clés non correspondantes.

Vous pouvez également vérifier la poignée de main depuis la ligne de commande à l’aide de l’outil `wg` fourni avec WireGuard :

wg show

La sortie répertorie chaque pair avec l'heure de sa dernière poignée de main et ses compteurs de transfert.

Comprendre les AllowedIPs

La valeur AllowedIPs dans la configuration du client détermine quel trafic est acheminé via le tunnel. En résumé, sur le client, AllowedIPs définit quels paquets sont envoyés dans le tunnel, tandis que sur le serveur, elle définit quels paquets provenant d’un client donné sont acceptés et où ils sont acheminés.

Une valeur de 0.0.0.0/0 achemine tout le trafic via le tunnel, y compris la navigation Internet classique. Utilisez-la lorsque vous souhaitez une protection totale du trafic. Pour que ce trafic atteigne Internet, le serveur doit le traduire. Voir « Configuration du NAT sur le serveur pour un tunneling complet » ci-dessous.

Une valeur telle que 10.0.0.0/24 achemine uniquement le trafic du réseau interne via le tunnel, tandis que le trafic Internet classique continue d’utiliser la connexion normale. Utilisez-la lorsque vous avez uniquement besoin d’accéder à des ressources spécifiques sur le réseau distant.

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

Configuration du NAT sur le serveur pour un tunneling complet

Si les clients utilisent AllowedIPs = 0.0.0.0/0 et que vous souhaitez que leur trafic atteigne effectivement Internet via le serveur, ce dernier doit traduire les adresses WireGuard internes en sa propre adresse externe. Sous Windows, cela s’effectue à l’aide de 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 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 toutes les adresses client que vous attribuez. Un client situé 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 la négociation s’effectue avec succès, mais que leur trafic Internet ne transite toujours pas par le serveur, activez le transfert IP sur les interfaces impliquées dans le routage et effectuez un nouveau test. La syntaxe exacte dépend de la version de Windows, par exemple :

Set-NetIPInterface -InterfaceAlias "Ethernet" -Forwarding Enabled

Appliquez-la à l’interface externe qui achemine le trafic Internet et à l’interface WireGuard, en utilisant leurs noms réels obtenus via 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 le 51820, est ouvert dans le pare-feu du serveur. Assurez-vous que les clés publiques ont bien été copiées entre les configurations du serveur et du client. Assurez-vous que le paramètre « 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 dans la section « Interface 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 que le paramètre `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 port d'écoute (`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 à partir de cet onglet si vous avez besoin de le partager.

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

Pour que le tunnel continue de fonctionner après un redémarrage, 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 la commande suivante, en utilisant le chemin d’accès à votre fichier de configuration du serveur :

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

N’exécutez cette commande qu’une seule fois, et non à chaque démarrage. L’activation du tunnel depuis l’application WireGuard installe normalement le même service ; dans la plupart des cas, une seule activation suffit donc. 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, puis la commande d’installation à nouveau.

Redémarrez le serveur et vérifiez que le tunnel démarre automatiquement.