4
Verständnisfrage resolv.conf vs. NetworkManager bei Bookworm mit Wireguard
Hallo,
mich interessiert der Zusammenhang von resolv.conf <--> Network Manager im PiOS Bookworm. Bookworm nutzt den NetworkManager, doch möchte Wireguard Resolv.conf.
Zum Hintergrund:
Ich habe einen Wireguard Client auf einem RaspberryPi (Bookworm) aufgesetzt. In der Config habe ich einen DNS Server eingetragen. Beim ersten Start über wg-quick dann diese Meldung:
Ich habe dann kurzerhand resolvconf installiert. Dazu wird auch in allen Foren geraten. Wireguard ließ sich danach starten. Nun würde ich gerne verstehen:
In der resolv.conf sind nun zwei DNS Server eingetragen und es wird auf systemd-resolved verwiesen. systemd-resolved ist jedoch nicht installiert.
In der ursprünglichen resolv.conf wird auf den NetworkManager verwiesen und es sind dort keine DNS Server enthalten.
NetworkManager:
Für mich stellt sich nun die Frage:
- Welcher Service ist führend?
- Welcher Dienst hat die die DNS Server in die resolv.conf eingetragen?
- Wie hätte man es alternativ ohne Installation lösen können?
- Sind Konflikte zu erwarten?
mich interessiert der Zusammenhang von resolv.conf <--> Network Manager im PiOS Bookworm. Bookworm nutzt den NetworkManager, doch möchte Wireguard Resolv.conf.
Zum Hintergrund:
Ich habe einen Wireguard Client auf einem RaspberryPi (Bookworm) aufgesetzt. In der Config habe ich einen DNS Server eingetragen. Beim ersten Start über wg-quick dann diese Meldung:
[#] resolvconf -a wg0 -m 0 -x
/usr/bin/wg-quick: line 32: resolvconf: command not foundIch habe dann kurzerhand resolvconf installiert. Dazu wird auch in allen Foren geraten. Wireguard ließ sich danach starten. Nun würde ich gerne verstehen:
In der resolv.conf sind nun zwei DNS Server eingetragen und es wird auf systemd-resolved verwiesen. systemd-resolved ist jedoch nicht installiert.
In der ursprünglichen resolv.conf wird auf den NetworkManager verwiesen und es sind dort keine DNS Server enthalten.
cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "resolvectl status" to see details about the actual nameservers.
nameserver 192.168.178.1
nameserver fd00::dede:dede:dede:1234
nameserver 192.168.178.11
search fritz.boxresolvectl status
-bash: resolvectl: command not foundNetworkManager:
ipv4.dns: --
ipv4.dns-search: --
ipv4.dns-options: --
ipv4.dns-priority: 0Für mich stellt sich nun die Frage:
- Welcher Service ist führend?
- Welcher Dienst hat die die DNS Server in die resolv.conf eingetragen?
- Wie hätte man es alternativ ohne Installation lösen können?
- Sind Konflikte zu erwarten?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 51694871436
Url: https://administrator.de/contentid/51694871436
Printed on: May 6, 2024 at 13:05 o'clock
4 Comments
Latest comment
Die Namensauflösung ist sehr alt im Linux und daher durch die Jahre sehr modular geworden.
Für Namensauflösung ist das erste was angeschaut wird ist "/etc/nsswitch.conf" und dort der Eintrag "hosts".
Dann wird von links nach rechts durchgegangen, bis der Name aufgelöst wurde.
Meist steht das sowas wie:
Damit wird zuerst die Datei "/etc/hosts" zum Auflösen verwendet.
Wenn das nichts findet, wird "dns" benutzt, was immer zur Datei "/etc/resolv.conf" führt.
Die wird von "oben" nach "unten" gelesen und der erste Treffer ist entscheidend.
Es gibt nun verschiedene Akteure, welche die "resolv.conf" schreiben.
Die Liste ist sicher nicht vollständig.
Jeder obige hat eigene Konfigurationskonzepte.
Wenn man die vermischt, geht es meistens schief.
Du kannst "/etc/resolv.conf" auch von Hand ändern, die Aenderungen sind dann aber meist nicht von Dauer.
Entschiede dich für eines und dann musst du das Manual lesen.
Für Namensauflösung ist das erste was angeschaut wird ist "/etc/nsswitch.conf" und dort der Eintrag "hosts".
Dann wird von links nach rechts durchgegangen, bis der Name aufgelöst wurde.
Meist steht das sowas wie:
hosts: files dnsWenn das nichts findet, wird "dns" benutzt, was immer zur Datei "/etc/resolv.conf" führt.
Die wird von "oben" nach "unten" gelesen und der erste Treffer ist entscheidend.
Es gibt nun verschiedene Akteure, welche die "resolv.conf" schreiben.
- netplan
- NetworkManager
- systemd-resolved (resolvectl)
- resolvconf (etwas veraltet und eher auf Systemen, die kein Systemd benutzen)
Die Liste ist sicher nicht vollständig.
Jeder obige hat eigene Konfigurationskonzepte.
Wenn man die vermischt, geht es meistens schief.
Du kannst "/etc/resolv.conf" auch von Hand ändern, die Aenderungen sind dann aber meist nicht von Dauer.
Entschiede dich für eines und dann musst du das Manual lesen.
@ITwissen Das hat mir im Verständnis sehr geholfen.
Etwas unglücklich ist, dass, wenn man eigentlich Network Manager nutzt, Wireguard damit nicht klarkommt und nach der Installation von resolvconf verlangt, in der resolv.conf nun auf resolved verwiesen wird, was aber nicht installiert ist...
Ich würde es jedoch so verstehen, dass resolv.conf weiterhin vom Network Manager verwaltet wird und nur (wie oben zu sehen) wenn wg0 startet, dieses über resolvconf in der resolv.conf zusätzlich die DNS nameserver hinterlegt.
Etwas unglücklich ist, dass, wenn man eigentlich Network Manager nutzt, Wireguard damit nicht klarkommt und nach der Installation von resolvconf verlangt, in der resolv.conf nun auf resolved verwiesen wird, was aber nicht installiert ist...
Ich würde es jedoch so verstehen, dass resolv.conf weiterhin vom Network Manager verwaltet wird und nur (wie oben zu sehen) wenn wg0 startet, dieses über resolvconf in der resolv.conf zusätzlich die DNS nameserver hinterlegt.
Wenn du eh schon den NetworkManager nutzt dann einfach die Wireguard Verbindung dort einrichten, der supported das von Haus aus 
, wg-quick ist dann überflüssig und NetworkManager regelt den DNS dann auch vernünftig.
https://blogs.gnome.org/thaller/2019/03/15/wireguard-in-networkmanager/
Zum manuellen auf und Abbauen der Verbindung reicht ein
Wenn man schon den NetworkManager nutzt sollte man auch am besten alles darüber abwickeln, denn er krallt sich die entsprechenden Hooks für DNS etc. und leitet auf sich selbst als primäre DNS Instanz um, wenn man da mit manuellem auf und Abbau von Verbindungen agiert kommt da unter Umständen einiges durcheinander.
Wenn man zwingend manuell Dinge abfackeln will NetworkManager besser für einen konsistenten Zustand solange temporär deaktivieren.
Gruß Katrin.
, wg-quick ist dann überflüssig und NetworkManager regelt den DNS dann auch vernünftig.nmcli connection import type wireguard file "/path/to/connection.conf" Zum manuellen auf und Abbauen der Verbindung reicht ein
# verbinden
nmcli conn up DeineVerbindung
# trennen
nmcli conn down DeineVerbindungWenn man schon den NetworkManager nutzt sollte man auch am besten alles darüber abwickeln, denn er krallt sich die entsprechenden Hooks für DNS etc. und leitet auf sich selbst als primäre DNS Instanz um, wenn man da mit manuellem auf und Abbau von Verbindungen agiert kommt da unter Umständen einiges durcheinander.
Wenn man zwingend manuell Dinge abfackeln will NetworkManager besser für einen konsistenten Zustand solange temporär deaktivieren.
Gruß Katrin.
Das kommt natürlich drauf an, wie du das alles installierst (hast du nicht beschrieben).
Wenn es die offiziellen Debian Pakete sind, kann man dort einen Bug-Report abgeben.
Wenn es eine andere Anleitung oder Quelle ist, kann man dort sein Problem schildern und es wird vielleicht verbessert.
Wenn du es nur hier schreibst, bekommst du ein Workaround, aber die Entwickler wissen nichts davon und werden es dementsprechend auch nicht ändern.
Wenn es die offiziellen Debian Pakete sind, kann man dort einen Bug-Report abgeben.
Wenn es eine andere Anleitung oder Quelle ist, kann man dort sein Problem schildern und es wird vielleicht verbessert.
Wenn du es nur hier schreibst, bekommst du ein Workaround, aber die Entwickler wissen nichts davon und werden es dementsprechend auch nicht ändern.
