IPsec-Child-SA steht, doch die Paketzähler bleiben auf null

Sie haben den Tunnel aufgebaut, der Rekey-Timer läuft herunter, und in beide Richtungen stehen weiterhin null Pakete. Dieses Zahlenpaar sagt nichts darüber aus, dass die Gegenstelle Ihren Tunnel abgelehnt hätte: eine installierte CHILD SA mit untätigen Zählern ist der normale Zustand einer Assoziation, zu der bisher nichts gepasst hat. Die Aufgabe besteht darin, zu belegen, dass ein Paket hätte passen müssen, und dann die Stelle zu finden, an der es den Pfad verlassen hat, den die Selektoren beschreiben. Tun Sie das einmal, in der richtigen Reihenfolge, und halten Sie die Anfrage zwischen den Läufen identisch.

Was ein Zählerstand von null tatsächlich belegt

Eine CHILD SA ist ein Selektorpaar plus die Schlüssel und SPIs, die den Verkehr innerhalb dieser Bereiche verschlüsseln. Sie zu installieren bedeutet nur, dass sich beide Seiten auf diese Bereiche und die abgeleiteten Schlüssel geeinigt haben; der Kernel hält sie stundenlang, ohne dass ein einziges Paket eintrifft. Die Frage ist also nie, ob der Tunnel existiert, sondern ob ein Paket Ihres Tests in die Bereiche gefallen ist, die beide Seiten ausgehandelt haben. War das nicht der Fall, bleiben die Zähler auf null, und die Assoziation läuft am Ende ihrer Lebensdauer ungenutzt ab.

Dieser Unterschied ändert, was Sie zuerst prüfen. Ein abgelehnter Vorschlag, ein Authentifizierungsfehler oder eine sterbende IKE SA erscheinen im Protokoll oder in der SA-Liste, nicht als stilles Null. Ein Tunnel, der sauber aushandelt und dann untätig bleibt, deutet stattdessen auf das Matching, das Routing oder den Ursprung des Testverkehrs hin.

Senden Sie einen Datenfluss, den Sie vorher beschreiben können

Wählen Sie ein Ziel im geschützten Subnetz und öffnen Sie eine neue Verbindung dorthin; eine Seite, die Sie vor einer Stunde geladen haben, kann aus dem Cache kommen, und eine zwischengespeicherte Antwort berührt den Tunnel nie. Notieren Sie dann vier Werte, solange die Anfrage noch hypothetisch ist: die Quelladresse, die die Anwendung binden wird, das Ziel, die Adressfamilie und den Namen oder das Selektorpaar des Child, das Sie beobachten. Dieser Eintrag verwandelt einen flachen Zählerstand in eine prüfbare Aussage.

Die Quelladresse ist der Wert, den Leute überspringen, und genau er lässt den Test am häufigsten scheitern. Ein Laptop mit einer kabelgebundenen Adresse, einer WLAN-Adresse und einer Tunneladresse kann je nach Routensuche jede davon binden, und nur eine liegt möglicherweise im ausgehandelten Bereich. Verwenden Sie ein Werkzeug, mit dem Sie die Quelle festlegen können, etwa ping -I 10.1.0.5 10.2.0.9 oder curl --interface 10.1.0.5, damit das Paket nicht stillschweigend eine andere Adresse wählt. Wenn der festgelegte Lauf die Zähler bewegt und der nicht festgelegte nicht, haben Sie ein Routingproblem gefunden und kein IPsec-Problem.

Welche Zahlen Sie lesen und wo sie liegen

Unter Linux gibt ip -s xfrm state jede Assoziation mit einer Zeile lifetime current: aus, deren Byte- und Paketsumme allein zu dieser SA gehören, gefolgt von einer Zeile stats: für Replay- und Fehlerzähler. Auf einer strongSwan-Gegenstelle führt swanctl --list-sas pro installiertem Child eine Zeile in und eine Zeile out auf, jede endet mit einer Byte- und einer Paketanzahl; die älteren Stroke-Werkzeuge bezeichnen dasselbe Paar als bytes_i und bytes_o. Lesen Sie beide Richtungen getrennt, denn die flach gebliebene Richtung ist der Befund. Beide zusammenzuzählen verdeckt genau die Asymmetrie, nach der Sie suchen.

