IPv6-Policy-Routing, wenn zwei Uplinks sich fe80::1 teilen

Sie haben zwei Uplinks, und ip -6 route show zeigt auf beiden denselben nächsten Hop: default via fe80::1 dev uplink0 und default via fe80::1 dev uplink1. Das ist kein Konflikt doppelter Adressen, und den blanken nächsten Hop fe80::1 in eine Policy-Tabelle zu kopieren sagt dem Kernel nicht, welchen Link Sie meinten. Die eigentliche Frage ist enger, als das Symptom vermuten lässt: braucht die zweite Tabelle einen Link oder beide, und was hält diese Routen nach einem Neustart am Leben. Drei Bedingungen, der Reihe nach geprüft, klären das meiste.

Dasselbe fe80::1 sind zwei verschiedene Nachbarn

Link-Local-Adressen sind auf einen Link beschränkt, also ist fe80::1 keine zweimal gedruckte Adresse; es sind zwei Nachbarn, die zufällig ein Suffix teilen. Der Zonenindex ist die Art, wie ein Host sagt, welchen er meint, also sind fe80::1%uplink0 und fe80::1%uplink1 für den Kernel verschiedene Ziele, und dieses Suffix reist nie zu einem entfernten Router. RFC 4007 beschreibt das Zonenmodell dahinter, und deshalb muss eine Policy-Tabelle mit jedem Link-Local-Next-Hop ein Gerät mitführen.

Ein VPN-Konfigurationsgenerator, der eine numerische Zonen-ID von einem Host in eine Vorlage kopiert, behandelt lokalen Kontext so, als wäre er Teil der Adresse, und die Datei, die er schreibt, ist auf jeder Maschine falsch, deren Schnittstellennamen oder -indizes abweichen. Eine Policy-Tabelle führt auch nicht zwei Links zu einem zusammen: ein geroutetes VPN reicht Pakete zwischen Netzen weiter, aber es trägt die Link-Local-Identität eines entfernten Ethernet-Nachbarn nicht durch den Tunnel, also bleibt Link-Local-Verkehr auf seinem eigenen Link.

Entfernen Sie das Gerät, und die Route wird nicht mehr schreibbar. ip -6 route add default via fe80::1 table 200 kann das Gateway nicht auflösen, und iproute2 lehnt sie mit Error: Nexthop has invalid gateway. ab; fügen Sie dev uplink0 hinzu, und der Befehl gelingt, weil das Gerät den nächsten Hop an einen dieser beiden Nachbarn bindet. Was das Gerät Ihnen nicht sagen kann, ist, ob uplink0 der richtige Link für diese Tabelle ist, und eine von einem anderen Host kopierte Route bringt dessen Schnittstellennamen mit, und genau daraus entstehen die echten Fehler.

Bedingung eins: ein Link oder zwei in der Tabelle

Beginnen Sie damit, wozu der zweite Uplink da ist. Wenn beide Links denselben Verkehr tragen und einer ein Standby ist, sollte die alternative Tabelle beide Gateways mit unterschiedlichen Metriken halten: dieselben Ziele, ein bevorzugter Pfad, eine offensichtliche zweite Wahl. Wenn die Uplinks existieren, weil verschiedener Verkehr über verschiedene Anbieter hinausgehen muss, oder weil dies ein geteilter Tunnel ist, bei dem ein Teil des Verkehrs das VPN umgeht, während der Rest drinnen bleibt, gehören die zwei Links überhaupt nicht in eine Tabelle. Sie gehören in zwei Tabellen, gewählt durch eine Regel, und die Regel wählt die Tabelle, nicht den Tunnel: umgehender Verkehr wird markiert, bevor er geroutet wird, und die Markierung schickt ihn in die zweite Tabelle.

Im zweiten Fall entscheidet die Regel, wann eine Tabelle befragt wird, und die Route entscheidet, wohin das Paket danach geht:

ip -6 rule add fwmark 0x2 table 201
ip -6 route add default via fe80::1 dev uplink1 metric 100 table 201
ip -6 route add 2001:db8:100::/48 dev uplink1 metric 100 table 201
ip -6 route show table 201

