Warum eine OpenVPN-Route gegen eine strongSwan-XFRM-Policy verliert

Pakete können einer OpenVPN-Route folgen und trotzdem von einer IPsec-Policy erfasst werden, und diese Kombination sieht aus jedem Blickwinkel wie ein Routingfehler aus, außer aus dem richtigen. Linux löst eine Route auf und konsultiert dann eine separate Sicherheitsrichtliniendatenbank, sodass eine spezifischere Zielroute eine passende XFRM-Policy nicht verdrängt. Das sichtbare Symptom ist Verkehr, der den Host verlässt und nie ankommt, während sich beide Tunnel als gesund melden. Drei Optionen lösen das, und welche man wählt, hängt davon ab, welcher der beiden Wege das Präfix tragen soll.

Zwei Entscheidungen, nicht eine

Die Routenauswahl beantwortet eine enge Frage: Welcher nächste Hop und welche Quelladresse sollen dieses Paket tragen. Die Sicherheitsrichtliniendatenbank beantwortet eine andere: Braucht dieses Paket IPsec-Schutz, und unter welchen Selektoren. Beide laufen für dasselbe Paket, und die erste zu erfüllen sagt nichts über die zweite. Deshalb kann eine geänderte Metrik oder eine zusätzliche statische Route das Symptom unberührt lassen.

Ein breiter IPsec-Selektor ist die übliche Ursache. Eine Policy, die 172.16.0.0/12 schützt, deckt auch 172.20.8.0/24 ab, das ein Administrator vielleicht stattdessen über den OpenVPN-Tunnel erreichen will. Die Absicht existiert nur in der Routing-Tabelle, und die Policy-Datenbank hat nie davon erfahren.

Behandeln Sie das als Konflikt zwischen zwei konfigurierten Schutzwegen und nicht als Wettstreit zweier Metriken. Die Korrektur gehört in die Komponente, die mit dem falschen Geltungsbereich konfiguriert wurde.

Lesen Sie die Route, die der Kernel tatsächlich wählt

Beginnen Sie mit der Suche, die der Kernel durchführt, einschließlich der Quelladresse und jeder Policy-Regel, die sie in eine andere Tabelle umleiten könnte. Eine Route in der Haupttabelle wird möglicherweise nie konsultiert, wenn eine frühere Regel eine andere Tabelle wählt, und die Longest-Prefix-Übereinstimmung gilt nur innerhalb der Tabelle, die eine Regel wählt.

ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15

Der letzte Befehl ist der entscheidende, weil er die gewählte Route zusammen mit der Quelladresse ausgibt, die der Kernel verwenden würde. Vergleichen Sie diese Ausgabe mit dem Selektor, auf den die IPsec-Policy passt. Wenn die Route auf die OpenVPN-Schnittstelle zeigt und die Policy weiterhin auf dasselbe Paar passt, haben Sie den Konflikt ohne Raten reproduziert.

Halten Sie Dumps frei von unbezogenen Adressen, bevor sie ein Ticket erreichen. Eine Routing-Tabelle von einem Produktionshost trägt interne Topologie, und nur die Zeilen, die die Frage beantworten, sind es wert, eingefügt zu werden.

Lesen Sie die Policy, die ebenfalls gilt

Die Policy-Auflistung zeigt Richtung, Selektoren und die Vorlage, die entscheidet, was mit einem passenden Paket geschieht. Lesen Sie zuerst die ausgehende Richtung, dann die eingehende Seite für den Rückverkehr, denn eine einseitige Ausnahme erzeugt eine Verbindung, die beginnt und nie abgeschlossen wird.

ip -s xfrm policy
swanctl --list-sas

Vergleichen Sie die Selektoren in der Auflistung mit den Präfixen, die die Verbindung ausgehandelt hat. Das Abschalten der Routeninstallation von strongSwan entfernt diese Policies nicht, und eine geänderte Metrik ändert nicht, welches Quell-Ziel-Paar eine Policy schützt. Diese beiden Scheinlösungen lohnt es sich früh auszuschließen, weil sie zuerst probiert werden.

Wenn die Auflistung keine Policy für das erwartete Präfix enthält, liegt das Problem woanders, und die Routing-Tabelle sagt wahrscheinlich die Wahrheit. Wenn sie eine breitere Policy enthält, die das Präfix abdeckt, haben Sie die Erfassung gefunden.

Drei Optionen, wenn beide Wege legitim sind

Den IPsec-Selektor zu verengen ist die sauberste Option, wenn das breite Präfix eine Bequemlichkeit und keine Anforderung war. Den Remote-Traffic-Selektor auf die Subnetze zu reduzieren, die wirklich hinter IPsec gehören, beseitigt den Konflikt für jeden Host auf einmal, und es kostet einen Schlüsselwechsel statt einer neuen Komponente.

Eine Passthrough-Ausnahme ist die chirurgische Option, wenn der breite Selektor bleiben muss. strongSwan unterstützt eine separate Verbindung, deren Child den Pass-Modus nutzt, was dem Kernel mitteilt, dass der passende Verkehr nicht durch IPsec verarbeitet werden darf. Die Loopback-Remote-Adresse verhindert, dass diese Verbindung für eingehende Peers gewählt wird, und die Selektoren müssen das real autorisierte Paar beschreiben statt alles.

connections {
    openvpn-exception {
        remote_addrs = 127.0.0.1
        children {
            openvpn-exception {
                local_ts = 10.44.7.0/24
                remote_ts = 172.20.8.0/24
                mode = pass
                start_action = trap
            }
        }
    }
}

Die strongSwan-Konfigurationsbeispiele dokumentieren diesen Policy-Typ und die Loopback-Peer-Konvention. Die dritte Option ist ein routenbasiertes Design mit XFRM-Schnittstellen, das Policy an Verkehr bindet, der über eine benannte Schnittstelle geroutet wird, statt an einen globalen Selektor. Es ist eine Migration und kein Feintuning, und der Verkehr muss weiterhin die ausgehandelten Selektoren erfüllen.

Beweisen Sie die Ausnahme, ohne den Rest zu schwächen

Testen Sie nach dem Laden der Änderung die Ausnahme und ein gewöhnliches Ziel, das geschützt bleiben muss. Prüfen Sie beide Richtungen, lassen Sie dann den OpenVPN-Tunnel fallen und bestätigen Sie, was mit dem ausgenommenen Verkehr geschieht. Eine Ausnahme, die dieses Präfix bei ausgefallenem Tunnel stillschweigend im Klartext sendet, ist eine Policy-Entscheidung, die Sie bewusst treffen sollten, nicht während eines Vorfalls entdecken.

Notieren Sie, welches Präfix welchen Weg nutzt und warum. Sonst eröffnet der nächste Ingenieur, der einen breiten Selektor sieht, dieselbe Untersuchung erneut, und die Antwort steht in einer Commit-Nachricht, die niemand liest.