IPsec ESP: Was es trägt und wie man belegt, dass es fließt

ESP trägt den Verkehr in einem IPsec-VPN, und sein Runbook beginnt mit einer Regel: Lesen Sie die Security Association, bevor Sie eine Policy ändern. Das meiste unerklärte ESP-Verhalten geht auf einen Selektor zurück, der nicht passte, einen Modus, der angenommen statt gelesen wurde, oder einen Zähler, den niemand prüfte, während ein einzelner Fluss gesendet wurde. Die drei Schritte unten legen fest, was was trägt, belegen, dass ein Fluss es nutzt, und hinterlassen ein Rollback, das nicht vom Gedächtnis abhängt. Jeder Schritt liefert eine Beobachtung, die es wert ist, notiert zu werden.

Kennen Sie die Felder, bevor Sie sie lesen

ESP setzt einen Header vor die geschützten Daten und einen Trailer dahinter. Der Header trägt einen Security-Parameter-Index, der angibt, welche Assoziation der Empfänger verwenden soll, eine Sequenznummer zur Replay-Erkennung und im Trailer Padding, das die Nutzlast für die Chiffre ausgerichtet hält. Das Next-Header-Feld im Trailer sagt, was der geschützte Inhalt ist, und so weiß der Empfänger, was er entkapselt hat.

Der Modus ändert, was innerhalb dieses Schutzes liegt. Im Tunnelmodus ist das geschützte Material ein vollständiges inneres IP-Paket, und ein neuer äußerer Header trägt es zwischen den Endpunkten. Im Transportmodus umschließt der Schutz die Nutzlast der oberen Schicht eines bestehenden Pakets, es gibt also keinen zweiten IP-Header zu entpacken. Welcher Modus verwendet wird, ist eine Konfigurationstatsache und keine Auslegungsfrage. Lesen Sie ihn aus dem Status-Eintrag, statt ihn aus einem Diagramm abzuleiten.

Keiner der Modi verbirgt die äußere Adressierung, die das Paket zustellen muss. Das ist eine Eigenschaft des Entwurfs und kein Mangel, und deshalb kann ein zwischengeschalteter Beobachter weiterhin sehen, welche zwei Adressen miteinander sprechen, selbst wenn die Nutzlast undurchsichtig ist.

Schritt eins: den Status lesen, dann die Policy

Die Status-Einträge halten die Schlüssel und Zähler; die Policy-Einträge halten die Selektoren, die entscheiden, was sie verwenden darf. Unter Linux sind beide ohne Paketmitschnitt sichtbar, und sie in dieser Reihenfolge zu lesen hält die beiden Fragen getrennt.

ip xfrm state
ip xfrm policy

Prüfen Sie in der Status-Ausgabe Quelle und Ziel der Assoziation, den Modus und ob die Kapselung UDP-Ports zeigt. Diese Ports bedeuten, dass NAT-Traversal verwendet wird, was ändert, was eine zwischengeschaltete Firewall zulassen muss, aber nicht, welche Selektoren oder Schlüssel an den Endpunkten gelten.

Lesen Sie dann die Selektoren in der Policy. Ein Selektor, der ein engeres Präfix nennt als der Verkehr, den Sie testen, ist der häufigste Grund, warum ein funktionierender Tunnel einen Fluss zu ignorieren scheint, und ein Selektor für das falsche Protokoll erzeugt dieselbe Stille.

Herstellerwerkzeuge geben dieselben Informationen in freundlicherer Form aus. ipsec statusall auf strongSwan listet die Kind-Assoziationen, ihre Selektoren und ihre Byte-Zähler, was oft schneller ist als rohe xfrm-Ausgabe zu lesen, wenn Sie bereits wissen, welches Kind Sie ansehen müssen.

Schritt zwei: belegen, dass ein Fluss die Zähler bewegt

Zähler sind nur aussagekräftig, wenn Sie wissen, was sie hätte bewegen sollen, also wählen Sie eine Quelle und ein Ziel, die der Selektor sicher abdeckt, und senden Sie eine harmlose Anfrage. Lesen Sie dann denselben Eintrag erneut und vergleichen Sie.

ip -s xfrm state
tcpdump -ni any esp

Zwei Messungen erzählen unterschiedliche Geschichten. Pakete, die auf der ausgehenden Seite steigen, aber nie auf der eingehenden, deuten auf ein Weiterleitungs- oder Rückwegproblem hin statt auf ein Schlüsselproblem, denn das Paket wurde gekapselt und verließ den Host. Bewegt sich kein Zähler, hat der Verkehr nie zur Policy gepasst, und der Selektor ist die Stelle, an der Sie nachsehen.

Der Mitschnitt im selben Schritt bestätigt die Kapselung auf der Leitung, einschließlich der Frage, ob die äußeren Pakete ESP oder UDP-gekapseltes ESP sind. Er zeigt Ihnen auch die Adressen, die den Fluss tatsächlich getragen haben, und die weichen gelegentlich von denen in der Konfiguration ab, die Sie gelesen haben.

Schritt drei: eine Sache ändern und ein Rollback behalten

Notieren Sie Quelle, Ziel, Modus, Selektoren und Zähler der Assoziation, bevor Sie etwas bearbeiten. Wenn eine Änderung die Lage verschlechtert, erlaubt Ihnen genau diese Notiz, den vorherigen Zustand wiederherzustellen, statt eine funktionierende Konfiguration aus einer Vermutung neu zu bauen. Die Notiz kostet eine Minute und spart später eine Stunde. Sie ist auch das einzige Artefakt, das die Person überlebt, die die Änderung vorgenommen hat.

Ändern Sie einen Selektor oder einen Parameter, laden Sie ihn neu und wiederholen Sie Schritt zwei gegen denselben Fluss. Das Löschen einer Assoziation reißt jeden Fluss ab, der sie nutzt, daher sind eine gezielte Bearbeitung und ein Neuladen des Kindes fast immer besser, als den Status zu leeren, um zu sehen, was passiert.

Das Rollback einer Selektoränderung ist das Wiederherstellen der vorherigen Policy und ein Neuladen, mit der Einschränkung, dass die Gegenseite eine passende Änderung brauchen kann, wenn der Selektor ausgehandelt und nicht lokal ist. Schreiben Sie diese Abhängigkeit auf, solange sie frisch ist, denn ein halb wiederhergestelltes Paar ist schwerer zu durchdenken als jeder der beiden Endzustände.

Halten Sie zum Schluss den Umfang ehrlich. Eine fließende ESP-Assoziation belegt, dass die beiden Gateways das Segment schützen und zustellen, und sie sagt nichts darüber, ob die Anwendung darüber ihre Nutzer authentifiziert oder verschlüsselt, was sie speichert. Das sind getrennte Kontrollen mit getrennten Nachweisen, und das Runbook ist erst fertig, wenn die nächste Person es anhand der Notizen wiederholen kann.