Verhalten von systemd-networkd bei Änderung an Wireguard-Interfaces

[bluestar]

Aus eigener (leidvoller) Erfahrung möchte ich zu systemd-networkd anmerken, das Änderungen an Wireguard Interfaces bei mir mit Bullseye Probleme machen.

So werden Endpoint-Änderungen nicht aktualisiert, die muss ich über wg dann auf der Kommandozeile händisch nachziehen.

Edit JTH: Abgetrennt aus „systemd-networkd vs. interfaces“.

[mat6937]

So werden Endpoint-Änderungen nicht aktualisiert, die muss ich über wg dann auf der Kommandozeile händisch nachziehen.

Statt händisch könntest Du auch das Script reresolve-dns.sh, mit einer timer-unit oder mit einem cronjob oder gleichwertig, benutzen.

[bluestar]

Statt händisch könntest Du auch das Script reresolve-dns.sh, mit einer timer-unit oder mit einem cronjob oder gleichwertig, benutzen.

Da meine Tunnel ohnehin auf festen IPs basieren, entfällt die Option. Die Umschaltung von IPv4 auf IPv6 als Transportprotokoll hat mich hier einiges an Nerven gekostet.

[mat6937]

Da meine Tunnel ohnehin auf festen IPs basieren, ...

Dann verstehe ich nicht was Du mit:

So werden Endpoint-Änderungen nicht aktualisiert, ...

meinst?
Was meinst Du mit:

über wg dann auf der Kommandozeile händisch nachziehen.

? Wie ziehst Du "händisch" nach?
Wenn ich in einer config-Datei von systemd-networkd eine Änderung mache, führe ich deamon-reload und ein restart der service-unit aus und danach ist die Änderung wirksam (auch mit bullseye).

[bluestar]

Das funktioniert bei mir auch alles problemlos, lediglich Änderungen an Endpoint Definitionen von Wireguard Devices übernimmt systemd-networkd schlicht nicht.

Das Problem ist aber auch bekannt: https://github.com/systemd/systemd/issues/9627

[mat6937]

..., lediglich Änderungen an Endpoint Definitionen von Wireguard Devices übernimmt systemd-networkd schlicht nicht.

Ich denke, das ist so gewollt, denn lt. der manpage von networkctl für reload (z. B. systemd version 247):

Reload .netdev and .network files. If a new .netdev file is found, then the corresponding netdev is
created. Note that even if an existing .netdev is modified or removed, systemd-networkd does not update or
remove the netdev. If a new, modified or removed .network file is found, then all interfaces which match
the file are reconfigured.

Teste mal, wenn Du den Inhalt der alten .netdev-Datei in eine neue .netdev-Datei verschiebst bzw. ergänzt/änderst und danach die alte .netdev-Datei löscht.

[bluestar]

Teste mal, wenn Du den Inhalt der alten .netdev-Datei in eine neue .netdev-Datei verschiebst bzw. ergänzt/änderst und danach die alte .netdev-Datei löscht.

Das hab ich alles schon durchprobiert, ohne Erfolg.

Für mich liegt die Ursache einfach im Zusammenspiel mit Wireguard, wenn ich ein Peer bearbeite, dann muss ich die .netdev Datei bearbeiten und es gibt aktuelle keine Möglichkeit mit systemd diese Änderungen durch reload zu übernehmen.

Für mich ist das eine Schwäche in der Wireguard-Implementation von systemd.

[mat6937]

Das hab ich alles schon durchprobiert, ohne Erfolg.

OK, dann rein interessehalber, Du schreibst ja weiter oben u. a.:

So werden Endpoint-Änderungen nicht aktualisiert, die muss ich über wg dann auf der Kommandozeile händisch nachziehen.

Hast Du nur als Test (und nicht für den alltäglichen Gebrauch), statt mit wg auf der Kommandozeile "händisch nachziehen", sofort nach den Änderungen einen reboot von bullseye mal gemacht? Werden die Änderungen/Ergänzungen, nach dem reboot übernommen?

[bluestar]

Hast Du nur als Test (und nicht für den alltäglichen Gebrauch), statt mit wg auch der Kommandozeile "händisch nachziehen", sofort nach den Änderungen einen reboot von bullseye mal gemacht?

Ja das funktioniert natürlich.

Für einen Wireguard VPN Server ist das halt sehr unschön, ich werfe ja nicht alle Roadwarrior-User aus dem VPN, nur weil bei einem festen Site-2-Site Tunnel der Endpoint aktiv geändert werden muss.

[mat6937]

Das hab ich alles schon durchprobiert, ohne Erfolg.

Hmm, ... d. h., wenn man eine bereits existierende .netdev-Datei mit z. B. mv umbenennt/verschiebt oder mit rm löscht und eine _neue_ .netdev-Datei erstellt, wird kein "richtiger" reload gemacht.

Reload .netdev and .network files. If a new .netdev file is found, then the corresponding netdev is
created. Note that even if an existing .netdev is modified or removed, systemd-networkd does not update or
remove the netdev.

Mit "a new .netdev file" ist dann gemeint, dass es vorher gar keine .netdev-Datei, jemals gegeben hat? Das passt doch irgendwie nicht zum reload, oder?

[bluestar]

Mit "a new .netdev file" ist dann gemeint, dass es vorher gar keine .netdev-Datei, jemals gegeben hat? Das passt doch irgendwie nicht zum reload, oder?

Richtig, es heißt ja auch das Löschen einer .netdev Datei löscht das Interface nicht.
Was ja auch blöd ist, wenn du ein VLAN rückbaust, dann kann ein Neustart ja nicht die systemd-Lösung sein oder hat Poettering heimlich den Neustartwahnsinn aus einem anderem OS für cool befunfen und ihn nachgebaut?

[JTH]

Richtig, es heißt ja auch das Löschen einer .netdev Datei löscht das Interface nicht.

Zum Löschen eines „virtual netdevs“ gibt es anscheinend das explizite

Code: Alles auswählen

networkctl delete DEVICE

Kenne mich mit Wireguard nicht aus, wäre das Kommando hier anwendbar?

[bluestar]

Kenne mich mit Wireguard nicht aus, wäre das Kommando hier anwendbar?

Dann kille ich halt ALLE bestehenden Verbindungen, das ist nicht so wirklich praktisch.