WireGuard : configuration client la plus simple sur Windows/macOS/Linux (et les pièges habituels)

1) Le modèle mental : ce que WireGuard fait réellement sur un client

WireGuard n’est pas un interrupteur « internet sécurisé » magique. C’est un logiciel très réduit et très opinionné qui crée une interface réseau virtuelle (généralement wg0 sur Linux, un adaptateur « WireGuard Tunnel » sur Windows, une interface utun sur macOS). Quand le tunnel est actif, votre OS route une partie du trafic vers cette interface. Le peer WireGuard de l’autre côté déchiffre et réachemine ensuite (souvent vers votre réseau d’entreprise, parfois vers l’internet public).

Les trois leviers que vous contrôlez réellement

• Clés : qui peut communiquer avec qui.
• AllowedIPs : quelles destinations sont routées dans le tunnel (et aussi comment les peers sont appariés sur le récepteur).
• Endpoint : où se trouve l’autre côté maintenant (et si le NAT le rend joignable).

Tout ce qui fait mal est généralement déguisé en l’un de ces éléments : décisions de routage, comportement DNS, état firewall/NAT, ou MTU. WireGuard est direct : il met en place la crypto et envoie les paquets. Il ne négocie pas des routes comme un VPN d’entreprise bavard ; il ne « corrige » pas votre DNS sauf si vous le lui dites ; il ne devine pas si vous vouliez un split tunneling ou un full tunneling.

Un état d’esprit utile en exploitation : traitez WireGuard comme un câble réseau point-à-point que vous branchez et débranchez. Si les paquets ne traversent pas le câble, inspectez dans l’ordre : (1) lien actif (handshake), (2) routage L3, (3) atteignabilité L4, (4) résolution de noms. Toujours dans cet ordre. Votre futur vous enverra une note de remerciement.

Une citation pour rester honnête, paraphrasant John Allspaw : « La fiabilité vient de la façon dont vous répondez aux pannes, pas de prétendre que les pannes n’arriveront pas. »

Blague #1 : WireGuard est comme un videur bien entraîné — discret, efficace, et complètement indifférent à vos sentiments sur le routage.

2) Faits et contexte intéressants (pour cesser de lutter contre l’outil)

Ce ne sont pas des anecdotes pour faire joli. Elles expliquent pourquoi WireGuard se comporte comme il le fait — et pourquoi certaines attentes « traditionnelles » vis-à-vis des VPN ne s’appliquent pas.

1. WireGuard a été conçu pour être minimal : beaucoup moins de lignes de code que les piles VPN classiques, pour réduire la surface d’attaque et la complexité opérationnelle.
2. Il utilise des primitives modernes par défaut : vous ne choisissez pas les suites de chiffrement ; le protocole sélectionne un ensemble étroit et contemporain (NoiseIK, ChaCha20-Poly1305, Curve25519, BLAKE2s, HKDF).
3. C’est un VPN de couche 3 : il route des paquets IP (et gère proprement IPv6). Ce n’est pas un pont L2 à moins que vous le construisiez par-dessus.
4. « AllowedIPs » est à la fois routage et contrôle d’accès : côté récepteur, c’est le mappage qui décide quel peer correspond à un paquet déchiffré ; les chevauchements peuvent provoquer des comportements déroutants.
5. Le roaming est intégré : si l’IP publique du client change (Wi‑Fi → LTE), WireGuard peut suivre dès qu’il voit du trafic authentifié depuis la nouvelle adresse.
6. L’amabilité avec le NAT n’est pas magique : cela dépend toujours de l’état UDP ; c’est pourquoi PersistentKeepalive existe.
7. Linux d’abord, mais réalité multi-plateforme : l’implémentation noyau Linux est la référence pour la performance ; les autres plateformes utilisent des intégrations natives ou une implémentation en espace utilisateur avec des particularités propres au système.
8. WireGuard est rapidement devenu « standard » sur Linux : il a été intégré au noyau Linux (ère 5.6), d’où son caractère de première classe sur les distributions modernes.
9. Il évite délibérément les fonctions de négociation : pas de complexité à la IKE. Excellent pour les humains. Parfois inconfortable pour les listes de contrôle d’entreprise.

3) Clés, peers et le fichier unique qui compte

Une configuration client WireGuard est un petit fichier de type INI. Il comporte deux sections : [Interface] (votre interface virtuelle locale) et une ou plusieurs entrées [Peer] (les endpoints distants vers lesquels vous chiffrez).

Configuration client minimale (exemple de tunnel fractionné)

C’est la forme à partir de laquelle vous devriez commencer. N’ajoutez de la complexité que lorsque c’est nécessaire. Surtout en entreprise, chaque ligne supplémentaire est une nouvelle façon de perdre un après-midi.

