WireGuard sous Linux : vérifier le tunnel, les routes et le DNS

Un client WireGuard peut afficher une interface wg0 active alors que vos paquets continuent de sortir par la connexion habituelle. Le cas arrive souvent après l’import d’un fichier de configuration sur un poste Debian ou Ubuntu.

Avant de modifier le client, vérifiez l’interface, l’échange avec le pair et la route réellement choisie. Ce contrôle indique si le tunnel transporte tout le trafic ou seulement un réseau interne.

Distinguer un tunnel déjà actif d’un client à importer

Gardez une console locale ou une seconde session SSH ouverte si le fichier WireGuard contient une route par défaut. Une ligne AllowedIPs = 0.0.0.0/0 peut faire passer le trafic IPv4 dans le tunnel quand vous lancez wg-quick. Avec ::/0, le même principe s’applique à IPv6.

Commencez par regarder si wg0 existe déjà. Si l’interface est présente, ne remplacez pas son fichier et ne relancez pas wg-quick up. Passez directement aux commandes wg show et ip route get plus bas.

ip link show wg0
sudo wg show wg0

Si wg0 est absent, vérifiez le nom de l’interface et les droits du fichier fourni par votre administrateur ou votre fournisseur. Ne copiez jamais une clé privée dans un ticket, un dépôt Git ou une capture d’écran.

if sudo test -e /etc/wireguard/wg0.conf; then
  sudo cp -a /etc/wireguard/wg0.conf /etc/wireguard/wg0.conf.bak && sudo install -m 600 /chemin/client.conf /etc/wireguard/wg0.conf
else
  sudo install -m 600 /chemin/client.conf /etc/wireguard/wg0.conf
fi
sudo grep -E '^(Address|DNS|Endpoint|AllowedIPs)' /etc/wireguard/wg0.conf

La commande grep relit les paramètres de réseau sans afficher les clés. Vérifiez surtout AllowedIPs. Une plage comme 10.44.0.0/24 vise habituellement le réseau distant. Une route 0.0.0.0/0 demande un contrôle plus prudent si vous êtes connecté au serveur par SSH.

Si le fichier doit remplacer une configuration existante, conservez l’ancien sous un nom hors de /etc/wireguard/ ou dans votre sauvegarde d’administration. Je choisirais de tester d’abord depuis la console d’une VM ou d’un poste, plutôt que de changer la route par défaut d’un serveur distant sans accès de secours.

Monter WireGuard et lire l’échange avec le pair

Si wg0 était absent, activez maintenant l’interface avec wg-quick et gardez votre console ou votre seconde session ouverte jusqu’à la fin des contrôles. Une adresse attribuée à wg0 ne confirme pas que le pair distant répond.

sudo wg-quick up wg0
ip -brief address show wg0
sudo wg show wg0

Dans la sortie de wg show wg0, relevez latest handshake et les compteurs transfer. Un horodatage récent après une requête vers le réseau distant et des octets reçus indiquent que le pair répond. L’absence de handshake oriente plutôt vers l’endpoint, le port UDP, le pare-feu ou une clé qui ne correspond pas au pair attendu. La documentation WireGuard Quick Start décrit les commandes wg et wg-quick utilisées ici.

Pour suivre l’échange pendant un essai, vous pouvez relancer la commande suivante. Elle évite de modifier la configuration pendant le diagnostic.

watch -n 2 'sudo wg show wg0 latest-handshakes transfer'

Un ping peut aider si le serveur distant autorise ICMP, mais son absence de réponse ne suffit pas à condamner le tunnel. Préférez une requête vers un service que votre configuration est censée rendre accessible, par exemple un DNS interne ou une application d’administration.

Vérifier la route choisie avant de conclure

Utilisez ip route get pour connaître le périphérique que Linux choisirait pour envoyer un paquet vers la cible. La commande n’envoie aucun trafic.

ip route get 10.44.0.10
ip route get 1.1.1.1

Pour une ressource interne, la première sortie doit mentionner dev wg0 si 10.44.0.10 appartient aux réseaux déclarés dans AllowedIPs. La seconde indique si la sortie Internet passe aussi par wg0 ou conserve l’interface habituelle. Remplacez ces adresses de documentation par une cible réellement prévue dans votre réseau.

Si le VPN fournit un résolveur interne, testez-le directement seulement si son adresse est présente dans la documentation de votre tunnel et si Linux choisit bien wg0 pour l’atteindre. Installez dnsutils sur Debian ou Ubuntu si la commande dig est absente :

ip route get 10.44.0.53
sudo apt install dnsutils
dig @10.44.0.53 intranet.exemple.lan
sudo wg show wg0 latest-handshakes transfer

La première commande doit indiquer dev wg0. La requête DNS doit ensuite retourner une réponse attendue et faire progresser le trafic reçu ou envoyé. Si la route utilise wg0 mais que le handshake reste absent, le client envoie bien vers l’interface locale sans parvenir au pair distant.

Pour arrêter le test et restaurer les routes ajoutées par wg-quick, utilisez sudo wg-quick down wg0. Cette commande ne répare pas une route configurée ailleurs dans NetworkManager ou systemd-networkd. Elle retire seulement l’interface et les éléments que wg-quick a installés pour ce tunnel.

Un tunnel WireGuard valide se reconnaît donc avec trois preuves : une interface présente, un handshake récent et une route qui pointe vers wg0 pour la cible attendue. Les articles sur ip addr, la route IP et dig détaillent ces contrôles séparément quand le problème dépasse le seul tunnel.