IPsec-Tunnel-Schnittstelle überwachen: Was Sie ablesen sollten

Ein routenbasiertes IPsec-Design installiert eine virtuelle Schnittstelle, und diese Schnittstelle gibt dem Monitoring ein konkretes Objekt: eines mit einem Namen, Zählern und einer daran gebundenen Route. Das allein ist noch kein Gesundheitsindikator. Die Schnittstelle kann existieren, während keine nutzbare Assoziation installiert ist, und eine Assoziation kann gesund sein, während keine Route den interessierenden Verkehr an sie schickt. Erst vier Zustände gemeinsam zu lesen macht aus einem Paketzähler eine Diagnose.

Arbeiten Sie sie der Reihe nach durch und halten Sie beim ersten Zustand an, der fehlschlägt.

Was die Schnittstelle zum Bild beiträgt

Bei einem richtlinienbasierten Design lebt die Auswahl in der IPsec-Richtlinientabelle, und der Kernel entscheidet anhand von Traffic-Selectors, was geschützt wird. Ein routenbasiertes Design fügt eine Schnittstelle und eine Route hinzu, sodass tcpdump und Schnittstellenzähler eine Grenze sehen statt einer Menge von Selectors. Das ist ein echter Gewinn für die Diagnose und für Routing-Protokolle, die eine Schnittstelle zum Peering benötigen.

Der Gewinn ist administrativer, nicht kryptografischer Natur. Die Schnittstelle berichtet über den Verkehr, den sie trägt, und sagt nichts darüber aus, ob der Schutz des Peers derzeit nutzbar ist.

Die vier Zustände lesen, bevor der Tunnel beschuldigt wird

Beginnen Sie mit der Schnittstelle und der Route, dann mit der Assoziation, dann mit der Anwendung. Jede hat ihren eigenen Befehl und ihre eigene Fehlersignatur. Ein sauberes Ergebnis auf einer Ebene ist kein sauberes Ergebnis auf der nächsten. Führen Sie alle vier aus, bevor Sie eine Schlussfolgerung ziehen. Eine grüne Zeile klärt selten etwas.

ip -s link show xfrm0
ip route get 10.20.30.40
ip xfrm state
ip xfrm policy
swanctl --list-sas
tcpdump -ni xfrm0 -c 20 host 10.20.30.40

Eine Schnittstelle mit steigendem Zähler, aber ohne passenden State-Eintrag beschreibt Verkehr, der in einen Pfad gelangt, in dem nichts ihn schützt, was schlimmer ist als ein Tunnel, der einfach ausgefallen ist. Ein State-Eintrag ohne Route, die auf die Schnittstelle zeigt, bedeutet, dass die Kryptografie bereit und ungenutzt ist.

Der Anwendungstest kommt bewusst zuletzt: Ein erfolgreicher Ping auf die Gegenseite des Tunnels beweist nicht, dass der dahinterliegende Dienst Verbindungen annimmt.

Innere Zähler mit äußeren Zählern vergleichen

Zähler auf der Tunnel-Schnittstelle messen den inneren Verkehr; Zähler und Mitschnitte auf der physischen Schnittstelle zeigen den gekapselten Austausch. Die beiden werden nicht eins zu eins übereinstimmen, weil Kapselung Header hinzufügt, Neuübertragungen manche Pakete duplizieren und die Abrechnung der Implementierung eigenen Regeln folgt. Erwarten Sie ein Verhältnis, keine Gleichheit.

Die Platzierung des Mitschnitts entscheidet auch darüber, welche privaten Daten Sie sammeln, also verwenden Sie enge Filter und eine harmlose Testadresse statt eines vollständigen Mitschnitts des Produktionsverkehrs.

Wenn die inneren Zähler steigen und die äußeren nicht, fehlt meist die Route oder die Richtlinie, die Pakete in den Tunnel schickt, nicht der Tunnel selbst.

Durch Rekey und Failover beobachten

Beobachten Sie einen Rekey, ein Dead-Peer-Detection-Ereignis und ein Link-Failover, während Sie dieselben vier Zustände im Blick behalten. Eine Schnittstelle kann einen Rekey überdauern, der nie abgeschlossen wird, und ein Failover kann einen State-Eintrag auf eine Peer-Adresse zeigen lassen, die nicht mehr erreichbar ist.

Alarmieren Sie auf den Dienstpfad, auf den Sie tatsächlich angewiesen sind, mit dem Assoziationszustand als Kontext, statt auf ein einzelnes Up-oder-Down-Flag. Halten Sie Schnittstellenname, Peer-Adresse und Route im Alarm-Payload fest, damit der Responder sie nicht rekonstruieren muss.

strongSwan dokumentiert sein eigenes XFRM-Schnittstellenmodell, und andere Plattformen benennen und implementieren das entsprechende Objekt anders. Lesen Sie den routenbasierten Vergleich für das Gerät, das vor Ihnen steht, bevor Sie Annahmen aus einer anderen Implementierung übertragen. Eine Monitoring-Vorlage, die zu den Zählern eines Herstellers passt, führt bei einem anderen still in die Irre.