Warum tcpdump IPsec-Klartext nur in eine Richtung anzeigt

Sie führen tcpdump auf der Außenschnittstelle eines Linux-IPsec-Gateways aus und sehen zwei Dinge gleichzeitig: eingehende ESP-Frames und direkt danach die entschlüsselten inneren Pakete. Ausgehend erscheint nur ESP. Die naheliegende Schlussfolgerung ist, dass keine Antworten gesendet werden oder dass IPsec eine Richtung verschlüsselt und die andere vergisst. Beides ist nicht wahr.

Was Sie sehen, ist ein Erfassungspunkt. Der Kernel wandelt ausgehende Pakete um, bevor der Sendepfad des Geräts sie dem Paket-Socket übergibt, sodass der Socket die innere Form beim Hinausgehen nie sieht. Eingehend wird das Paket zuerst als ESP erfasst, und die entkapselte Kopie wird sichtbar, wenn sie wieder in den Stack gelangt. Derselbe Verkehr, zwei verschiedene Beobachtungsfenster.

Der Erfassungspunkt entscheidet, was Sie sehen

Auf einer normalen Schnittstelle sitzt ein AF_PACKET-Socket nahe der Geräteschicht. Pakete, die den Host verlassen, durchlaufen zuerst die IPsec-Ausgangsverarbeitung, die ein inneres TCP-Segment in ein ESP- oder UDP-4500-Datagramm umwandelt, und erreichen erst danach diese Schicht. Ankommende Pakete werden in den Socket kopiert, während sie von der Leitung kommen, noch verschlüsselt, und das entschlüsselte Ergebnis wird später sichtbar, wenn der Stack es lokal zustellt oder weiterleitet.

Diese Reihenfolge erklärt die Asymmetrie vollständig. Sie ist kein Beleg über Richtung, Richtlinie oder Anwendungsverhalten, und wer sie so behandelt, jagt einer Antwort nach, die die ganze Zeit korrekt gesendet wurde. Es ist eines der wenigen Netzwerkrätsel, bei denen das Instrument und nicht das Netzwerk die Anomalie erzeugt.

Passen Sie den Filter an die gemeinte Schicht an

Ein Ausdruck wie tcp port 443 wählt eine innere TCP-Verbindung aus. Ausgehend ist diese Verbindung bereits ESP, wenn der Socket befragt wird, sodass der Filter nichts trifft. Wenn Sie geschützten Verkehr zählen wollen, filtern Sie stattdessen auf die äußere Form: Protokoll 50 für rohes ESP oder UDP-Port 4500, wenn NAT-Traversal im Spiel ist. Beide Filter liefern eine Paketzahl, die zwischen den beiden Peers verglichen werden kann, was meist der Grund für das Zählen ist. Keiner von beiden sagt Ihnen, ob die innere Anfrage beantwortet wurde.

Behandeln Sie eine UDP-4500-Zählung nicht als ESP-Paketzahl. IKE nutzt diesen Port auch für NAT-T-Keepalives und für den gekapselten Austausch, sodass die Zahl Verkehr enthält, der nicht die Daten sind, die Sie messen wollten. Der anfängliche IKE-Austausch auf UDP 500 braucht einen eigenen Filter, wenn das die Frage ist. Eine Zahl, die Steuerverkehr mit Daten vermischt, macht außerdem jede Bandbreitenschätzung um einen unbekannten Betrag falsch. Getrennte Zählungen beantworten getrennte Fragen.

Schreiben Sie den Filter neben die Frage, die er beantwortet. „Wie viel ESP hat die Box verlassen“ und „hat die Webanfrage die Box verlassen“ sind verschiedene Messungen mit verschiedenen Filtern, und eine Erfassung kann nicht beides klären. Ohne diese Notiz vergleichen zwei Personen Zahlen, die nie dasselbe gezählt haben.

Vor der Umwandlung beobachten, nicht danach

