wg-quick: line 32: resolvconf: command not found (correctif WireGuard)

La config est correcte, les clés correspondent, et wg-quick up wg0 s'arrête sur :

/usr/bin/wg-quick: line 32: resolvconf: command not found

Le message nomme exactement le vrai problème, et presque personne ne le lit ainsi. Il ne dit pas que votre réglage DNS est faux. Il dit qu'un programme appelé resolvconf était censé l'appliquer et qu'il n'existe pas sur cette machine.

Ce que wg-quick fait réellement d'une ligne DNS

wg-quick est un script shell qui enveloppe la commande wg. Quand votre config contient :

[Interface]
DNS = 10.10.0.1

il n'écrit pas /etc/resolv.conf lui-même. Il lance le binaire externe resolvconf et le laisse arbitrer, parce que plusieurs composants d'un système Linux peuvent vouloir contrôler le résolveur en même temps, et écraser le fichier directement, c'est précisément comme ça qu'ils se battent.

Sur une distribution de bureau, ce programme est présent. Sur une image serveur minimale, une instance cloud ou un conteneur, il ne l'est généralement pas, et le script échoue exactement à cette ligne.

Un rayon de supermarché grillagé presque vide photographié de près, avec une seule boîte en carton de gnocchis ouverte restée dessus, le reste de l'étagère vide

Solution 1 : installer une implémentation de resolvconf

La réponse directe, quand rien d'autre ne gère votre résolveur :

apt install openresolv        # Debian, Ubuntu
pacman -S openresolv          # Arch

Ensuite, wg-quick up wg0 fonctionne sans rien changer.

⛔ Ne faites pas ça si systemd-resolved tourne. Vous auriez alors deux programmes revendiquant l'autorité sur un seul fichier, et le symptôme est pire que l'erreur de départ : un DNS qui fonctionne jusqu'à ce que quelque chose redémarre, puis plus du tout. Vérifiez d'abord :

systemctl is-active systemd-resolved

Solution 2 : utiliser systemd-resolved, que vous avez peut-être déjà

Si cette commande répond active, la machine a déjà un gestionnaire de résolveur et wg-quick peut lui parler via une couche de compatibilité. Sur Debian et Ubuntu :

apt install systemd-resolvconf

Ce paquet fournit une commande resolvconf qui relaie vers systemd-resolved, plutôt qu'une seconde implémentation indépendante. Vérifiez ensuite que le fichier est géré comme vous l'attendez :

ls -l /etc/resolv.conf

Un lien symbolique vers /run/systemd/resolve/ signifie que systemd-resolved le possède. Un fichier ordinaire signifie que c'est autre chose, et cela vaut la peine d'être tiré au clair avant d'ajouter un tunnel par-dessus.

Solution 3 : régler le DNS vous-même avec PostUp

Si vous préférez ne rien installer, remplacez la ligne DNS par des commandes qui font le travail directement :

[Interface]
PostUp = printf 'nameserver 10.10.0.1\n' > /etc/resolv.conf
PostDown = printf 'nameserver 1.1.1.1\n' > /etc/resolv.conf

C'est brutal et ça marche, mais ses deux limites doivent être dites. Cela écrase le contenu du fichier, donc tout autre composant qui gère le résolveur sera en désaccord avec vous. Et la ligne PostDown doit restaurer quelque chose de cohérent, car un tunnel qui tombe en laissant un resolv.conf vide emporte le DNS avec lui.

Pour un conteneur ou un VPS à usage unique où rien d'autre ne touche au résolveur, c'est un choix tout à fait raisonnable.

Solution 4 : décider que vous n'en avez pas besoin

Supprimez la ligne DNS et le tunnel monte immédiatement.

C'est la bonne réponse dans un seul cas : quand le tunnel sert à atteindre un réseau, pas à masquer vos résolutions DNS. Un lien site à site entre deux serveurs n'a aucune raison de modifier le résolveur de l'une ou l'autre machine.

⛔ C'est la mauvaise réponse quand le tunnel sert à la confidentialité. Sans DNS via le tunnel, chaque nom que vous résolvez part toujours en clair vers votre résolveur précédent, et le chiffrement du trafic qui suit n'y change rien. Le mécanisme de cette fuite est détaillé dans la prévention des fuites DNS.

Vous tombez sur cette erreur sur un portable Linux avec un .conf téléchargé chez un VPN commercial ? Inutile de vous battre avec wg-quick. L'application Linux officielle de Proton VPN (Debian, Ubuntu, Fedora, Arch) gère le tunnel via NetworkManager plutôt que wg-quick, donc sans resolvconf, et envoie le DNS vers ses propres résolveurs, avec un kill switch sur toutes les formules, Free comprise (lien affilié). Gardez les solutions ci-dessus quand le serveur vous appartient : l'application ne remplace que le côté client d'un service commercial.

Choisir entre elles

systemd-resolved déjà actif -> systemd-resolvconf (solution 2) rien ne gère le résolveur -> openresolv (solution 1) conteneur, VPS à usage unique -> PostUp (solution 3) tunnel entre deux serveurs -> supprimer la ligne DNS (solution 4)

Si vous voulez seulement que vos domaines internes soient résolus via le tunnel et le reste laissé tel quel, c'est encore une autre configuration : le split DNS WireGuard.

Et si le tunnel monte maintenant mais que rien ne charge, le DNS n'était pas le problème : voyez le MTU pour les pages qui restent bloquées, et le dépannage du handshake si wg show n'indique aucun handshake.

★ Datacenter Nuremberg GDPR · ✓ IPv4 dédiée incluse · port 200 Mbit/s

Héberge ton VPN sur ton propre VPS → ContaboAccès root complet · IPv4 publique · choisis ta région→

Questions fréquentes

Pourquoi wg-quick affiche resolvconf: command not found ?

Parce que wg-quick ne configure pas le DNS lui-même. Quand la config contient une ligne DNS, il lance la commande externe resolvconf pour l'appliquer, et sur une image serveur minimale ce binaire n'est pas installé. La configuration du tunnel est correcte ; c'est un programme auxiliaire qui manque.

Est-ce que je peux simplement supprimer la ligne DNS ?

Oui, et le tunnel montera immédiatement. La conséquence, c'est que les résolutions de noms continuent de partir vers votre résolveur existant au lieu de passer par le tunnel, ce qui constitue une fuite DNS si le but du tunnel était la confidentialité. C'est la bonne réponse uniquement si vous n'aviez pas besoin du DNS via le tunnel.

Quel paquet fournit resolvconf ?

Sur Debian et Ubuntu, c'est openresolv ou resolvconf, et sur Arch c'est openresolv. Sur un système qui fait déjà tourner systemd-resolved, installer une autre implémentation de resolvconf peut créer deux gestionnaires pour un seul fichier, ce qui est pire que l'erreur de départ.

Quelle est la différence entre resolvconf et systemd-resolved ici ?

Ils résolvent le même problème de manières incompatibles. resolvconf est un petit programme qui arbitre les écritures dans /etc/resolv.conf ; systemd-resolved est un démon qui possède le fichier via un lien symbolique et se configure avec resolvectl. Prenez celui qui gère déjà votre système et n'installez pas l'autre.

Cette erreur signifie-t-elle que mon VPN n'est pas sécurisé ?

Non. L'erreur survient avant que l'interface soit entièrement configurée : soit le tunnel ne monte pas du tout, soit il monte sans le réglage DNS demandé. Le second cas mérite d'être connu, car le tunnel fonctionne et les résolutions DNS, elles, ne l'utilisent pas, sans rien signaler.