WireGuard ne parvient pas à créer son interface : noyau ou permissions ?

WireGuard ne parvient pas à créer son interface, il n’y a donc aucun périphérique à configurer, aucune clé à échanger et aucune poignée de main à déboguer. L’échec reste entièrement sur la machine locale, et le texte d’erreur indique quelle partie de la pile locale a refusé. Le lire correctement est plus rapide que de réinstaller la configuration du pair. Les couches sont séparables, et le message nomme celle qui a refusé.

L’erreur survient avant qu’un seul pair parle

Créer une interface est une seule requête netlink au noyau demandant un périphérique de type wireguard. Le noyau dispose ou non d’un pilote qui comprend ce type, et la réponse revient immédiatement. Aucun paquet ne quitte la machine pendant cette étape, et c’est pourquoi les adresses des points de terminaison et les clés du serveur ne peuvent pas être la cause.

Cet ordre compte pour le diagnostic. Si la commande n’a jamais créé de périphérique, le problème ne peut pas être une clé publique erronée ni un port UDP bloqué. Corrigez d’abord le chemin de création local et ne regardez vers l’extérieur qu’ensuite.

Quelle implémentation doit posséder le périphérique

Deux implémentations peuvent répondre à cette requête. Le module du noyau enregistre le type de périphérique wireguard, et une implémentation en espace utilisateur comme wireguard-go fournit la même interface par un mécanisme différent. Si le module est absent, le noyau rejette la requête avec une erreur de périphérique non pris en charge, et la solution est soit de charger le module, soit de pointer les outils vers l’implémentation en espace utilisateur.

Vérifiez ce qui est réellement présent avant de choisir entre elles. La première commande montre si le module est chargé et la seconde interroge le noyau directement :

lsmod | grep wireguard
ip link add wgtest0 type wireguard

La seconde commande est la plus petite reproduction possible : elle demande un périphérique et rien d’autre. Si elle échoue avec un message de type non pris en charge, la pièce manquante est l’implémentation et non votre fichier de configuration.

Privilèges et frontières du conteneur

Créer et configurer un périphérique réseau exige des privilèges, soit en root, soit avec la capacité d’administrer le réseau. Une session utilisateur ordinaire ne peut pas le faire, et cette restriction est la conception même et non un obstacle à contourner en lançant un installateur que vous n’avez pas examiné.

Dans un conteneur, la frontière double. Le conteneur a besoin d’accéder au périphérique de tunnel et de la capacité de le configurer, et les drapeaux qui l’accordent sont les mêmes que ceux qu’utilise un conteneur VPN sous Linux. Un invité restreint qui peut naviguer normalement sur le web ne peut toujours pas créer d’interface, car la navigation n’a pas besoin de cette capacité. Accordez la capacité au service qui en a besoin et non à chaque session de l’hôte.

Résolvez le conflit de noms, puis réessayez

Une interface qui existe déjà n’est pas automatiquement un reste. Un autre gestionnaire peut posséder le nom et l’utiliser en ce moment même, alors inspectez-la avant de supprimer quoi que ce soit :

ip link show wg0
sudo wg show wg0

Si le propriétaire est un service actif, configurez ce service au lieu de créer un second périphérique. Si elle est vraiment obsolète, supprimez-la au moyen de l’outil qui l’a créée, puis montez l’interface avec le client ou l’unité documentés afin que la configuration et le périphérique restent alignés.

Une fois la création réussie, l’échec suivant appartient à une étape ultérieure, et une unité qui signale un échec après l’existence du périphérique est un problème différent d’un périphérique qui n’a jamais été créé. Séparez les deux avant de changer à nouveau les permissions.