Wenn Sie ausgehenden Klartext sehen müssen, verschieben Sie den Beobachtungspunkt nach früher, vor die IPsec-Ausgangsverarbeitung. NFLOG gibt Ihnen einen Netfilter-Hook, an dem eine Regel ausgewählte Pakete in einen Socket im Userspace kopieren kann, den tcpdump lesen kann. Der Traffic-Dump-Leitfaden von strongSwan dokumentiert genau diesen Ansatz aus genau diesem Grund.

Die Richtlinienübereinstimmung beschränkt die Regel auf Verkehr, der gerade in einen Tunnel eintreten soll. -m policy --pol ipsec --dir out ist das, was die Regel spezifisch macht, statt jedes Paket zu protokollieren, das die Box sendet. Lesen Sie dann die Loggruppe mit einer begrenzten Erfassung: eine kleine Snapshot-Zahl und ein Größenlimit verhindern, dass die Diagnose zu einem Verkehrsarchiv wird. Eine begrenzte Erfassung lässt sich auch leichter an einen Prüfer übergeben, ohne unnötige Nutzlast mitzuschleppen. Legen Sie die Zahl vor dem Start fest, nicht danach, wie viel angekommen ist.

iptables -I OUTPUT 1 -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5
tcpdump -ni nflog:5 -s 128 -c 20 'host 10.83.0.44 and tcp port 8443'

Wählen Sie den Hook passend zum Fluss. OUTPUT deckt Verkehr ab, den das Gateway selbst erzeugt; Transit von einem LAN-Client durchläuft stattdessen die Kette FORWARD, und eine Regel auf OUTPUT wird ihn nie sehen. Adresse und Port oben sind Platzhalter für ein genehmigtes Testziel.

Was die Beobachtung beweist

NFLOG ist ein Protokollierungsziel, keine Annahmeentscheidung. Ein Paket, das dort erscheint, zeigt, dass es den Hook erreicht und die Regel getroffen hat. Es zeigt nicht, dass ein späterer Filter es zugelassen hat, dass das Gerät es gesendet hat oder dass der Peer etwas empfangen hat.

Ein leeres Protokoll ist ebenso mehrdeutig. Prüfen Sie den Paketzähler der Regel, bestätigen Sie die Richtung, bestätigen Sie, dass der Fluss tatsächlich einer IPsec-Richtlinie entsprach, und bestätigen Sie das Ziel. Nur ein übereinstimmender Zähler auf beiden Peers macht aus einer Beobachtung eine Schlussfolgerung. Vergleichen Sie dann die Zähler der Sicherheitsassoziation auf beiden Peers für denselben kontrollierten Versuch, denn die SA-Zähler sind der maßgebliche Nachweis darüber, was geschützt und gesendet wurde.

Noch eine Falle: „Klartext“ bedeutet in diesem Zusammenhang außerhalb der IPsec-Verschlüsselungsschicht. Eine innere HTTPS-Sitzung hat weiterhin ihr eigenes TLS. Das Erfassen des entkapselten Pakets entschlüsselt nicht das TLS der Anwendung, und lesbares HTTP dort bedeutet, dass die Anwendung nie HTTPS verwendet hat.

Aufräumen und beide Enden vergleichen

Entfernen Sie die genaue Regel, die Sie eingefügt haben, durch ihren Eigentümer, sobald die Beobachtung beendet ist. Eine stehen gelassene Protokollierungsregel kostet CPU bei jedem passenden Paket und schafft still ein Problem mit der Datenaufbewahrung. Löschen Sie, indem Sie die Regel mit -D wiederholen, statt eine Kette zu leeren, die Ihnen nicht gehört.

iptables -D OUTPUT -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5

Wenn die Bereitstellung IPsec im Userspace, eine XFRM-Schnittstelle oder Hardware-Offload verwendet, verschieben sich die Beobachtungspunkte, und dieses Rezept gilt möglicherweise gar nicht. Bei libipsec ist der dokumentierte Ort zur Beobachtung inneren Verkehrs das TUN-Gerät. Identifizieren Sie zuerst den Pfad, wählen Sie dann den Punkt, der die Frage beantwortet, und erwarten Sie, dass die beiden Richtungen nur dann unterschiedlich aussehen, wenn Sie auf die falsche Seite der Umwandlung schauen.