cr0x@server:~$ cat wg-client.conf
[Interface]
PrivateKey = <client-private-key>
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.8.0.0/24, 10.20.0.0/16
PersistentKeepalive = 25

Interprétation, en anglais opérationnel simple :

• Address : l’IP du client sur le tunnel. Le /32 n’est pas une erreur ; cela signifie « cette interface possède uniquement cette IP », ce qui réduit les bizarreries de routage accidentelles.
• DNS : quel résolveur utiliser pendant que le tunnel est actif. Sans cela, vous aurez souvent « je peux ping des IPs mais les noms échouent. »
• AllowedIPs : liste du split tunnel. Seules ces destinations seront routées dans le tunnel. Si vous mettez 0.0.0.0/0 (et peut-être ::/0), vous tunnelisez tout le trafic.
• PersistentKeepalive : maintenir l’état NAT pour les clients derrière des NAT stricts (hôtels, LTE). 25 secondes est le chiffre commun qui « marche juste ».

Deux règles qui évitent la plupart des incidents

1. Ne pas chevaucher AllowedIPs entre peers sur la même interface, sauf si vous aimez la sélection de peer nondéterministe.
2. Décidez à l’avance split vs full tunnel et encodez-le explicitement. « On va juste ajouter 0.0.0.0/0 et voir » est la façon de casser l’impression, la VoIP et votre patience.

4) Configuration du client Windows (simple, avec les pièges habituels)

Approche recommandée : l’application officielle WireGuard pour Windows

Sur Windows, soyez ennuyeux : utilisez le client officiel avec interface graphique. Il installe un adaptateur tunnel WireGuard et gère proprement les routes. Vous pouvez importer un fichier de configuration, activer le tunnel, et il survit aux redémarrages sans scripts créatifs.

Étapes qui fonctionnent dans de vraies entreprises

1. Importer la config : utilisez « Import tunnel(s) from file ». Ne saisissez pas les clés à la main. Les humains sont mauvais en base64.
2. Nommez le tunnel explicitement : « corp-split » ou « prod-breakglass ». « test » devient permanent, puis votre identité.
3. Activez on-demand seulement si vous comprenez le réseau Windows : il est facile de créer des états « connecté mais inutilisable » lorsque les réseaux changent.
4. Vérifiez le comportement DNS : Windows a une longue histoire de listes de suffixes DNS et de priorité du résolveur faisant des choses inattendues quand plusieurs interfaces existent.

Pièges Windows à anticiper

• Handshake OK, trafic non : souvent un problème de route ou de firewall, pas WireGuard lui-même. Windows peut avoir plusieurs routes par défaut avec des métriques surprenantes.
• Fuites DNS ou mauvais résolveur : si vous ne définissez pas DNS dans la config, Windows continue d’utiliser ce qu’il veut (souvent le DNS de la NIC physique).
• Priorité/metrics de l’adaptateur : parfois Windows insiste pour envoyer le trafic hors du tunnel car l’interface physique a une métrique plus basse.
• Captive portals : hôtels et Wi‑Fi invités peuvent bloquer UDP ou exiger une connexion web ; le tunnel ne montera pas tant que le portail n’est pas satisfait.

5) Configuration du client macOS (app vs wg-quick, et les pièges DNS)

macOS offre deux options courantes : l’application officielle WireGuard (recommandée) ou des outils en ligne de commande (via des paquets tiers). Pour la majorité des personnes qui veulent la fiabilité, l’application l’emporte : elle s’intègre au système d’extension réseau de macOS et gère le cycle de vie de l’interface sans que vous bricoliez des agents de lancement.

Utilisez l’application sauf raison contraire

Le Wi‑Fi d’entreprise et les cycles fréquents veille/réveil sont les domaines où les outils VPN « presque fonctionnels » meurent. L’application tend à mieux récupérer des changements réseau et à rétablir l’état DNS/route.

Réalités DNS spécifiques à macOS

Le DNS sur macOS n’est pas « un fichier, un résolveur ». C’est une pile avec des résolveurs par interface, des domaines de recherche et une résolution scoping. Un tunnel WireGuard peut être actif et fonctionner, tandis que votre navigateur continue de résoudre des noms internes via le mauvais résolveur à cause de l’ordre des résolveurs ou de domaines de recherche manquants.

Si votre entreprise utilise un DNS fractionné (domaines internes résolus seulement via le DNS interne), vous devriez définir les deux :

• Serveur DNS (ex. 10.8.0.1), et
• Domaines de recherche (ex. corp.example), lorsque votre client le prend en charge.

Sans domaines de recherche, les utilisateurs tapent des noms courts et obtiennent des réponses DNS publiques. Ce n’est pas une « erreur utilisateur » ; c’est un résultat de configuration prévisible.

Piège macOS : veille/réveil et routes obsolètes

