Ein geladenes strongSwan-Profil ist kein aktiver Tunnel

Eine Verbindung in der strongSwan-Konfiguration aufzulisten beweist nur, dass eine Definition geladen wurde. Es bedeutet nicht, dass der Peer kontaktiert wurde, dass eine IKE-SA existiert oder dass irgendein Datenverkehr geschützt ist. Der Daemon behandelt Definitionen und aktive Assoziationen als getrennte Objekte, und der Abstand dazwischen ist eine bewusste Designentscheidung. Zu wissen, welches Objekt man gerade prüft, macht aus einem vagen Fehlerbild einen konkreten nächsten Befehl.

Laden ist nicht Verbinden

Eine geladene Verbindung ist eine Aussage darüber, was später ausgehandelt werden kann: Peer-Adressen, Anmeldedaten, Vorschläge und Traffic Selectors. Nichts in dieser Aussage verlangt, dass der Daemon jemanden angerufen hat. Ein Gateway kann auf die Gegenseite warten, beim Start selbst initiieren oder auf passenden Datenverkehr warten, der es weckt. Alle drei Varianten sind gültig, und alle drei sehen in der Konfigurationsdatei gleich aus, bis man die Start-Richtlinie liest.

Betreiber geraten in Schwierigkeiten, wenn sie die Definitionsliste als Statusliste lesen. Das Profil ist da, also gilt der Tunnel als aufgebaut, und die nächste Stunde fließt in die Fehlersuche an Routen für eine Assoziation, die nie errichtet wurde.

Der umgekehrte Fehler ist genauso verbreitet. Ein fehlendes Profil schickt Leute auf die Suche nach einem Netzwerkfehler, obwohl die Konfiguration nie geladen wurde. Benennen Sie das Objekt und führen Sie dann den Befehl aus, der es beobachtet.

Drei Objekte, drei Beobachtungen

strongSwan hält eine geladene Definition, eine IKE-SA und eine CHILD-SA. Die erste ist Konfiguration, die zweite eine authentifizierte Steuerbeziehung, und die dritte ausgehandelter Schutz für ausgewählten Datenverkehr. Sie haben sogar eigene Namen, sodass ein Profil namens hq ein Child namens hq-lan besitzen kann.

Die Tabelle ordnet jeder Ebene den Befehl zu, der sie anzeigt. Lesen Sie die Zeile, bevor Sie das Protokoll lesen.

Das Anfordern des Child baut zuerst seine übergeordnete IKE-SA auf, wenn keine existiert. Nur die IKE-SA anzufordern ist ein anderer Aufruf. Ein Steuerkanal, der sauber authentifiziert, garantiert nicht das Child, das Sie angefordert haben.

Dieser Unterschied zählt bei einem Teilausfall. Eine IKE-SA kann gesund sein, während das Child an einer Selektor-Abweichung oder einem Vorschlag scheitert, den der Peer nicht akzeptiert. Die beiden Objekte scheitern aus unterschiedlichen Gründen, deshalb verdienen sie getrennte Beobachtungen.

Wählen Sie die Startaktion bewusst

In swanctl.conf entscheidet start_action eines Child über das Verhalten nach dem Laden. Der Standard none überlässt die Definition der manuellen Initiierung oder der Nutzung als Responder. start wählt die Verbindung, während trap eine Richtlinie hinterlässt, die aushandelt, sobald passender Datenverkehr auftaucht.

Also sind sowohl „Laden startet nie einen Tunnel“ als auch „Laden startet immer einen“ falsch. Die Aktion ist Teil des Profils und sollte zur Rolle des Peers passen. Zwei Gateways, die beide auf die Gegenseite warten, erzeugen Stille, keinen Tunnel.

Bei trap muss der Datenverkehr zu den Selektoren passen, ein unabhängiger Ping weckt also nichts. Bei start muss die Peer-Adresse nutzbar sein und beide Seiten müssen sich über Authentifizierung und Vorschläge einig sein. Keine der beiden Aktionen ersetzt die Prüfung dieser Voraussetzungen.

Wiederherstellung ist eine eigene Richtlinie

Der Start ist kein Keepalive. Dead-Peer-Erkennung, ausdrückliches Schließen durch den Peer, Rekeying und ein Prozessneustart sind verschiedene Lebenszyklus-Ereignisse mit eigenen Einstellungen. Konfigurieren Sie jedes davon bewusst, statt zu erwarten, dass ein anfänglicher Start alle abdeckt.

Ein Tunnel, der beim Booten hochkommt und eine Stunde später stirbt, ist eine Frage der Wiederherstellung. Die Start-Richtlinie hat ihre Aufgabe erfüllt und danach aufgehört zu zählen. Prüfen Sie DPD- und Rekey-Einstellungen, bevor Sie die anfängliche Aushandlung beschuldigen.

Geladene Definitionen zu ersetzen ist eine eigene Operation. Nicht standardmäßige Start-Richtlinien haben dokumentierte Gegenaktionen, und ein Reload ist eine betriebliche Änderung statt der Annahme, jede Assoziation sei an Ort und Stelle aktualisiert worden. Führen Sie Reloads in Phasen durch, in denen eine Neuverbindung akzeptabel ist. Behalten Sie die alte Konfiguration, bis die neue bewiesen ist.

Prüfen Sie, was existiert, bevor Sie Routing debuggen

Führen Sie die drei Beobachtungen der Reihe nach aus: geladene Definitionen, aktive IKE-SAs und Child-Einträge. Jede Antwort verengt die nächste Frage. Lassen Sie einen Schritt aus, und Sie debuggen am Ende eine Ebene, die nie errichtet wurde.

Beginnen Sie mit dem, was geladen ist, und dem, was tatsächlich aufgebaut ist:

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

Fehlt das Child, während das Profil korrekt ist, initiieren Sie es per Namen und beobachten Sie, was passiert. Die Ausgabe sagt meist, ob zuerst die übergeordnete Verbindung hochkam.

swanctl --initiate --child hq-lan

Eine aktive CHILD-SA ist nicht die Ziellinie. Weiterleitungsregeln, Routen und die eigene Autorisierung der Anwendung müssen weiterhin zusammenpassen. Der Lebenszyklus beantwortet, was ausgehandelt wurde; er kann nicht entscheiden, wer den Dienst nutzen darf.