Die Routing-Regel liest die Paketmarkierung, nicht conntrack

Vier Prüfungen trennen eine funktionierende Markierungsregel von einer funktionierenden Route: welche Markierung die Regel liest, ob das Paket sie beim Lookup noch trägt, ob eine Verbindungsmarkierung auf spätere Pakete zurückgeschrieben wurde und ob ob Maske und Priorität der passenden Regel ihr Auslösen erlauben. Ein Zähler, der hochzählt, beweist nur, dass irgendeine Regel auf irgendetwas gepasst hat. Er sagt nichts darüber, was das Paket trug, als der Kernel seinen Pfad wählte.

Die beiden Markierungen leben an verschiedenen Stellen und laufen nach verschiedenen Zeitplänen ab.

Zwei Markierungen, zwei Lebensdauern

Eine Paketmarkierung gehört zu einem skb, wandert mit ihm durch die Hooks und wird vom fwmark-Selektor des Policy-Routings verbraucht. Eine Verbindungsmarkierung gehört zum conntrack-Eintrag, bleibt über die Pakete dieses Flusses hinweg bestehen und ist für die Routing-Regel unsichtbar, bis etwas sie zurückschreibt. Eine Paketmarkierung in die Verbindung zu speichern ist ein Speichern; sie wiederherzustellen ist eine eigene Aktion. Keines von beiden geschieht implizit.

Deshalb kann ein Regelsatz stimmig aussehen, während die Routing-Entscheidung Null sieht: der Wert wurde gespeichert, und nichts hat ihn wiederhergestellt.

Das Kopieren zwischen ihnen ist ein Schritt, den Sie schreiben

Die beiden entscheidenden Anweisungen laufen in entgegengesetzte Richtungen: die eine speichert die Markierung des Pakets in der Verbindung, die andere lädt die Markierung der Verbindung auf das Paket. Welche Sie brauchen, hängt davon ab, wann die Klassifizierung relativ zum Fluss stattfindet. Ein Entwurf kann nur die Paketmarkierung benötigen, und conntrack-Markierung hinzuzufügen, weil ein Workaround beides nutzte, ist der Weg, auf dem eine einfache Policy einen zweiten Fehlermodus bekommt.

ct mark set meta mark
meta mark set ct mark

Schreiben Sie die Richtung neben die Regel, denn aus der Syntax ist sie auf den ersten Blick nicht ersichtlich. Die erste Zeile speichert, die zweite stellt wieder her, und keine setzt die andere voraus.

Klassifizieren Sie vor dem Lookup, der es verbraucht

Lokal erzeugter Verkehr und aus einem LAN weitergeleiteter Verkehr durchlaufen verschiedene Hooks und erreichen Routing-Entscheidungen zu verschiedenen Zeitpunkten. Eine Output-Regel, die für die eigenen Verbindungen des Routers funktioniert, beweist nicht, dass das Paket eines weitergeleiteten Clients vor seinem Lookup markiert wurde. Setzen Sie die Klassifizierung dorthin, wo der Lookup, der sie verbraucht, noch nicht stattgefunden hat, und prüfen Sie, ob spätere Regeln in derselben Kette den Wert überschreiben. Die Reihenfolge innerhalb einer Kette ist Teil der Konfiguration, kein Implementierungsdetail.

Auch die Persistenz des Verbindungszustands braucht einen ausdrücklichen Plan. Wenn nur das erste Paket eines Flusses klassifiziert wird, müssen spätere Pakete die gespeicherte Markierung wiederhergestellt bekommen, sonst nehmen sie den unmarkierten Pfad. Das ist der Unterschied zwischen einer Markierung, die eine Verbindung beschreibt, und einer, die ein Paket beschreibt.

Stellen Sie der Route eine markierte Frage

ip route get 10.77.0.10 mark 0x2

Prüfen Sie die Regeln und die Tabelle und fragen Sie dann die Route mit eingeschlossener Markierung ab, dazu Quelle oder eingehende Schnittstelle, wenn diese die Policy beeinflussen. Ein einfacher unmarkierter Lookup beantwortet eine andere Frage und meldet bereitwillig den Pfad, den Sie nicht wollten. Prüfen Sie Maske und Priorität der Regel ebenso wie ihren Wert und bestätigen Sie, dass die ausgewählte Tabelle eine brauchbare Route enthält.

Ein steigender Zähler ist ein Beleg dafür, dass irgendeine Regel auf irgendein Paket gepasst hat. Er ist kein Beleg dafür, dass das endgültige Paket die beabsichtigte Markierung am richtigen Entscheidungspunkt trug.

Lesen Sie die Markierung, die Richtung, den Zeitpunkt und die Maske. Vier Prüfungen, und die Route ist kein Rätsel mehr.