Après un réveil, vous pouvez voir un tunnel « connecté » mais sans trafic. En général il s’agit d’un état UDP ou d’une table de routage qui ne s’est pas mise à jour proprement. Basculer le tunnel résout souvent ; définir PersistentKeepalive aide aussi pour les clients en roaming.

6) Configuration du client Linux (wg-quick, NetworkManager, et la réalité du routage)

Linux est l’endroit où WireGuard donne l’impression d’avoir toujours dû exister. Vous disposez du module noyau, des outils wg, et de wg-quick qui est une enveloppe pragmatique configurant l’interface, les routes et les hooks DNS.

La voie « simplement faire marcher » : wg-quick

Vous placez une config dans /etc/wireguard/wg0.conf et exécutez wg-quick up wg0. C’est tout. Le mieux est que c’est réversible : wg-quick down wg0 nettoie routes et état d’interface.

Intégration NetworkManager : bien, mais sachez ce qu’il fait

Si vous êtes sur un portable avec NetworkManager, vous pouvez importer la config WireGuard et le laisser gérer le tunnel. Cela peut être excellent pour le roaming, mais ajoute une couche qui peut remplacer routes ou DNS selon la distro et la version. Lors du débogage, soyez clair sur qui « possède » l’interface — wg-quick ou NetworkManager — pas les deux.

Pièges Linux qui mordent des ingénieurs expérimentés

• Interactions avec le routage politique : les systèmes modernes peuvent avoir plusieurs tables de routage (surtout avec des plugins container/network). Vos routes de tunnel peuvent se retrouver au mauvais endroit si vous n’êtes pas prudent.
• Reverse path filtering : rp_filter peut abandonner du trafic légitime dans des scénarios de routage asymétrique.
• iptables/nftables NAT : pour une configuration client c’est généralement sans objet, mais pour un « client qui forwarde » ou « client comme gateway », vous devez explicitement faire du NAT et activer le forwarding.
• systemd-resolved : la gestion du DNS peut vous surprendre si resolv.conf est un stub et que vous vous attendez à ce que DNS= fonctionne sans les hooks appropriés.

7) Tâches pratiques : commandes, sortie attendue et décisions (12+)

Voici les vérifications que j’exécute réellement quand quelqu’un dit « WireGuard est up mais rien ne marche ». Chaque tâche inclut : la commande, ce que signifie la sortie, et la décision suivante.

Task 1: Confirmer que l’interface existe et est UP (Linux)

cr0x@server:~$ ip link show wg0
7: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

Sens : L’interface wg0 existe et est UP. mtu 1420 est typique. state UNKNOWN est normal pour des tunnels.

Décision : Si elle est DOWN ou absente, votre tunnel n’est pas monté. Réparez le service/UI d’abord. Si elle est up, passez au handshake et au routage.

Task 2: Vérifier handshake WireGuard et compteurs de trafic

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 5Z5Jw0y5mOQ4rGqgXwq8yW9q0l1bQp3m5G5m6l8P8xk=
  private key: (hidden)
  listening port: 51820

peer: 9sZxq2Qb7D2i2c8p9n5m0tTn0aVY7mXlCkQw1kVv0m4=
  endpoint: 203.0.113.10:51820
  allowed ips: 10.8.0.0/24, 10.20.0.0/16
  latest handshake: 18 seconds ago
  transfer: 12.34 MiB received, 9.87 MiB sent
  persistent keepalive: every 25 seconds

Sens : Vous avez un handshake récent et des paquets qui bougent. Si « latest handshake » est « never », vous avez probablement un problème d’endpoint/UDP/firewall/NAT.

Décision : Si le handshake est récent mais que le transfert reste à 0, suspectez le routage/AllowedIPs/firewall côté distant.

Task 3: Valider l’IP du tunnel du client

cr0x@server:~$ ip addr show dev wg0
7: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 10.8.0.2/32 scope global wg0
       valid_lft forever preferred_lft forever

Sens : Le client a 10.8.0.2/32 assigné. OK.

Décision : Si absent ou incorrect, corrigez Address dans la config et redémarrez le tunnel.

Task 4: Confirmer que les routes pour AllowedIPs sont installées

cr0x@server:~$ ip route show table main | grep wg0
10.8.0.0/24 dev wg0 scope link
10.20.0.0/16 dev wg0 scope link

Sens : Les routes de split-tunnel existent. Le trafic vers ces CIDR va dans wg0.

Décision : Si les routes manquent, soit wg-quick n’a pas été exécuté, soit un autre gestionnaire a retiré les routes, ou vous avez utilisé une méthode qui ne les ajoute pas automatiquement. Corrigez cela avant de toucher au DNS.

Task 5: Voir quelle route sera utilisée pour une destination spécifique

