NetworkManager oder wg-quick: Wem gehören deine WireGuard-Routen?

Du änderst AllowedIPs in der WireGuard-Datei, startest den Tunnel neu, und die Routingtabelle sieht genau aus wie zuvor. Die übliche Reaktion ist, die störende Route zu löschen und weiterzumachen, was funktioniert, bis die nächste Wiederverbindung sie zurücksetzt. Die Datei, die du bearbeitet hast, ist nicht zwangsläufig das Objekt, das den Zustand erzeugt hat, den du siehst. Zwei Manager können dasselbe Protokoll auf einer Maschine betreiben, und nur einer von ihnen besitzt die Schnittstelle zu jedem Zeitpunkt.

Mythos: Auf der Maschine gibt es nur eine WireGuard-Konfiguration

wg-quick liest eine Datei unter /etc/wireguard/ und baut die Schnittstelle auf, wenn du sie hochfährst. NetworkManager speichert ein Verbindungsprofil im eigenen Keyfile-Format und rendert es bei der Aktivierung, und der Import einer wg-quick-Datei kopiert die Werte in dieses Profil, statt darauf zu verweisen. Das Original danach zu bearbeiten ändert nichts, weil das Profil es nicht mehr liest. Dieselbe Liste von Peers und Schlüsseln kann daher zweimal existieren, wobei die zweite Kopie gilt.

Ein Merkmal, das man sich merken sollte: Änderungen, die einen Neustart überstehen, aber keinen erneuten Import, stammen aus einem Speicher, und Änderungen, die beim Neustart verschwinden, aus dem anderen.

Ein praktisches Beispiel macht die Trennung offensichtlich. Vergleiche nmcli connection show mit systemctl status wg-quick@wg0, und prüfe dann, an welcher Schnittstelle die Routen tatsächlich hängen. Ist der Dienst tot und die Schnittstelle oben, leistet das Profil die Arbeit, egal was die Datei sagt.

Mythos: Die Routingregeln sind Teil von WireGuard

Das WireGuard-Gerät im Kernel kennt Peers und Schlüssel und weiß nichts über Policy-Routing. Welche ip rule -Einträge und zusätzlichen Tabellen du auch siehst, sie wurden von dem Werkzeug installiert, das die Schnittstelle hochgefahren hat. wg-quick kann ein fwmark und eine eigene Tabelle samt Regeln darauf hinzufügen, während NetworkManager Routen über die eigenen ipv4-Einstellungen installiert und DNS dem Resolver-Backend überlässt, das das System verwendet. Derselbe Tunnel, andere Nebenwirkungen.

Lies ip rule und ip route show table all , bevor du etwas änderst, und notiere, in welcher Tabelle welche Route liegt. Eine Tabellennummer, die du nicht konfiguriert hast, ist ein starker Hinweis auf das Werkzeug, das sie angelegt hat.

Mythos: Die Route zu löschen ist eine Lösung

Eine zur Laufzeit gelöschte Route ist eine Route, die der Eigentümer bei der nächsten Aktivierung wieder installiert, und die Aktivierung kann ohne dich geschehen: ein Laptop, der aufwacht, ein Link-Flap, ein Dienstneustart oder ein Autoconnect von NetworkManager. Deshalb kommt dieselbe Route zurück, und deshalb fühlt sich der Workaround unzuverlässig statt falsch an. Identifiziere zuerst den Manager und ändere dann die Eingabe, die dieser Manager tatsächlich liest.

Neuverbinden und Neustarten des zuständigen Dienstes ist der Test, der eine echte Lösung von einer sauber aussehenden trennt.

Wähle einen Eigentümer und entferne den anderen

Wähle den Manager, den dein Deployment unterstützt, und deaktiviere dann die konkurrierende Aktivierung über ihre dokumentierte Steuerung, statt zu hoffen, dass sie untätig bleibt. Ein maskierter wg-quick-Dienst oder ein gelöschtes NetworkManager-Profil ist explizit; beides aktiviert zu lassen und gegeneinander laufen zu lassen nicht. Erhalte den funktionierenden Zugang, bevor du etwas deaktivierst, denn die Schnittstelle, die deine Remote-Sitzung trägt, könnte die sein, die du gerade entfernst.

Prüfe nach der Änderung den eingeschlossenen und ausgeschlossenen Verkehr, dann DNS, und starte dann einmal neu. Übersteht der Zustand einen Neustart mit einem einzigen Manager, hast du einen Eigentümer statt eines Zufalls.

Die allgemeine Regel lohnt sich über WireGuard hinaus: Wenn eine Einstellung immer wieder zurückkommt, höre auf, das Ergebnis zu löschen, und finde den Prozess, der es immer wieder erzeugt.