Keines der beiden Objekte ersetzt das andere, und eine Tabelle, die nur eine Default-Route enthält, kann immer noch daran scheitern, ihr Gateway aufzulösen. Wenn ein Hinzufügen abgelehnt wird oder die Route vorhanden, aber unbrauchbar ist, legen Sie das verbundene Präfix für diese Schnittstelle in dieselbe Tabelle, oder markieren Sie den Hop onlink, wenn dieses Präfix woanders geroutet wird. Im Block oben steht 2001:db8:100::/48 für genau dieses verbundene Präfix auf uplink1, nicht für ein beliebiges Ziel. Die fwmark-Regel verbraucht nur eine Markierung, die etwas anderes setzen muss, aus einer nftables- oder iptables-Regel auf dem Weiterleitungspfad oder aus SO_MARK auf dem Socket, also passt ein kopierter Block ohne Markierungsquelle auf nichts.

Bedingung zwei: Metriken erkennen keinen toten Anbieter

Eine Metrik ist eine Präferenz unter vorhandenen Routen, kein Gesundheitscheck. Fällt der Träger weg, entfernt der Kernel die Routen auf diesem Gerät, und der zweite Default übernimmt. Bleibt das Kabel oben und stirbt der Anbieter dahinter, ändert sich in der Tabelle nichts: die bevorzugte Route ist installiert, der Nachbar ist auf Schicht 2 erreichbar, und Pakete laufen in ein schwarzes Loch. Wenn dieser Unterschied für Ihr Setup zählt, muss das Failover von etwas kommen, das den Pfad prüft und die Route entfernt, sei es ein Routing-Daemon oder ein kleines Skript, das den Eintrag löscht und neu installiert.

Prüfen Sie die Wahl, nachdem die Tabelle gebaut ist, und prüfen Sie sie so, wie der Kernel sie sehen wird. ip -6 route get 2001:db8:100::1 gibt die Route aus, die verwendet würde, einschließlich Gerät und gewählter Quelladresse, und respektiert Policy-Regeln. Eine Quelladresse, die zum falschen Uplink gehört, ist das übliche Zeichen dafür, dass eine Regel früher gepasst hat, als Sie erwartet hatten.

Bedingung drei: entscheiden Sie, wer die Persistenz besitzt

Eine mit ip -6 route add hinzugefügte Route überlebt bis zum Neustart oder bis etwas sie wegspült. Ein aus Router-Ankündigungen gelernter Default trägt eine Lebensdauer und kann vom Router zurückgezogen werden, während ein manuell hinzugefügter Default nie von selbst abläuft. Beides in einer Tabelle zu mischen ist der Weg, auf dem eine veraltete permanente Route eine frisch angekündigte überholt, lange nachdem der Uplink, den sie beschrieb, zu existieren aufgehört hat.

Wählen Sie einen Eigentümer pro Tabelle. Wenn ein Netzwerkmanager oder Routing-Daemon die Schnittstelle bereits verwaltet, beschreiben Sie die Policy-Route dort und lassen Sie den Kernel in Ruhe. Wenn Sie es skripten, machen Sie das Skript idempotent und schreiben Sie den Abbau gleich mit, denn Sie werden ihn bei der ersten schlechten Änderung brauchen:

ip -6 route flush table 201
ip -6 rule del fwmark 0x2 table 201

Prüfen Sie auf einem Router, der für andere Hosts weiterleitet, net.ipv6.conf.all.forwarding, bevor Sie die Tabelle beschuldigen. Mit ausgeschalteter Weiterleitung werden Pakete an ein anderes Netz verworfen, so korrekt Tabelle 201 auch ist.

Halten Sie das Design fest, damit die nächste Person es prüfen kann

Ein Inventar, das nur fe80::1 speichert, wirft die Felder weg, auf die es ankommt. Halten Sie Ziel, nächsten Hop, Gerät, Tabelle und Metrik zusammen fest, dazu die Herkunft jeder Route, ob angekündigt, vom Manager erzeugt oder statisch. Wenn jemand später fragt, ob der zweite Uplink tatsächlich Verkehr trägt, beantwortet dieser Eintrag die Frage ohne Raten.

Bevor Sie die Tabelle als fertig bezeichnen, bestätigen Sie den Nachbarn mit ip -6 neigh show dev uplink0, lesen Sie ip -6 rule show erneut auf Reihenfolgeunfälle und testen Sie mit Verkehr, der zur Regel passt, statt mit einem Ping, der die Default-Route nimmt. Nehmen Sie dann einen Uplink absichtlich herunter und beobachten Sie, auf welche Route der Kernel zurückfällt; die Antwort sollte der entsprechen, die Sie notiert haben.