cr0x@server:~$ ip route get 10.20.5.10
10.20.5.10 dev wg0 src 10.8.0.2 uid 1000
    cache

Sens : L’OS enverra des paquets vers 10.20.5.10 via wg0.

Décision : Si ça indique dev eth0 (ou l’interface Wi‑Fi), vos AllowedIPs/routes sont incorrectes. Corrigez le routage d’abord ; ne « déboguez WireGuard » que s’il est effectivement utilisé.

Task 6: Tester l’atteignabilité par IP (ignorer le DNS)

cr0x@server:~$ ping -c 2 10.20.5.10
PING 10.20.5.10 (10.20.5.10) 56(84) bytes of data.
64 bytes from 10.20.5.10: icmp_seq=1 ttl=63 time=28.3 ms
64 bytes from 10.20.5.10: icmp_seq=2 ttl=63 time=27.9 ms

--- 10.20.5.10 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 27.933/28.110/28.288/0.177 ms

Sens : L’atteignabilité L3 fonctionne via le tunnel.

Décision : Si le ping par IP échoue mais que le handshake existe, suspectez firewall distant, routes manquantes côté serveur, ou MTU. Si le ping marche mais que les noms échouent, passez aux tâches DNS.

Task 7: Tester un service TCP (parce qu’ICMP ment)

cr0x@server:~$ nc -vz 10.20.5.10 22
Connection to 10.20.5.10 22 port [tcp/ssh] succeeded!

Sens : TCP/22 atteignable ; les groupes de sécurité/firewalls le permettent probablement.

Décision : Si le ping fonctionne mais TCP échoue, vous avez un problème de firewall/service, pas « VPN cassé ». Escaladez vers le propriétaire du service ou la politique de sécurité.

