strongSwan-Trap-Modus: Warum der IPsec-Tunnel auf Verkehr wartet

Ein inaktiver On-Demand-IPsec-Tunnel zeigt kein CHILD SA, bis ein Paket zu seiner Trap-Richtlinie passt. Lesen Sie den Zustand, prüfen Sie den Auslöser und wissen Sie, wann start passt.

Im Status-Output erscheint kein CHILD SA, der Tunnel wirkt tot, und dann bringt ein Ping ins entfernte Subnetz ihn hoch. In einem On-Demand-IPsec-Setup ist diese Reihenfolge das Design, kein Fehler. Eine Trap-Richtlinie installiert einen Selektor und wartet, und das erste passende Paket startet IKE und die CHILD-SA-Aushandlung.

Ein Teil der Verwirrung ist Vokabular: „up“ wird für zwei verschiedene Zustände verwendet. Die Konfiguration ist geladen und die Kernel-Richtlinie existiert, die Datenassoziation aber nicht. Ein Monitor, der nur aktive SAs zählt, meldet einen gesunden Standort als down, solange niemand Verkehr dorthin sendet.

Ein inaktiver On-Demand-Tunnel hat kein CHILD SA zu zeigen

Ein Trap-Eintrag authentifiziert für sich genommen nichts. Er bittet den Kernel, eine Richtlinie für den ausgewählten Verkehr zu halten und eine Acquisition auszulösen, wenn ein Paket diese Richtlinie braucht. Der Daemon empfängt die Acquisition, ordnet sie der child-Definition zu und verhandelt von dort. Bis dahin gibt es auch keine IKE SA anzuzeigen, weshalb beide Listen gleichzeitig leer sein können.

Diese Reihenfolge macht die Logs lesbar. Zuerst kommt die Acquisition, dann IKE_SA_INIT und IKE_AUTH, dann das CHILD SA. Endet das Log direkt nach der Acquisition, hat der Auslöser funktioniert. Die Aushandlung ist gescheitert, und die nächste Frage betrifft Anmeldedaten, Vorschläge oder Erreichbarkeit, nicht die Trap.

Mit dem Linux-Kernel-Backend sehen Sie die Richtlinie, bevor irgendein SA existiert. Führen Sie ip xfrm policy aus und suchen Sie den Selektor mit Richtung out und einer Vorlage, die auf die Verbindung zeigt. Dieser Eintrag ist der On-Demand-Zustand, und seine Existenz ist das Erste, was zu bestätigen ist.

start_action entscheidet, ob überhaupt etwas wartet

Jedes child in swanctl.conf trägt ein start_action. start startet beim Laden der Konfiguration, trap installiert die Richtlinie und wartet, und none überlässt den Start etwas anderem. Nur trap erzeugt das oben beschriebene Ping-und-es-kommt-hoch-Verhalten.

children {
    office-lan {
        local_ts = 192.168.50.0/24
        remote_ts = 192.168.70.0/24
        start_action = trap
    }
}

Die beiden Verkehrsselektoren definieren, was als interessant gilt, und ein Paket von einem Host außerhalb dieser Präfixe löst die Trap nicht aus; es wird wie gewohnt geroutet. Die Selektoren zu erweitern, damit der Auslöser eifriger wird, erweitert auch den Bereich, den der Tunnel zu schützen behauptet, also leiten Sie sie aus Verkehr ab, den Sie wirklich verschlüsseln wollen.

Die swanctl.conf-Referenz listet die akzeptierten Werte auf, zusammen mit den separaten close- und DPD-Aktionen, die regeln, was passiert, sobald die SA existiert.

Finden Sie heraus, ob der Auslöser überhaupt ausgelöst hat

Beginnen Sie mit swanctl --list-conns und bestätigen Sie, dass das child mit der beabsichtigten Aktion geladen ist. Senden Sie dann ein Paket von einem Host innerhalb von local_ts an eine Adresse innerhalb von remote_ts und beobachten Sie swanctl --list-sas. Ändert sich die Ausgabe nicht, hat keine Acquisition den Daemon erreicht.

Zwei gewöhnliche Gründe für eine stille Trap: Das Paket wurde source-NATet, bevor es die Richtlinie traf, und passt nicht mehr zu local_ts, oder die Verbindung wurde wegen eines Syntax- oder Anmeldefehlers nie geladen. Führen Sie swanctl --load-all erneut aus und lesen Sie die Ausgabe, bevor Sie Selektoren anfassen. Eine Verbindung, die nicht geladen wurde, installiert keine Richtlinie, es gibt also nichts, was Verkehr auslösen könnte.

Auch die Richtung zählt: Eine für ausgehenden Verkehr installierte Trap startet nicht bei einem eingehenden Paket. Soll die Gegenseite den Tunnel hochbringen, braucht sie ihre eigene Trap, oder diese Seite braucht start.

Auf das erste Paket zu warten ist nicht immer der richtige Tausch

Interaktive Sitzungen spüren die Einrichtungskosten. Die erste Anfrage zahlt für den IKE-Austausch und die CHILD-Aushandlung, und ein Client mit knapper Frist kann aufgeben, bevor die SA existiert. Proaktives start beseitigt diese Verzögerung beim ersten Paket. Es hält aber einen Tunnel für Verkehr offen, der vielleicht nie ankommt.

Drei Fakten entscheiden die Wahl: wie oft der Pfad genutzt wird, ob die erste Anfrage eine enge Frist hat und ob der Peer beim Boot erreichbar ist. Gelegentlicher Batch-Verkehr und ein beim Boot möglicherweise offline befindlicher Peer sprechen beide für trap. Ein latenzempfindlicher Client und ein immer erreichbarer Peer sprechen für start. Können beide Seiten initiieren, einigen Sie sich, wer den Auslöser besitzt, damit keine doppelten Aushandlungen entstehen.

Eine installierte Richtlinie ist auch keine auslaufsichere Garantie. Ist die Anforderung fail-closed, muss die Firewall Verkehr ohne SA verwerfen, und diese Regel lebt außerhalb der child-Definition.

Notieren Sie die drei Zeilen, die die nächste Diskussion beenden

Schreiben Sie die Selektoren, die Startaktion und die Kommandoausgabe auf, die die Richtlinie ohne SA als vorhanden zeigt. Diese drei Zeilen trennen „on demand und inaktiv“ von „lädt nicht“, wenn jemand den Tunnel das nächste Mal als down meldet. Sie brauchen eine Minute. Ohne sie beginnt dieselbe Untersuchung bei null.

Testen Sie von einem Host, der wirklich innerhalb des Selektors liegt. Ein Ping vom Router selbst folgt oft einem anderen Pfad und beweist nichts über die Richtlinie, die das Subnetz dahinter schützt.

Ähnliche Artikel