Repères · Tous niveaux · Relecture documentaire : 2 octobre 2026. Les exemples sont génériques ; adapter les noms, versions et chemins avant toute modification.
Créer un pair et une paire de clés par appareil. La clé privée ne doit quitter l’appareil que dans un transfert maîtrisé pour son installation ; le serveur reçoit la clé publique. Attribuer une adresse de tunnel unique et consigner le propriétaire. Un fichier WireGuard contient un secret : le conserver dans un emplacement protégé et ne pas le joindre à un ticket public.
Endpoint désigne l’adresse et le port UDP du serveur. Address est l’adresse du client dans le tunnel. AllowedIPs sélectionne les destinations routées dans le tunnel côté client et participe à l’association des adresses aux pairs côté serveur. Ce champ n’est pas à lui seul une politique complète de contrôle d’accès : le pare-feu doit aussi filtrer.
Un tunnel partagé vers quelques réseaux internes évite de faire passer toute la navigation dans l’entreprise. Un tunnel complet exige aussi routage, DNS et politique de sortie cohérents. N’ajouter 0.0.0.0/0 ou ::/0 que si ce comportement est voulu et configuré. Un réseau distant portant le même préfixe que le réseau local du client peut créer un conflit de route.
Préparer le service sur le pare-feu, le pair et ses droits, puis l’éventuelle redirection UDP sur la box. Importer le fichier dans l’application officielle. Tester depuis une connexion réellement extérieure, par exemple un partage mobile avec le Wi-Fi local désactivé.
Contrôler un handshake récent, les compteurs de trafic, puis DNS et un service interne autorisé. Le handshake confirme une communication cryptographique ; il ne prouve pas que toutes les routes ou permissions sont correctes. Tester également un service interdit.
Sans handshake : vérifier endpoint, port UDP, NAT, opérateur et clés. Avec handshake mais sans accès : vérifier routes, AllowedIPs, DNS et règles sur l’interface VPN. PersistentKeepalive peut être utile à un pair derrière NAT lorsqu’il doit rester joignable ; il n’est pas un remède universel.
Pour un appareil perdu, désactiver son pair immédiatement et remplacer ses secrets. L’administration de l’hyperviseur et du pare-feu doit être autorisée seulement aux pairs qui en ont besoin. Ne pas partager un même fichier entre plusieurs collaborateurs.
Exemple : sous-réseau de tunnel 172.27.66.0/24, serveur .1, poste nomade .2. Choisir un réseau qui n’existe pas déjà sur les sites utilisés. Chaque appareil reçoit sa propre paire de clés ; la clé privée reste sur son appareil. Ne jamais réutiliser une configuration complète pour plusieurs clients connectés simultanément.
| Paramètre | Côté Windows | Côté serveur |
|---|---|---|
| PrivateKey | Clé privée du client | Clé privée du tunnel serveur |
| Address | 172.27.66.2/32 | Adresse de tunnel serveur selon configuration |
| PublicKey du pair | Clé publique du serveur | Clé publique du client |
| Endpoint | Nom public et port UDP du serveur | Souvent dynamique pour un client nomade |
| AllowedIPs | Réseaux à joindre via le tunnel | Adresse du client /32 ; réseaux derrière lui seulement si routés |
| DNS | Résolveur privé joignable | Réglage distribué ou choisi pour le client, pas une preuve d’accès |
| PersistentKeepalive | Utile dans certains cas de NAT | Pas obligatoire pour tous les pairs |
Le fichier ci-dessous contient des marqueurs non utilisables, pas de véritables clés. Ne l’importer qu’après remplissage local sécurisé et création du pair côté serveur.
[Interface]
PrivateKey = REMPLACER_PAR_LA_CLE_PRIVEE_CLIENT
Address = 172.27.66.2/32
DNS = 192.168.50.2
[Peer]
PublicKey = REMPLACER_PAR_LA_CLE_PUBLIQUE_SERVEUR
Endpoint = vpn.example.com:51820
AllowedIPs = 172.27.66.1/32, 192.168.50.0/24, 192.168.60.0/24
PersistentKeepalive = 25
Ce routage est fractionné : seules les destinations listées empruntent le tunnel. 0.0.0.0/0 et ::/0 désignent un tunnel complet et impliquent des politiques de sortie et DNS différentes. Ne pas les ajouter pour « débloquer » un simple service. Les AllowedIPs du serveur associés à ce client ne doivent pas contenir tout le LAN du serveur : cela attribuerait les destinations au mauvais pair.
Publier uniquement le port UDP du tunnel sur la chaîne de routeurs nécessaire. Le pare-feu WAN autorise la négociation WireGuard ; les règles de l’interface VPN déterminent ensuite ce que le client peut atteindre. Autoriser DNS, puis les sous-réseaux et ports administratifs convenus. Les routes retour doivent conduire au serveur VPN ; sinon les requêtes partent mais les réponses se perdent.
Le VPN protège le transport, pas un PC compromis. Conserver comptes nominatifs, authentification applicative et droits adaptés. Révoquer un appareil perdu en retirant son pair, puis vérifier qu’il ne réalise plus de handshake. Un nouveau client exige une nouvelle clé ; ne pas modifier la clé commune du serveur inutilement.
Couper le Wi-Fi domestique et utiliser un partage mobile ou un réseau autorisé. Activer le tunnel, vérifier handshake récent et compteurs émission/réception. Tester le DNS interne puis un service par son nom. Tester aussi un accès interdit. Si handshake absent : endpoint, UDP, clés et NAT ; si handshake présent mais aucun service : routes, AllowedIPs, règles et DNS.
Si de petites requêtes passent mais les transferts bloquent, examiner MTU et découverte de MTU plutôt que de modifier toutes les règles. Si le réseau du lieu de connexion recouvre le LAN distant, préférer corriger le plan ou utiliser des routes spécifiques documentées ; une route ambiguë ne se résout pas par un changement de mot de passe.
Le fichier client est un secret donnant accès au réseau. Le transmettre par canal approprié, protéger sa copie et supprimer les versions provisoires. Avant un changement serveur, exporter la configuration protégée et préserver l’accès local. Une mauvaise règle VPN se corrige depuis cet accès, sans ouvrir l’administration à tout Internet.