Task 8: Vérifier le choix du résolveur DNS (Linux avec systemd-resolved)

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 7 (wg0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.8.0.1
       DNS Servers: 10.8.0.1

Sens : Le DNS pour wg0 est réglé sur 10.8.0.1. Bien.

Décision : Si le serveur DNS reste celui de votre Wi‑Fi, attendez-vous à des échecs de noms internes et à des fuites. Corrigez le DNS dans la config ou via resolved.

Task 9: Prouver que le DNS interne fonctionne (et voir où il va)

cr0x@server:~$ dig @10.8.0.1 internal-api.corp.example A +short
10.20.5.10

Sens : Le résolveur interne renvoie une adresse interne.

Décision : Si cela marche mais que dig internal-api.corp.example échoue, le problème est la sélection du résolveur/domaines de recherche, pas le serveur.

Task 10: Vérifier le MTU et les blackholes PMTU

cr0x@server:~$ ping -M do -s 1380 -c 2 10.20.5.10
PING 10.20.5.10 (10.20.5.10) 1380(1408) bytes of data.
1388 bytes from 10.20.5.10: icmp_seq=1 ttl=63 time=28.9 ms
1388 bytes from 10.20.5.10: icmp_seq=2 ttl=63 time=29.1 ms

--- 10.20.5.10 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms

Sens : Des paquets ICMP d’environ ~1408 octets avec DF passent. Bon signe.

Décision : Si vous voyez « Frag needed and DF set » ou des timeouts à des tailles plus grandes, réduisez le MTU WireGuard (souvent 1280–1420). Les problèmes de MTU se présentent souvent comme « SSH marche mais Git clone bloque » ou « page web charge à moitié ».

Task 11: Confirmer l’atteignabilité UDP vers l’endpoint (côté client)

cr0x@server:~$ nc -vu -w 2 vpn.example.net 51820
Connection to vpn.example.net 51820 port [udp/*] succeeded!

Sens : Votre système peut envoyer de l’UDP à cet hôte/port. Cela ne garantit pas les réponses (UDP), mais élimine certains blocs d’egress locaux.

Décision : Si cela échoue sur un réseau d’entreprise, vous pourriez avoir besoin d’une autre politique d’egress ou d’un endpoint/port différent. Ne perdez pas de temps à régler Keepalive si l’UDP est bloqué en sortie.

Task 12: Inspecter l’état du firewall (client Linux)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,80p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy accept;
  }
  chain forward {
    type filter hook forward priority 0; policy drop;
  }
  chain output {
    type filter hook output priority 0; policy accept;
  }
}

Sens : Le forwarding est droppé (défaut commun), mais pour un client c’est normal. Input/output accept signifie que le client lui‑même peut communiquer.

Décision : Si output est restreint, WireGuard peut faire le handshake mais le trafic vers des sous‑réseaux internes peut être bloqué. Ajustez les règles soigneusement ou utilisez un profil firewall hôte qui permet le tunnel.

Task 13: Vérifier le sysctl qui peut casser des tunnels routés (rp_filter)

cr0x@server:~$ sysctl net.ipv4.conf.all.rp_filter
net.ipv4.conf.all.rp_filter = 1

Sens : Le reverse path filtering est en mode « strict » (1). Cela peut abandonner du trafic dans des scénarios de routage asymétrique.

Décision : Pour un usage client normal, cela va généralement. Pour un routage fractionné complexe ou du multi-homing, envisagez de mettre à 2 (loose) sur les interfaces pertinentes après avoir compris les implications de sécurité.

Task 14: Confirmer quel fichier DNS vous utilisez réellement

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Jan  2 10:11 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Sens : Vous êtes sur un stub systemd-resolved. Éditer /etc/resolv.conf directement ne persistera pas et peut ne pas faire ce que vous pensez.

Décision : Configurez le DNS via resolvectl, NetworkManager, ou votre gestionnaire WireGuard, pas en éditant manuellement les fichiers stub en espérant le meilleur.

8) Playbook de diagnostic rapide (vérifications 1re/2e/3e)

Si vous ne mémorisez qu’un seul workflow, retenez celui-ci. Il trouve rapidement le goulot sans cargo-culter des changements de config.

Premier : le tunnel échange-t-il vraiment des paquets ?

• Vérifiez que l’interface existe et est UP.
• Vérifiez le latest handshake et les compteurs de transfert.
• Si le handshake est jamais : concentrez-vous sur l’endpoint, l’atteignabilité UDP, le NAT, et le keepalive.

Second : l’OS route-t-il le bon trafic dans le tunnel ?

• Confirmez que les routes existent pour vos destinations prévues (AllowedIPs).
• Utilisez un lookup de route pour une IP interne connue (ip route get sur Linux).
• Si le trafic n’est pas routé vers le tunnel : corrigez AllowedIPs ou les conflits de gestionnaire de routes.

Troisième : pouvez-vous joindre quelque chose par IP, puis par nom ?

• Pingez une IP interne. Puis testez un port TCP (SSH/HTTPS) car ICMP peut être autorisé quand TCP ne l’est pas.
• Si l’IP marche mais les noms échouent : corrigez le DNS (serveur, domaines de recherche, priorité du résolveur).

Quatrième : MTU et pannes « ça marche pour les petites choses »

• Si le chat marche mais les transferts de fichiers bloquent : suspectez MTU/PMTU.
• Réduisez le MTU sur le tunnel client et retestez.

Cinquième : l’autre côté (routage/NAT/firewall serveur)

• Le client ne fait qu’envoyer des paquets chiffrés. Le serveur décide s’il les route ensuite.
• Si handshake et routage client semblent corrects, le serveur peut manquer de routes vers les sous‑réseaux clients ou bloquer le forwarding.

9) Erreurs courantes : symptôme → cause racine → correction

1) « Connecté » mais pas de handshake

Symptôme : L’UI client indique actif, mais latest handshake est « never ».

Cause racine : Endpoint hôte/port incorrect, UDP bloqué, captive portal, ou mappage NAT qui expire instantanément.

Correction : Vérifiez l’endpoint, testez l’egress UDP, complétez la connexion captive portal, ajoutez PersistentKeepalive = 25 pour les clients en roaming, et assurez-vous que le serveur écoute réellement sur ce port.

2) Handshake OK, mais aucun trafic n’atteint les réseaux internes

Symptôme : Le handshake se met à jour, mais vous ne pouvez pinguer aucune IP interne ; les compteurs de transfert avancent à peine.

Cause racine : AllowedIPs n’inclut pas les sous‑réseaux internes, ou les routes n’ont pas été installées, ou la métrique de route Windows préfère l’interface physique.

Correction : Ajoutez les CIDR internes corrects à AllowedIPs sur le client. Confirmez les routes. Sous Windows, vérifiez la table de routage et les métriques ; assurez-vous que les routes du tunnel sont plus spécifiques que la route par défaut en cas de split tunneling.

3) Connectivité IP OK, mais noms d’hôtes échouent

Symptôme : Vous pouvez ping 10.20.5.10 mais ssh internal-api ne se résout pas.

Cause racine : DNS non défini, domaine de recherche manquant, systemd-resolved/NetworkManager n’appliquent pas le DNS au tunnel, ou le DNS est défini mais bloqué par la politique.

Correction : Mettez DNS = ... dans la config client et assurez-vous que votre plateforme l’applique. Sur macOS, vérifiez que le résolveur du tunnel est réellement utilisé. Ajoutez des domaines de recherche lorsque pris en charge.

4) Tout marche sauf les transferts « gros » (Git, Docker pulls, copies de fichiers)

Symptôme : De petits pings réussissent, certains sites se chargent, mais les gros téléchargements stagnent.

Cause racine : MTU/PMTU blackhole ; la fragmentation est bloquée quelque part entre client et serveur.

Correction : Réduisez le MTU du tunnel (essayez 1380, puis 1360, puis 1280). Retestez avec des pings DF. Préférez un MTU cohérent sur la flotte client quand c’est possible.

5) Le split tunnel est devenu accidentellement un full tunnel

Symptôme : L’impression ne marche plus, Zoom déconne, les appareils locaux disparaissent, l’IP publique devient celle de la sortie bureau.

Cause racine : AllowedIPs inclut 0.0.0.0/0 (et possiblement ::/0), ou une route par défaut OS a été ajoutée.

Correction : Supprimez la route par défaut d’AllowedIPs. Si vous avez besoin d’un routage internet sélectif, faites-le intentionnellement avec du policy routing — ne prétendez pas qu’une route par défaut est « temporaire ».

6) Deux peers, une destination : le trafic va au mauvais endroit

Symptôme : Certains sous‑réseaux internes routent de façon intermittente vers le « mauvais » peer ; le comportement change après reconnexion.

Cause racine : AllowedIPs qui se chevauchent entre peers sur la même interface.

Correction : Rendez les AllowedIPs disjoints. Si vous avez besoin d’un basculement, implémentez‑le via un mécanisme de niveau supérieur ; ne comptez pas sur l’ambiguïté.

7) Marche sur Wi‑Fi, échoue sur LTE/hotspot

Symptôme : À la maison tout va bien ; sur le hotspot du téléphone le handshake se fait une fois puis meurt.

Cause racine : Le mappage NAT expire rapidement ; le roaming change l’endpoint ; absence de keepalive.

Correction : Définissez PersistentKeepalive. Confirmez que le serveur autorise le roaming (la plupart le font par défaut). Envisagez de déplacer le serveur vers un réseau ayant un traitement UDP stable.

8) Windows dit connecté, mais le trafic interne sort par la mauvaise NIC

Symptôme : Les routes internes existent mais ne sont pas utilisées ; la lookup de route montre l’interface Wi‑Fi.

Cause racine : Routes concurrentes et métriques ; parfois une route plus large avec une meilleure métrique gagne sur Windows.

Correction : Assurez-vous que vos routes de tunnel sont correctement spécifiques et que les métriques se comportent. Évitez de pousser des routes larges qui chevauchent des routes corpales existantes sauf si vous le souhaitez.

10) Trois micro-histoires du monde corporate (situations reconnaissables)

Histoire A : l’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a déployé WireGuard pour remplacer un VPN vieillissant. Le pilote était fluide : ingénieurs sur Linux, réseaux domestiques propres, un seul sous‑réseau interne. La config utilisait le split tunneling et un DNS interne. Tout semblait réussi.

Puis le déploiement s’est étendu aux utilisateurs Windows. Les tickets de support ont commencé : « VPN connecté, noms internes cassés. » L’équipe réseau a supposé que le DNS « faisait partie du VPN », parce que l’ancien client se comportait ainsi. Les fichiers de config WireGuard n’incluaient pas de directive DNS, puisque personne ne l’avait remarqué durant le pilote — les utilisateurs Linux avaient déjà le DNS fractionné configuré localement via d’autres outils.

Les opérations ont tenté de « réparer » en ajoutant des entrées host pour quelques services critiques. Cela a réglé les choses pendant un jour et créé un chantier d’archéologie : IPs obsolètes, comportements inconsistants, et une dépendance croissante sur ce qui aurait dû être un problème de résolveur.

La vraie correction fut ennuyeuse : définir le comportement DNS explicitement dans la config client (et ajouter les domaines de recherche quand nécessaire), puis vérifier sur chaque OS que la sélection du résolveur change bien quand le tunnel monte. La leçon n’était pas « WireGuard est compliqué ». La leçon était « vos attentes viennent d’un autre produit. »

Histoire B : l’optimisation qui a mal tourné

Une équipe sécurité voulait réduire la complexité d’egress. Leur idée : tunneliser tout le trafic des portables via une gateway WireGuard centrale, puis appliquer DLP et logging en un point. C’est un réflexe courant : si le réseau est bordélique, canalisez‑le et appelez ça de la gouvernance.

Le déploiement « a marché » au sens où les handshakes se faisaient et le trafic circulait. Ce qui a échoué, c’était tout autour : applications sensibles à la latence, accès réseau local, et tout ce qui dépend de CDNs géographiquement proches. Les appels vidéo commençaient à transiter par un egress distant, et les plaintes internes se sont transformées en demandes de statut toutes les heures par les dirigeants.

L’équipe a alors « optimisé » en augmentant le MTU pour tenter d’améliorer les performances. Sur certains chemins cela a aidé ; sur d’autres cela a créé des blackholes PMTU. Ils se sont retrouvés avec un double mode de panne : certains utilisateurs avaient de la lenteur générale, d’autres des blocages et des pages à moitié chargées. Le tunnel n’était pas en panne ; il était pire : il était inconstamment cassé.

Le plan de reprise fut d’abandonner l’idée qu’une politique unique convient à tous. Ils sont passés au split tunneling pour la plupart, gardant le full tunnel seulement pour les rôles à haut risque, ont standardisé un MTU conservateur, et documenté ce que « full tunnel » casse réellement. Ce n’était pas aussi propre idéologiquement. C’était opérationnellement sain.

Histoire C : la pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe de services financiers utilisait WireGuard pour l’accès fournisseur à un environnement restreint. Le setup était discret : petit nombre de peers, AllowedIPs statiques, contrôle de changement strict, et un test mensuel « prouver que ça marche encore » où quelqu’un validait handshake, routes, DNS, et un ou deux flux applicatifs.

Un lundi, un fournisseur signale une panne totale : pas d’accès interne. Le client montrait « connecté », mais le trafic applicatif était mort. L’équipe n’a pas commencé par des hypothèses. Ils ont suivi leur checklist : état du handshake, compteurs, lookup de route, résolution DNS, puis vérifications MTU. Cela n’était aucune de ces choses.

Le vrai problème était en amont : une modification de firewall bloquait l’UDP entrant vers le port WireGuard depuis un ASN partenaire spécifique. Parce qu’ils faisaient un exercice routinier, ils avaient aussi des sorties de référence pour l’état « sain ». L’absence totale de handshake a rendu le problème évident et raccourci la discussion avec l’équipe firewall.

La correction fut un ajustement de politique ciblé. Pas d’héroïsme. La valeur n’était pas dans l’outil ; c’était l’habitude vérifiable et une définition partagée de « fonctionner ».

11) Checklists / plan pas-à-pas

Checklist d’installation client (tous OS)

1. Obtenir une config propre depuis le côté serveur (ou la générer) : private key client, IP tunnel client, public key serveur, endpoint, et AllowedIPs.
2. Décider de la politique de tunnel : split tunnel (recommandé pour la plupart) ou full tunnel (seulement si nécessaire et en acceptant le rayon d’impact).
3. Définir explicitement le DNS : résolveur interne et domaines de recherche si votre environnement utilise des noms courts.
4. Ajouter keepalive pour les clients en roaming : PersistentKeepalive = 25.
5. Monter le tunnel.
6. Vérifier handshake et compteurs.
7. Vérifier le routage pour une IP interne.
8. Vérifier la résolution DNS pour un nom interne.
9. Tester un chemin applicatif réel (HTTPS vers un endpoint interne, SSH, ou ce qui compte).
10. Documenter le comportement attendu (quels subnets sont accessibles, si l’internet est tunnelisé, quel DNS utiliser).

Étapes Windows (client uniquement)

1. Importer la config dans l’application WireGuard.
2. Confirmer que AllowedIPs est conforme à l’intention (split vs full).
3. Assurer que DNS est défini si vous avez besoin de résolution interne.
4. Activer le tunnel.
5. Si « connecté » mais inutile : vérifiez la table de routage et le comportement DNS avant de toucher aux clés.

Étapes macOS (client uniquement)

1. Importer la config dans l’application WireGuard.
2. Activer le tunnel et confirmer qu’il survit aux cycles veille/réveil.
3. Si les noms internes échouent : vérifiez si le résolveur du tunnel est réellement utilisé et si vous avez besoin de domaines de recherche.
4. Si cela casse seulement sur certains réseaux : ajoutez le keepalive et envisagez de réduire le MTU.

Linux pas-à-pas avec wg-quick

1. Placer la config dans /etc/wireguard/wg0.conf, permissions verrouillées.
2. Monter le tunnel.
3. Vérifier handshake et routes.
4. Vérifier l’intégration DNS (systemd-resolved vs réalité de resolv.conf).

cr0x@server:~$ sudo install -m 600 wg-client.conf /etc/wireguard/wg0.conf
cr0x@server:~$ sudo wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.8.0.2/32 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] ip -4 route add 10.8.0.0/24 dev wg0
[#] ip -4 route add 10.20.0.0/16 dev wg0
[#] resolvconf -a wg0 -m 0 -x
[#] iptables -I OUTPUT -o wg0 -j ACCEPT

Sens : wg-quick a créé l’interface, appliqué la config, ajouté l’adresse et les routes, et tenté les hooks DNS. (La méthode de hook varie selon la distro.)

Décision : Si vous ne voyez pas les routes ajoutées, les AllowedIPs de votre config peuvent être vides/incorrectes, ou vous utilisez un autre gestionnaire. Corrigez cela avant d’escalader.

Blague #2 : Si votre problème VPN disparaît quand vous baissez le MTU, félicitations — vous venez de découvrir que l’internet fonctionne encore avec des bonnes ondes et du ruban adhésif.

12) FAQ

Q1 : Que fait réellement « AllowedIPs » ?

Sur le client, c’est la liste de sélection de route : destinations qui doivent être envoyées dans le tunnel. Sur le récepteur, c’est aussi la sélection de peer : quel peer « possède » une plage source/destination donnée. Traitez‑le comme à la fois une intention de routage et une carte de contrôle d’accès.

Q2 : Dois‑je utiliser 0.0.0.0/0 sur les clients ?

Uniquement si vous voulez un full tunnel et que vous acceptez les effets secondaires (accès réseau local perdu, changements de géolocalisation/CDN, latence, goulots d’entreprise). Le split tunnel est opérationnellement plus calme pour la plupart des organisations d’ingénierie.

Q3 : Pourquoi je vois des handshakes mais pas de trafic ?

Parce qu’un handshake ne prouve que les deux peers peuvent échanger des messages authentifiés. Il ne prouve pas que votre OS route le trafic dans le tunnel, ni que le serveur le route ensuite. Vérifiez les routes, AllowedIPs et le forwarding/firewall côté serveur.

Q4 : Ai‑je besoin de PersistentKeepalive ?

Pour les clients en roaming derrière NAT (la plupart des portables hors site), oui. Si vous êtes sur des réseaux stables et que vous initiez toujours le trafic, peut‑être pas. En pratique, 25 secondes est une assurance peu coûteuse.

Q5 : Pourquoi le DNS fuit‑il hors du tunnel ?

Parce que le DNS est son propre sous‑système et votre OS peut préférer le résolveur de l’interface physique à moins que vous ne définissiez explicitement le DNS et que votre gestionnaire client l’applique correctement. Corrigez la sélection DNS, pas la crypto WireGuard.

Q6 : Quel est le bon MTU pour WireGuard ?

Il n’y a pas de valeur universelle. 1420 est courant. Si vous voyez des blocages, essayez 1380, puis 1360, puis 1280. Le « bon » MTU est le plus grand qui n’engendre pas de blackholes sur votre chemin réseau le plus défavorable.

Q7 : Puis‑je avoir plusieurs peers dans une config client ?

Oui, mais soyez discipliné : pas d’AllowedIPs chevauchées. Si vous avez besoin d’un basculement, concevez‑le explicitement ; ne comptez pas sur des chevauchements ambigus pour que WireGuard « choisisse le meilleur ».

Q8 : Pourquoi ça marche sur Wi‑Fi mais échoue sur les réseaux d’hôtel ?

Les hôtels adorent les captive portals, le throttling UDP et des timeouts NAT étranges. Authentifiez le portail d’abord, puis utilisez le keepalive. Si l’UDP est bloqué complètement, vous aurez besoin d’un autre réseau ou d’un endpoint alternatif approuvé par la politique.

Q9 : WireGuard est‑il « plus sécurisé » que les VPN plus anciens ?

C’est sécurisé quand il est bien configuré et il bénéficie d’un design plus petit et plus auditable. Mais la sécurité est une propriété système : la gestion des clés, le durcissement des endpoints et la politique de routage comptent autant que le protocole.

Q10 : Quelle est la façon la plus simple d’éviter les pannes auto-infligées ?

Gardez les configs minimales, standardisez des templates, évitez les AllowedIPs chevauchées, définissez le DNS intentionnellement, et validez avec une checklist répétable. La complexité ne scale pas ; les habitudes opérationnelles, oui.

13) Étapes pratiques suivantes

1. Choisissez votre politique de tunnel : split tunnel pour la plupart des utilisateurs ; full tunnel seulement pour les rôles nécessitant vraiment un contrôle centralisé d’egress.
2. Standardisez un template de config client : incluez DNS et keepalive par défaut ; gardez AllowedIPs explicites et documentés.
3. Créez un « test connu‑bon » : un ping sur une IP interne, un test de service TCP, une résolution de nom interne. Utilisez ces trois tests sur Windows/macOS/Linux.
4. Adoptez le playbook de diagnostic rapide : handshake → routage → atteignabilité IP → DNS → MTU → forwarding côté serveur.
5. Rédigez ce que « fonctionner » signifie : sous‑réseaux accessibles, comportement DNS attendu, et si l’internet doit être tunnelisé. Cela prévient le prochain incident causé par des suppositions.

Si vous faites tout cela, WireGuard devient ce qu’il promet : un outil petit et net qui vous laisse tranquille — jusqu’au moment où vous en avez besoin, et là il se comporte de façon prévisible. Prévisible est le meilleur compliment qu’un système de production puisse recevoir.