Wie routenbasiertes IPsec mit einer XFRM-Schnittstelle funktioniert

Routenbasiertes IPsec überlässt der Routing-Tabelle eine Entscheidung, die früher Policy-Selektoren getroffen haben. Unter Linux ist das Stück, das dies ermöglicht, die XFRM-Schnittstelle: ein virtuelles Gerät, dessen Verkehr über einen Schnittstellenbezeichner statt über einen Selektor mit IPsec-Zustand abgeglichen wird. Ein solches Gerät zu erstellen braucht einen einzigen Befehl und beweist nichts darüber, ob ein Tunnel existiert. Das Gerät ist ein Haken zwischen Routing und Sicherheitsrichtlinie, und beide Seiten dieses Hakens müssen konfiguriert sein, bevor irgendetwas geschützt ist.

Was das Gerät ist und was es nicht ist

Eine XFRM-Schnittstelle ist ein Routing-Griff. Pakete, die hineingeroutet werden, werden gegen XFRM-Richtlinien abgeglichen, die denselben Schnittstellenbezeichner referenzieren, und wenn eine Richtlinie und ein Zustand existieren, werden sie gekapselt. Ohne diese existiert die Schnittstelle, die Zähler bleiben stehen, und der Verkehr landet nirgends sinnvoll.

Das ist die erste diagnostische Trennung. Eine Route in das Gerät ist eine Routing-Tatsache, ein installierter Zustand ist eine Sicherheitstatsache, und ein steigender Zähler am Gerät ist keines von beiden. Wenn Leute sagen, der Tunnel sei oben, weil die Schnittstelle UP zeigt, beschreiben sie die Link-Flags eines virtuellen Geräts, das keinen eigenen Peer hat. Das Flag bedeutet, dass das Gerät erstellt und aktiviert wurde, mehr nicht.

Noch eine Grenze: Der Schnittstellenbezeichner ist kein Name. Zwei Geräte mit ähnlichen Namen und unterschiedlichen Bezeichnern teilen keinen Zustand, und eine Verbindung, die mit dem falschen Bezeichner konfiguriert ist, installiert Zustand, den keine Route jemals nutzen wird.

Bauen Sie eines in der richtigen Reihenfolge

Beginnen Sie mit dem äußeren Gerät und einer Zahl, die Sie auch in die Daemon-Konfiguration schreiben. Das Beispiel verwendet eth0 als äußere Schnittstelle und 42 als Bezeichner, Adressen, die Sie durch Ihre eigenen ersetzen sollten.

Bringen Sie das Gerät hoch und bestätigen Sie dann den Bezeichner, den der Kernel festgehalten hat, bevor Sie die VPN-Konfiguration anfassen:

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip link set xfrm0 up
ip -d link show xfrm0 | grep -o 'if_id [0-9]*'

Konfigurieren Sie nun die Verbindung in strongSwan mit demselben Bezeichner, denn der Daemon muss Richtlinien und Zustände installieren, die ihn referenzieren. Setzen Sie die lokalen und entfernten Traffic-Selektoren auf den Bereich, den Sie routen wollen, und routen Sie diesen Bereich dann in das Gerät. Daemon-Konfiguration und Routing-Tabelle müssen sich sowohl über den Bezeichner als auch über die Ziele einig sein, und keine liefert die andere.

Halten Sie IKE und ESP aus der Tunnelroute heraus

Eine Default-Route, die in das XFRM-Gerät zeigt, fängt die gekapselten Pakete ebenso ein wie den Verkehr, den sie tragen. Das Ergebnis ist eine Schleife: Das Gateway versucht, sein eigenes ESP durch den Tunnel zu senden, den ESP aufbauen soll.

Die Lösung ist eine spezifischere Route für die äußere Adresse des Peers über die physische Schnittstelle, die die Default-Route gewinnt, weil sie mehr Bits trifft. Mark-basiertes Routing leistet dasselbe, wenn mehrere Tunnel eine Tabelle teilen, und strongSwan dokumentiert beide Ansätze für routenbasierte Bereitstellungen.

Was auch immer Sie wählen, verifizieren Sie, dass das äußere Paket ungekapselt hinausgeht. Eine schnelle Prüfung ist, die äußere Adresse des Peers anzupingen, nachdem der Tunnel steht; schlägt das fehl, während die Schnittstelle oben ist, verdächtigen Sie Einfang statt Erreichbarkeit. Dieselbe Überlegung gilt für den IKE-Port, denn der eigene UDP-Verkehr des Daemons darf nicht in das Gerät geroutet werden, das er aufzubauen versucht.

Prüfen Sie Zähler an zwei Stellen, bevor Sie die Verschlüsselung beschuldigen

Schnittstellenzähler und Zustandszähler messen verschiedene Stufen. In das Gerät geroutete Pakete erhöhen das Gerät auch dann, wenn kein Zustand passt, während sich die Zustandszähler nur für Verkehr bewegen, der tatsächlich gekapselt wurde.

Lesen Sie beides und dann die Sicht des Daemons auf die Child-Assoziation:

ip -s link show xfrm0
sudo ip xfrm state list | grep -E 'src|proto|mode'
sudo swanctl --list-sas

Steigende Gerätezähler bei leerer Zustandsausgabe bedeuten, dass Routing funktioniert und die Richtlinie nicht passt, meist ein Fehler bei Bezeichner oder Selektor. Steigende Zustandszähler, während die Gegenseite nichts meldet, bedeuten, dass die Pakete hinausgehen, aber nicht ankommen oder die Authentifizierung scheitern, was auf den Pfad oder die Peer-Konfiguration deutet. Ein aufgelistetes Child ohne Verkehr ist ein Selektorproblem an einem Ende, keine kaputte Chiffre.

Entscheiden Sie, wer die Routen installiert

Zwei Eigentümer für eine Routing-Tabelle sind die übliche Quelle von Flapping. Wenn der Daemon Routen automatisch installiert, darf Ihr Netzwerkmanager nicht zusätzlich eine Default-Route durch dasselbe Gerät installieren, und eine manuelle Route aus einem Startskript wird beim nächsten Rekonfigurieren des Daemons entfernt.

Wählen Sie einen Eigentümer und schreiben Sie es auf. Wenn der Daemon die Routen besitzt, halten Sie das Startskript aus der Tabelle heraus und lassen Sie die Verbindungsdefinition die Traffic-Selektoren beschreiben. Wenn der Netzwerkmanager sie besitzt, deaktivieren Sie die automatische Installation und akzeptieren Sie, dass der Daemon eine fehlende Route beim Wiederverbinden nicht repariert.

Weiterleitungs- und Firewall-Regeln sind eine separate Entscheidung darüber, denn ein Gateway, das Verkehr anderer Hosts durchlässt, braucht beides. Routenbasiertes IPsec macht diesen Verkehr mit gewöhnlichen Routing-Werkzeugen leicht ausdrückbar; es macht die Richtlinienebene nicht optional.