ip rule einen Reconnect mit systemd-networkd überleben lassen

Fügen Sie mit ip rule eine Policy-Regel hinzu, dann funktioniert sie, bis der Link verschwindet; an diesem Punkt ist sie einfach weg. Nichts ist laut gescheitert: Der Kernelzustand hat sich geändert, und kein Konfigurationseigentümer wusste, dass die Regel existieren sollte. Das ist der ganze Unterschied zwischen einer Regel, die überlebt, und einer, die es nicht tut. Auf einem Host mit systemd-networkd besteht die Lösung darin, der Regel einen Eigentümer zu geben, statt den Befehl nach jedem Reconnect erneut auszuführen.

Eine Regel existiert nur, wenn jemand sie besitzt

Kernel-Routing-Policy ist Zustand, nicht Konfiguration. Sie lebt im laufenden System, und alles, was die Schnittstelle abbaut, von der sie abhängt, kann sie mitnehmen. Ein Shell-Befehl ändert diesen Zustand und hinterlässt keine Aufzeichnung der Absicht.

Netzwerkmanager arbeiten umgekehrt: Sie lesen Konfiguration, wenden sie an und wenden sie erneut an, wenn ein Link-Event den vorherigen Zustand ungültig macht. Eine in ihrer Konfiguration deklarierte Regel wird neu erzeugt, während eine daneben hinzugefügte Regel ein fremdes Objekt ohne Eigentümer ist.

Diese Unterscheidung hat in networkd einen Namen, und es lohnt sich, ihn zu lesen, bevor Sie irgendetwas aktivieren. Fremde Regeln werden in neueren Versionen standardmäßig entfernt, was Leute überrascht, die erwartet hatten, dass ihre manuellen Einträge bestehen bleiben.

Lesen Sie die Version, bevor Sie einer Einstellung trauen

Das Eigentümerverhalten wird durch eine Einstellung in networkd.conf gesteuert, und diese Einstellung existiert in älteren systemd-Versionen nicht. Prüfen Sie die installierte Version, bevor Sie darauf aufbauen, denn ein älterer Host verhält sich anders als die Dokumentation, die Sie lesen.

Zwei Werte zählen. Der eine entscheidet, ob Regeln entfernt werden, die nicht in der networkd-Konfiguration deklariert sind, der andere tut dasselbe für Routen. Beide betreffen den Besitz und nicht den Inhalt der Policy, und beide wählen in aktuellen Versionen standardmäßig das strengere Verhalten. Schaltet man sie global ab, bleibt jede fremde Regel am Leben, was eine viel weiterreichende Entscheidung ist, als eine gewünschte VPN-Policy zu deklarieren.

systemctl --version | head -1
networkctl --version | head -1
grep -R "ManageForeign" /etc/systemd/ /usr/lib/systemd/ 2>/dev/null

Dieses grep sagt Ihnen, was lokal gesetzt ist und was der Herstellerstandard ist. Auch Abwesenheit ist Information, denn sie bedeutet, dass der kompilierte Standard gilt. Schreiben Sie den Standard in Ihre Notizen, damit die nächste Person ihn nicht neu entdecken muss.

Deklarieren Sie die Regel und die Tabelle, auf die sie zeigt

Eine Regel in einer .network-Datei benennt eine Tabelle, und mehr tut ein Name nicht. Sie erzeugt nicht die Routen in dieser Tabelle und prüft nicht, ob sie sinnvoll sind. Die Regel ohne die Routen zu deklarieren erzeugt eine Policy, die Verkehr zuordnet und ihn dann verwirft.

Deklarieren Sie die Routen in derselben Datei, mit erreichbaren nächsten Hops und der richtigen Tabelle. Behalten Sie die Priorität in der deklarierten Regel, damit sie in der geordneten Liste dort landet, wo Sie es erwarten. Eine Regel, die die falsche Tabelle früher als beabsichtigt erreicht, ändert mehr Verkehr als der Dienst, den Sie reparieren wollten. Lesen Sie das Fragment unten als Form und nicht als vollständige Datei, denn Schnittstelleneigentum und der Rest der Verbindung müssen weiterhin vorhanden sein.

[RoutingPolicyRule]
Family=ipv4
IPProtocol=tcp
SourcePort=443
Table=100
Priority=1000

[Route]
Destination=10.80.0.0/24
Gateway=10.80.0.1
Table=100

Laden Sie dann neu und lesen Sie den Kernelzustand statt die Datei. Eine sauber geparste Konfiguration kann trotzdem eine Regel erzeugen, die Sie nicht beabsichtigt haben, und beide Sichten stimmen nur überein, wenn die Deklaration vollständig war.

Wählen Sie einen Eigentümer für die Schnittstelle

Zwei Manager auf einem Tunnel erzeugen einen Streit, der in beiden wie ein Fehler aussieht. Ein bestehendes wg-quick-Setup nach networkd zu importieren ist eine Migration und kein Zusatz, und beide laufen zu lassen lässt die Schnittstelle und ihre Regeln unter zwei Eigentümern.

Machen Sie die Migration in einem Durchgang: Stoppen Sie die alte Unit, deaktivieren Sie sie, deklarieren Sie Schnittstelle und Routen in networkd, laden Sie dann neu. Prüfen Sie, dass die alte Unit beim Booten nicht zurückkommen kann. Eine zurückgebliebene Unit, die nach einem Neustart wieder aktiv wird, überschreibt den Zustand, den Sie gerade deklariert haben. Behalten Sie die alte Konfigurationsdatei, bis die neue einen Reconnect überlebt hat, und ziehen Sie sie dann zurück.

Die Eigentümerschaft der Marke verdient dieselbe Sorgfalt: Wenn eine Regel auf eine Firewall-Marke passt, muss etwas diese Marke setzen. Eine Regel, die auf eine Marke verweist, die niemand setzt, ist tote Konfiguration, die gezielt aussieht.

Üben Sie die Lebenszyklusereignisse

Konfiguration ist nur so gut wie ihr Verhalten über Ereignisse hinweg. Nehmen Sie den Link herunter, bringen Sie ihn hoch, starten Sie den Dienst neu und erneuern Sie die Adresse. Lesen Sie nach jedem davon die Regelliste und den Tabelleninhalt.

sudo networkctl reload
ip rule show
ip route show table 100
sudo systemctl restart systemd-networkd

Das beabsichtigte Ergebnis ist dieselbe besessene Policy, neu erzeugt, und veralteter Zustand, zurückgezogen, was haltbarer ist, als nach jedem Reconnect eine Shell-Regel erneut hinzuzufügen. Behalten Sie eine Zeile im Änderungsprotokoll, die die Datei nennt, der die Regel gehört, und die Version, die sie unterstützt. Dann kann der nächste Ingenieur die Policy finden, ohne eine Shell-Historie zu durchsuchen. Eine Regel, die niemand besitzt, ist eine Regel, die wieder verloren geht.