Eins oben, null verbindend: was diese strongSwan-Zeile zählt

Liest man eine Statuszeile mit Security Associations (1 up, 0 connecting), sieht sie wie ein Bericht über einen funktionierenden Tunnel aus. Zwei Subnetze leiten gleichzeitig Verkehr hindurch, also scheint die Zahl zu lügen. Sie lügt nicht; sie zählt IKE-Assoziationen, und eine davon kann mehrere Kinder beherbergen. Lies die Inventare, bevor du einen Vorschlag oder eine Route anfasst.

Warum Kopfzeile und Verkehr nicht übereinstimmen

Die alte stroke-Ausgabe bezeichnet ihre Summe als Sicherheitsassoziationen und leitet sie vom IKE-Assoziationsmanager ab. Jede aufgebaute IKE-Assoziation trägt eine bei, unabhängig davon, wie viele CHILD SA darunter liegen. Ein einzelner IKEv2-Elternteil trägt üblicherweise mehrere Kinder, eines pro Verkehrsselektorpaar, und die ausgehandelten Selektoren eines Kindes können mehr als eine Adresse oder ein Präfix abdecken. Die Zahl der Adressen in deiner Konfiguration hat daher keine feste Beziehung zur Zahl in der Kopfzeile.

Moderne Ausgaben zeigen manchmal eine Summe statt der alten Formulierung “up”, und ein swanctl-verwalteter Daemon wird überhaupt nicht von alten stroke-Einstellungen gesteuert. Nimm weder die Formulierung noch die Zählregel über Versionen hinweg als gegeben an.

Vergleiche drei Inventare, bevor du etwas änderst

Beginne mit dem, was geladen ist, dann mit dem, was ausgehandelt ist, dann mit dem, was tatsächlich Pakete bewegt. Das sind drei verschiedene Fragen, und jede hat ihren eigenen Befehl.

swanctl --list-conns
swanctl --list-sas

Die erste listet Verbindungsdefinitionen auf, die der Daemon akzeptiert hat. Die zweite listet aufgebaute IKE-Assoziationen mit ihren Kindern auf, und dort erscheint die eigentliche Hierarchie. Eine Definition, die in einer Datei steht, aber in der ersten Liste fehlt, wurde nie geladen, und keine Anzahl von Wiederholungen des Initiators behebt das. Wenn du stattdessen die alte Schnittstelle betreibst, ist das entsprechende Paar ipsec statusall und dieselbe swanctl-Liste, je nachdem welches Plugin die Konfiguration besitzt. Mische keine Werkzeuge zwischen zwei Daemons auf einem Host und erwarte keine einheitliche Antwort.

swanctl --list-sas --raw | head -40
ip -s xfrm state

Die Rohform hält Identifikatoren und Selektoren zum Vergleich sichtbar, und die Kernel-Zustandsliste zeigt, was der Stack installiert zu haben glaubt. Wenn Daemon und Kernel nicht übereinstimmen, wurde der Daemon um ein bestehendes Kind herum neu gestartet oder das Kernel-Objekt wurde darunter entfernt.

Lies die Hierarchie, nicht die Summe

Ein beispielhafter aufgebauter Elternteil mit zwei Kindern sieht wie ein Knoten mit zwei Kindern darunter aus, jedes mit eigenem Zustand und Modus beschriftet. Gib die tatsächliche Ausgabe aus und zähle die Kinder selbst, statt eine Zusammenfassung zu lesen, die jemand aus einem Dashboard eingefügt hat.

swanctl --list-sas
swanctl --list-conns --raw | grep -A4 'accounting'

Ein Elternteil mit zwei installierten Kindern ist ein gesunder Tunnel für zwei Subnetze. Ein Elternteil mit einem installierten und einem fehlenden Kind ist eine andere Situation, und die Selektoren des fehlenden Kindes sind das, was mit dem Vorschlag der Gegenseite zu vergleichen ist. Während einer Schlüsselerneuerung können ein altes Kind und sein Ersatz kurzzeitig beide erscheinen. Bewahre den Zeitstempel zusammen mit der Momentaufnahme auf, denn eine Zählung mitten in der Erneuerung sieht wie Duplizierung aus und eine danach wie Verlust.

Geladen, installiert und Verkehr, der durchgeht

Ein Kind im installierten Zustand hat ausgehandelte Parameter und einen Kernel-Eintrag. Es hat aber nicht zwangsläufig ein Paket befördert: Selektoren können enger sein als der erwartete Verkehr, und eine Route kann diesen Verkehr woanders hinschicken, bevor der Tunnel ihn überhaupt sieht. Sende einen Fluss, der zu den ausgehandelten Selektoren passt, von einem autorisierten Host und lies dann die Zähler des Kindes statt der Kopfzeile. Ein Zähler, der bei null bleibt, während du passenden Verkehr erzeugst, deutet auf Routing oder Policy hin, nicht auf IKE.

swanctl --initiate --child accounting
swanctl --list-sas --raw | grep -E 'bytes|packets'

Ein benanntes Kind zu starten ist eine bewusste Handlung mit sichtbarem Ergebnis, und sie trennt “die Verbindung ist untätig, weil niemand gefragt hat” von “die Verbindung kann nicht hochkommen”. Eine Trap-Policy auf Anforderung verhält sich genau wie der erste Fall, also lies die Starteinstellung der Verbindung, bevor du es einen Fehler nennst.

Wenn die Zählung wirklich falsch ist

Fehlt eine Definition im geladenen Inventar, sieh dir das Laden der Konfiguration und die laufende Daemon-Instanz an. Ist sie geladen, verhandelt aber nie, vergleiche Vorschläge, Authentifizierungskontext und Selektoren mit der Gegenseite, ein Kind nach dem anderen. Ändere pro Versuch ein Element und notiere die geänderte Kennung. Einen Vorschlag zurückzurollen ist trivial, wenn man weiß welchen; es ist Raten nach drei Änderungen, die nie getrennt wurden.

Korrigiere zuerst die Fehlinterpretation. Die meisten Berichte über einen “fehlenden” zweiten Tunnel enden mit zwei installierten Kindern unter einem Elternteil, und das Einzige, was je kaputt war, war die Zusammenfassungszeile, der die Leute statt der Hierarchie vertrauten.