IPsec in IPsec: Welche Adressen der äußere Tunnel tragen muss

Verschachteltes IPsec lässt sich leichter durchdenken, wenn die beiden Ebenen auf unterschiedlichen Maschinen enden. Vier Gateways, zwei Tunnel und eine einzige Frage, die entscheidet, ob das Design funktioniert: Was sieht der äußere Tunnel tatsächlich, wenn der innere mit dem Paket fertig ist? Beantworten Sie das, und Selectors, Routen und Fehlersuche-Reihenfolge folgen. Machen Sie es falsch, und Sie verbringen einen Tag damit, einen Tunnel zu debuggen, der technisch gesehen steht.

Das Modell mit vier Gateways

Die äußeren Gateways A und B bauen den ersten Tunnel zwischen den beiden Standorten auf. Hinter A sitzt das innere Gateway C mit der Transitadresse 10.60.0.2; hinter B sitzt das innere Gateway D mit der Transitadresse 10.70.0.2. Die Anwendungsnetze liegen hinter C und D, und jede Adresse im Beispiel überlappt bewusst nicht.

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

Die Ebenen auf vier Hosts zu verteilen bedeutet, dass jede Maschine eine Grenze durchsetzt. Ein einzelner Host, der beide Ebenen ausführt, muss zwei Policies, zwei Routing-Tabellen und zwei Fehlermodi auf einer Maschine unter einen Hut bringen, was möglich und viel schwerer zu beobachten ist.

Jede Ebene entfernt nur ihren eigenen Schutz

C verschlüsselt ein Anwendungspaket für D. Das Ergebnis ist von C nach D adressiert, und genau das erreicht A. Alles flussabwärts hängt von dieser Umschreibung ab.

A verschlüsselt es erneut für B. B entschlüsselt die äußere Ebene, sieht ein Paket von C nach D und leitet es weiterhin verschlüsselt weiter. D entfernt den inneren Schutz und stellt das Anwendungspaket zu.

A und B sehen also die inneren Endpunkte und ihre Metadaten, sind aber nicht die Parteien, die die Anwendungsnutzlast entschlüsseln. Das ist eine echte Eigenschaft des Designs und keine Behauptung, C, D oder die Anwendungshosts seien vertrauenswürdig.

Die äußeren Selectors benennen die inneren Gateways

Hier scheitern die meisten dieser Aufbauten. Bei einem policybasierten äußeren Tunnel müssen die Selectors, die Sie aushandeln, die Adressen enthalten, die A und B tatsächlich verarbeiten: 10.60.0.2/32 und 10.70.0.2/32, in der richtigen lokalen und entfernten Reihenfolge.

Die endgültigen Anwendungs-Subnetze in die äußeren Selectors zu setzen funktioniert nicht, denn wenn ein Paket A erreicht, hat die innere Kapselung bereits umgeschrieben, was A schützen muss. Die äußere Policy würde dann nichts mehr treffen, und der Tunnel käme hoch, ohne Daten zu tragen.

Verengen Sie die äußere Erlaubnis auch nicht auf UDP 500. Die innere Verbindung hat ihren eigenen Datenpfad, der je nach Aushandlung ESP oder UDP-Kapselung verwendet, und die äußere Policy muss dieses Protokoll zulassen.

Prüfen Sie das Ergebnis mit swanctl --list-sas auf jedem Gateway und bestätigen Sie, dass die Child-Sicherheitsassoziationen die beabsichtigten Adressen melden, nicht die angenommenen. Wenn die Liste die Anwendungs-Subnetze zeigt, wurde die äußere Policy für die falsche Ebene geschrieben. Korrigieren Sie die Selectors, bevor Sie das Routing debuggen, denn das Routing wird in Ordnung aussehen, und die Zähler werden sich nicht bewegen.

Weiterleitung und die Rekursionsfalle

Selectors ersetzen kein Routing. A und B müssen Verkehr zwischen C und D in beide Richtungen weiterleiten, was aktivierte IP-Weiterleitung, Routen, die auf den Tunnel zeigen, und einen Rückweg auf der Gegenseite bedeutet.

Wenn der äußere Tunnel XFRM-Interfaces verwendet, wählen Routen das Interface aus, während die ausgehandelten Policies weiterhin begrenzen, was es trägt. Ein Interface erweitert nicht den geschützten Bereich; es ändert nur, wie der Kernel das Paket aufgreift.

Die Falle ist Rekursion. Die Route von A zum äußeren Endpunkt von B muss dem Underlay folgen, nicht dem Tunnel, den A aufbaut, sonst versucht die Kapselung, in sich selbst zu reisen, und die Verbindung kommt nie zustande.

Prüfen Sie die Übersetzung, bevor Sie Ebenen hinzufügen

Sehen Sie sich jedes Source-NAT auf A und B an, bevor Sie irgendetwas anderes abstimmen. Eine Regel, die C's Adresse umschreibt, bevor die IPsec-Policy greift, kann die vereinbarten Selectors brechen und auch ändern, was D auf der anderen Seite erhält.

Breites Masquerading wird durch zwei Ebenen nicht sicherer. Es verbirgt, welche Adresse die Gegenseite sieht, und genau diese Information brauchen Sie, wenn der Tunnel steht und die Anwendung nicht.

Wenn eine NAT-Regel wirklich nötig ist, schreiben Sie auf, mit welcher Adresse jede Seite zu sprechen glaubt. Diese eine Zeile entscheidet die meisten Diskussionen darüber, ob der Tunnel oder die Übersetzung schuld ist. Sie sagt auch dem nächsten Ingenieur, wo er nachsehen soll, wenn die Regel ein Jahr später entfernt wird. Ein Ping leistet nichts davon.

Fail-closed beweisen und die MTU prüfen

Eine verschwindende Route ist für sich genommen keine Fail-closed-Policy. Eine andere Tabelle, eine Default-Route oder eine Policy-Regel kann stillschweigend einen Fallback liefern, und der einzige Weg, das zu wissen, ist, den äußeren Tunnel herunterzunehmen und zu beobachten, was der Anwendungsverkehr tut. Tun Sie das absichtlich, in einem Wartungsfenster, statt es zufällig zu entdecken.

Testen Sie drei Zustände: äußerer Tunnel unten, innerer Tunnel unten und Wiederherstellung, nachdem beide zurück sind. Verwenden Sie Policy-Zähler an jedem Gateway, denn zwei etablierte IKE-Sitzungen beweisen nur, dass die Aushandlung auf der Steuerungsebene erfolgreich war.

Kalkulieren Sie beide Kapselungen ein. Funktionierendes IKE ist ein Kleinpaket-Ergebnis, und Anwendungspakete voller Größe können noch scheitern, sobald zwei Header hinzukommen; testen Sie mit einer bekannten Nutzlastgröße auf dem realen Pfad, statt anzunehmen, die Zahlen würden aufgehen. Die Arithmetik ist einfach, der Pfad nicht.