wg-quick: line 32: resolvconf: command not found (WireGuard-Lösung)

Die Konfiguration ist korrekt, die Schlüssel passen, und wg-quick up wg0 bricht ab mit:

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

Die Meldung benennt das eigentliche Problem genau, und fast niemand liest sie so. Sie sagt nicht, dass deine DNS-Einstellung falsch ist. Sie sagt, dass ein Programm namens resolvconf sie anwenden sollte und auf diesem Rechner nicht existiert.

Was wg-quick mit einer DNS-Zeile tatsächlich macht

wg-quick ist ein Shell-Skript, das den Befehl wg umhüllt. Wenn deine Konfiguration Folgendes enthält:

[Interface]
DNS = 10.10.0.1

schreibt es /etc/resolv.conf nicht selbst. Es ruft das externe Programm resolvconf auf und überlässt ihm die Koordination, weil auf einem Linux-System mehrere Komponenten gleichzeitig den Resolver steuern wollen können und direktes Überschreiben der Datei genau der Weg ist, auf dem sie sich in die Quere kommen.

Auf einer Desktop-Distribution ist dieses Programm vorhanden. Auf einem minimalen Server-Image, einer Cloud-Instanz oder in einem Container meist nicht, und das Skript scheitert genau an dieser Zeile.

Lösung 1: eine resolvconf-Implementierung installieren

Die direkte Antwort, wenn sonst nichts deinen Resolver verwaltet:

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

Danach funktioniert wg-quick up wg0 unverändert.

⛔ Tu das nicht, wenn systemd-resolved läuft. Du hättest dann zwei Programme, die Hoheit über eine Datei beanspruchen, und das Symptom ist schlimmer als der Fehler, mit dem du angefangen hast: DNS, das funktioniert, bis irgendetwas neu startet, und dann nicht mehr. Prüfe vorher:

systemctl is-active systemd-resolved

Lösung 2: systemd-resolved nutzen, das du vielleicht schon hast

Antwortet dieser Befehl mit active, hat der Rechner bereits einen Resolver-Verwalter, und wg-quick kann über eine Kompatibilitätsschicht mit ihm sprechen. Unter Debian und Ubuntu:

apt install systemd-resolvconf

Das liefert einen resolvconf-Befehl, der an systemd-resolved weiterleitet, statt eine zweite unabhängige Implementierung zu sein. Prüfe anschließend, ob die Datei so verwaltet wird, wie du es erwartest:

ls -l /etc/resolv.conf

Ein Symlink nach /run/systemd/resolve/ heißt, dass systemd-resolved sie verwaltet. Eine normale Datei heißt, dass etwas anderes sie verwaltet, und das solltest du klären, bevor du einen Tunnel dazunimmst.

Lösung 3: DNS selbst per PostUp setzen

Wenn du lieber nichts installieren willst, ersetze die DNS-Zeile durch Befehle, die die Arbeit direkt erledigen:

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

Das ist grob, und es funktioniert, aber zwei Grenzen gehören dazugesagt. Es überschreibt, was auch immer in der Datei stand, also wird alles andere, was den Resolver verwaltet, dir widersprechen. Und die PostDown-Zeile muss etwas Sinnvolles wiederherstellen, denn ein Tunnel, der beim Abbau eine leere resolv.conf hinterlässt, nimmt DNS mit.

Für einen Container oder einen VPS mit nur einer Aufgabe, auf dem nichts anderes den Resolver anfasst, ist das eine völlig vernünftige Wahl.

Lösung 4: entscheiden, dass du es nicht brauchst

Lösche die DNS-Zeile, und der Tunnel kommt sofort hoch.

Das ist in genau einem Fall die richtige Antwort: wenn der Tunnel dazu dient, ein Netz zu erreichen, nicht deine Namensauflösungen zu verbergen. Eine Site-to-Site-Verbindung zwischen zwei Servern hat keinen Grund, den Resolver eines der beiden Rechner zu ändern.

⛔ Falsch ist es, wenn der Tunnel der Privatsphäre dient. Ohne Tunnel-DNS geht jeder Name, den du auflöst, weiterhin im Klartext an deinen bisherigen Resolver, und dass der Verkehr danach verschlüsselt ist, macht das nicht rückgängig. Wie dieses Leck funktioniert, steht in DNS-Lecks verhindern.

Tritt dieser Fehler auf einem Linux-Laptop mit einer .conf von einem kommerziellen VPN auf? Dann musst du dich gar nicht mit wg-quick herumschlagen. Die offizielle Linux-App von Proton VPN (Debian, Ubuntu, Fedora, Arch) verwaltet den Tunnel über NetworkManager statt über wg-quick, es ist also kein resolvconf beteiligt, und sie schickt DNS an die eigenen Resolver, mit Kill Switch in jedem Tarif einschließlich Free (Affiliate-Link). Behalte die Lösungen oben, wenn der Server dir gehört: Die App ersetzt nur die Client-Seite eines kommerziellen Dienstes.

Die Wahl zwischen ihnen

systemd-resolved bereits aktiv -> systemd-resolvconf (Lösung 2) nichts verwaltet den Resolver -> openresolv (Lösung 1) Container, VPS mit einer Aufgabe -> PostUp (Lösung 3) Tunnel zwischen zwei Servern -> DNS-Zeile entfernen (Lösung 4)

Wenn du nur deine internen Domains über den Tunnel auflösen und den Rest in Ruhe lassen willst, ist das wieder ein anderes Setup: WireGuard Split DNS.

Und wenn der Tunnel jetzt hochkommt, aber nichts lädt, war DNS nicht das Problem: Siehe MTU für Seiten, die hängen, und Handshake-Fehlerbehebung, wenn wg show überhaupt keinen Handshake meldet.