Beide Ansichten sind pro Assoziation, ein Rekey installiert also ein frisches SPI-Paar, und Ihre Ausgangsbasis kehrt auf null zurück, ohne dass etwas kaputt ist. Notieren Sie das SPI, das Sie beobachten, bevor der Rekey-Timer auslöst, sonst vergleichen Sie eine neue SA mit einer alten Zahl. Steigt ausgehend an, während eingehend flach bleibt, hat der Selektor gepasst und die Antwort kam nie zurück, was die Untersuchung auf die Weiterleitung der Gegenstelle und ihre eigene Policy verlagert. Die IKEv2-Konfigurationsdokumentation von strongSwan behandelt den Child-SA-Lebenszyklus und das Rekey-Timing hinter diesen Zahlen.

Der Beobachtungspunkt ist eine eigene Variable, getrennt vom Ursprung des Pakets. Ein Hardware-Offload kann die Zähler der Assoziation hochzählen, während eine Software-Aufzeichnung an der Schnittstelle nichts zeigt, weil ausgelagerte Pakete den Hook überspringen, auf dem die Aufzeichnung sitzt, und beim Ingress kann es genauso auseinanderlaufen. Wenn beide nicht übereinstimmen, beantworten Sie mit den Zählern, ob etwas gepasst hat, und mit der Aufzeichnung, wie das Paket aussah.

Route, Selektoren und wo das Paket entstanden ist

Vergleichen Sie drei Dinge nebeneinander: die Route, die der Kernel für Ihr Ziel wählt, die Policy, die Verkehr in den Tunnel lenkt, und das Selektorpaar, das das Child ausgehandelt hat. ip route get 10.2.0.9 from 10.1.0.5 nennt die Schnittstelle und die Quelle, die der Kernel verwenden würde, und das ist oft nicht das Paar, das Sie angenommen haben. ip xfrm policy zeigt die lokal installierten Vorlagen und Selektoren, während swanctl --list-sas zeigt, worauf sich die Gegenstelle geeinigt hat. Eine Suche, die das Paket über die physische Schnittstelle hinausschickt, erreicht die Policy überhaupt nicht, also können sich die Zähler nicht bewegen.

Fehlanpassungen gibt es in mehreren Varianten, die von einem Zähler aus identisch aussehen. Ein IPv6-Ziel außerhalb eines IPv4-Selektors, eine Quelladresse aus dem falschen Subnetz und eine Policy, die enger ist als das Child, erzeugen alle dasselbe Null. Beheben Sie zuerst die engste Ursache, denn einen Selektor nur zu verbreitern, um eine Zahl zu verschieben, ändert, was der Tunnel schützt.

Dann ist da noch der Ursprung des Pakets, die Falle, die ein Gateway seinem eigenen Bediener stellt. Verkehr, den das Gateway selbst erzeugt, wird gegen die Output-Policy geprüft, während ein Paket, das es für einen Client weiterleitet, gegen die Forward-Policy geprüft wird, also kann ein Ping von der Box auf einem Pfad gelingen, den kein Client je nimmt.

Eine umkehrbare Änderung und ein Bericht, der der Prüfung standhält

Ändern Sie ein einziges Element, wiederholen Sie die identische Anfrage und lesen Sie dieselben Zähler. Alle Firewall-Regeln zu löschen oder alle Selektoren auf einmal zu ersetzen verschiebt eine Zahl und zerstört den Beweis, der Ihnen gesagt hat, warum. Zeigt der zweite Lauf weiterhin null, haben Sie eine Hypothese ausgeschlossen, statt den Nachmittag zu verschwenden.

Schreiben Sie den Befund so auf, dass ihn jemand reproduzieren kann: Name des Child, akzeptierte Bereiche, die festgelegte Quelle, das getestete Ziel, die Richtung, die bei null blieb, und das SPI, das Sie gelesen haben. Dieser Satz trennt eine Assoziation, die niemand genutzt hat, von einer entfernten Anwendung, die den Verkehr erhielt und ablehnte. Nehmen Sie die Änderung zurück, wenn sie die Zähler nicht bewegt hat, und behalten Sie den Eintrag; die nächste Person beginnt dort, wo Sie aufgehört haben. Nichts am Tunnel musste dafür neu aufgebaut werden, und genau darum geht es, wenn man das Matching prüft, bevor man die Konfiguration anfasst.