IPsec-Verkehrsselektoren: Was sie abdecken und was nicht

Verkehrsselektoren benennen den inneren Verkehr, den eine IPsec-Vereinbarung schützt, und das Paar wird ausgehandelt statt angenommen. Zwei Endpunkte können sich gegenseitig einwandfrei authentifizieren und sich dennoch darüber uneinig sein, welche Pakete in den Tunnel gehören. Diese Uneinigkeit ist im Verbindungsstatus unsichtbar, der normalerweise einen gesunden Tunnel meldet. Wer die Selektoren von beiden Enden liest und dann ein Ziel verfolgt, findet sie schneller als mit noch so viel Richtlinienbearbeitung.

Von beiden Enden lesen

Jeder Endpunkt beschreibt seine eigene Seite als lokal und die andere Seite als entfernt. Dasselbe Präfixpaar erscheint daher in den beiden Konfigurationen vertauscht, und das ist korrekt und nicht widersprüchlich. Die Perspektive umzudrehen ist das Erste, was zu tun ist, wenn eine funktionierende Vereinbarung auf dem Papier falsch aussieht. Zwei Dateien nebeneinander zu vergleichen, ohne sie zu tauschen, erzeugt eine Nichtübereinstimmung, die es nicht gibt.

Die Werte sind nicht immer einzelne Subnetze. IKEv2-Selektoren können Adressbereiche, Protokollnummern und Portbereiche tragen, und so schützt eine Richtlinie einen Dienst statt eines ganzen Netzwerks. Ein Selektor, der enger ist als der beabsichtigte Verkehr, erzeugt einen Tunnel, der einige Ziele trägt und andere still ausschließt.

Schreiben Sie beide Seiten in eine Tabelle, bevor Sie irgendetwas ändern. Die Übung klärt die Frage meist, ohne eine Konfigurationsdatei anzufassen.

Das Verengen ist die Entscheidung des Responders

Ein Initiator schlägt vor, und der Responder darf nur eine Teilmenge annehmen. IKEv2 erlaubt dem Responder, die angebotenen Verkehrsselektoren zu verengen, und das verengte Ergebnis wird tatsächlich installiert. Die Konfiguration des Initiators zu lesen beschreibt daher ein Angebot, nicht die Vereinbarung.

Deshalb kann ein zum Client hinzugefügtes Subnetz einen funktionierenden Tunnel erzeugen, der das neue Ziel trotzdem ablehnt. Der Server hat das Angebot auf das verengt, was seine Richtlinie zulässt, während die Datei des Clients noch den weiteren Bereich auflistet. Nur der ausgehandelte Zustand zeigt die Wahrheit: unter Linux melden ip xfrm policy und die child-SA-Auflistung in strongSwans IKEv2-Dokumentation, was installiert wurde, statt was angefordert wurde. Wenn die beiden nicht übereinstimmen, ist die Richtlinie des Responders diejenige, die geändert werden muss.

Ein abgelehntes Angebot ist ein anderes Symptom als ein verengtes. Eine Ablehnung erscheint im Verhandlungsprotokoll und hinterlässt überhaupt keine child-Assoziation.

Ein Ziel von Anfang bis Ende verfolgen

Wählen Sie ein echtes Ziel plus die Quelladresse, die der Client dafür verwenden würde, und verfolgen Sie dann dieses Paar durch drei unabhängige Entscheidungen. Die Route wählt einen Pfad, der Selektor entscheidet, ob dieser Pfad geschützt ist, und die Firewall entscheidet, ob das Paket erlaubt ist. Jede kann für sich scheitern, und ein breiter Selektor repariert keine der anderen.

ip route get 10.20.30.41
ip xfrm policy list
swanctl --list-sas

Die Routenabfrage nennt die Schnittstelle und die Quelladresse, die das Paket tragen würden. Die Richtlinienauflistung zeigt, ob eine passende Tunnelrichtlinie für dieses Paar existiert, einschließlich Richtung und Ebene. Die SA-Auflistung zeigt die ausgehandelten child-Selektoren zusammen mit Zählern, sodass eine child-Assoziation mit null Paketen nach versuchtem Verkehr die Signatur von Selektoren ist, die ausschließen, was gesendet wird. Drei Befehle, drei verschiedene Antworten, und nur eine davon erklärt einen stillen Verlust.

Wenn sich die child-Zähler bewegen, während die Anwendung weiterhin scheitert, liegt das Problem jenseits des Tunnels. Das verlagert die Untersuchung auf den Listener oder die Firewall des entfernten Hosts statt auf die Selektoren.

Halten Sie die beiden Ziele getrennt

Ein Büro-Subnetz zu schützen und das gesamte Surfen über einen entfernten Ausgang zu senden, sind unterschiedliche Anforderungen mit unterschiedlichen Selektoren. Ein für das eine gebautes Profil passt selten zum anderen, und ihre Vermischung erzeugt entweder ein Leck oder eine kaputte Aufteilung. Den geschützten Bereich zu erweitern bedeutet, beide Endpunkte und ihre Weiterleitungsrichtlinie zu ändern, weil eine einseitige Änderung zu einem abgelehnten Angebot wird. Das ist der häufigste Weg, auf dem ein funktionierender Tunnel nach einer kleinen Änderung aufhört zu funktionieren.

Selektoren beschreiben die kryptografische Abdeckung, Routen wählen Pfade, und Anwendungen setzen ihre eigenen Berechtigungen durch. Ein Tunnel, der alles abdeckt, erreicht trotzdem keinen Dienst, der an loopback gebunden ist, und eine Route in den Tunnel braucht trotzdem einen Selektor, der das Ziel einschließt. Prüfen Sie alle drei an derselben Testanfrage, und die Nichtübereinstimmung benennt sich selbst.