IPsec mit mehreren Subnetzen verliert Rückverkehr? Zählen Sie die Reqids

Der Verkehr verlässt einen Standort und kommt nie zurück, beide Gateways melden eine abgeschlossene Aushandlung, und der einzige Hinweis ist ein Stapel ausgehender Pakete ohne Antworten. Auf einem Linux-Endpunkt ist die übliche Ursache nicht die Verschlüsselungsstärke, die MTU oder die Routing-Tabelle. Es ist die Granularität der Policy-Einträge und die Nummer, die jede Policy mit einer Sicherheitsassoziation verbindet. Die folgende Anleitung liest diese beiden Datenbanken, bevor etwas anderes angefasst wird.

Das Symptom eingrenzen, bevor etwas geändert wird

Ein einseitiger Fehler bei abgeschlossener IKE-Aushandlung engt das Problem auf den Datenpfad ein. Entweder passte die ausgehende Policy und die Antwort wurde verworfen, oder die Antwort kam nie an, weil die Gegenseite nichts hatte, womit sie sie senden konnte. Für eine Anwendung sehen beide Fälle gleich aus, und die xfrm-Datenbanken unterscheiden sie.

Beginnen Sie nicht mit der MTU. Eine falsche MTU erzeugt Stocken und Fragmentierungssymptome, keine saubere Richtungstrennung mit steigenden Ausgangszählern.

Die Policy-Datenbank und die State-Datenbank lesen

Verschlüsselung unter Linux entscheiden Policy-Einträge, also bringt eine passende Policy und nicht eine Route ein Paket in den Tunnel. Führen Sie ip xfrm policy aus, um Selektoren, Richtung, Priorität und Template jedes Eintrags zu sehen, und ip xfrm state, um die aufgebauten Assoziationen mit ihren Reqids zu sehen. Die Policy und die Assoziation werden durch diese Reqid verbunden.

Sehen Sie sich alle drei Richtungen an. Ausgehend und eingehend decken den Verkehr zu und von diesem Host ab; die Forward-Richtung zählt, wenn der Host für andere weiterleitet. Ein fehlender oder abweichender Eintrag in einer Richtung erklärt ein einseitiges Ergebnis ohne jeden kryptografischen Fehler.

Die klassische Asymmetrie: eine Reqid für mehrere Subnetze

Ein häufiger Fehler kommt von einer Gegenstelle, die Policies für alle ausgehandelten Subnetze unter einer einzigen Reqid installiert, was mit racoons generate_policy require passiert. Der Verkehr geht dann über die zuletzt aufgebaute Assoziation hinaus, während die Gegenseite pro Subnetz eine eigene Assoziation behält. Antworten treffen auf einer Assoziation ein, deren Reqid nicht die Policy bezeichnet, die sie annehmen müsste, und der Kernel verwirft sie nach der Entschlüsselung.

Die Lösung ist eine Konfigurationsänderung, keine Firewall-Regel: generate_policy unique; gibt jeder Policy ihre eigene Reqid, sodass die Assoziationen pro Policy der Gegenseite passende Partner haben. Wenden Sie das an, handeln Sie neu aus, und zählen Sie die verschiedenen Reqids für die erwarteten Subnetze, bevor Sie Erfolg erklären.

Teilen sich zwei Subnetze weiterhin eine Reqid, obwohl die Gegenseite zwei erwartet, haben Sie die Asymmetrie gefunden. Halten Sie die Zuordnung fest, denn sie ist der Beleg dafür, ob die nächste Änderung sie behoben oder erhalten hat.

Selektoren stammen aus der Aushandlung, nicht aus Ihrer Konfiguration

Die geschützten Bereiche sind das, worauf sich beide Seiten geeinigt haben, nicht das, was eine Seite verlangt hat. Ein Client, der ein Host-Paar gegen einen breiten entfernten Bereich anbietet, erhält die verengte Version des Gateways, und der Client kann sie nicht erweitern. Lesen Sie die installierten Selektoren statt der in Ihrer lokalen Datei.

Wenn das Ziel das Gegenteil ist, ein Ziel außerhalb des Tunnels zu halten, fügen Sie eine Bypass-Policy mit einer niedrigeren Prioritätsnummer hinzu, damit sie gegen den automatisch installierten Eintrag gewinnt. Eine Policy ohne Template erlaubt Klartext, was sie zu einer bewussten Ausnahme für einen Änderungsnachweis statt zu einem Debugging-Schritt macht.

In dieser Reihenfolge prüfen, und den Rückweg kennen

Listen Sie Policies für jedes Subnetz in beiden Richtungen auf, einschließlich Forward, wenn der Host weiterleitet. Zählen Sie die verschiedenen Reqids und bestätigen Sie eine pro Policy auf der Seite, die sie erwartet. Vergleichen Sie installierte Selektoren mit den ausgehandelten. Lesen Sie die Zähler pro Assoziation nach einem Rekey erneut, denn die Assoziation, die Sie geprüft haben, kann bereits weg sein. Prüfen Sie Routen zuletzt, denn eine fehlende Route zum entfernten Subnetz erzeugt ein ähnliches einseitiges Symptom mit sauberen Policy-Zählern.

Bevor Sie die Gegenstelle ändern, sichern Sie die aktuelle Ausgabe beider xfrm-Befehle. Stellt die neue Einstellung die Rückrichtung nicht wieder her, ist das Zurückspielen dieser Ausgabe ein schnellerer Rollback als der Neuaufbau des Tunnels aus dem Gedächtnis, und es hält den Vergleich ehrlich.