ipsec.conf oder swanctl.conf? Wählen Sie ein strongSwan-Frontend

Ein funktionierendes IKEv1-Profil aus einer älteren Anleitung landet auf Ubuntu 24.04, und der erste Versuch scheitert, weil der Daemon die Datei nie gelesen hat. Die übliche Reaktion ist, das Profil erneut zu bearbeiten. Die eigentliche Frage ist, welches strongSwan-Frontend installiert ist und welches der laufende Dienst verwendet. Bis das geklärt ist, zielt jede Bearbeitung auf einen Loader, den es vielleicht nicht gibt.

Zwei Dateien, zwei Loader, ein Daemon

Die alte Starter-Anordnung liest ipsec.conf und übergibt Verbindungen über ihre alte Verwaltungsintegration an charon. Ihr betrieblicher Einstiegspunkt ist der Befehl ipsec.

Die swanctl-Anordnung lädt Definitionen über VICI, liest swanctl.conf und wird vom Befehl swanctl gesteuert. Der systemd-native charon-Daemon ist in diesen Ansatz integriert.

Beide können auf derselben Maschine installiert sein, und genau dort beginnt die Verwirrung. Eine Datei unter /etc beweist nur, dass jemand sie geschrieben hat, nicht dass der laufende Prozess sie geladen hat. Alle Alternativen zu installieren, um zu sehen, welche funktioniert, erzeugt einen Host mit zwei Verwaltungswegen und ohne klaren Eigentümer. Wählen Sie eine Anordnung und entfernen oder deaktivieren Sie die andere.

Lesen Sie die installierten Pakete und Units

Beginnen Sie schreibgeschützt. Die Paketnamen auf Ubuntu 24.04 sind getrennt: strongswan-starter, strongswan-swanctl und charon-systemd. Ein fehlendes Paket ist eine nützliche Information, keine Anweisung, es zu installieren.

Erfassen Sie die Pakete und die Units in einem Durchgang:

dpkg-query -W strongswan-starter strongswan-swanctl charon-systemd
systemctl list-unit-files '*strongswan*'

Untersuchen Sie dann die aktive Unit und ihren Startbefehl. Der Unit-Name verrät, welcher Daemon die Konfiguration besitzt, und die Befehlszeile bestätigt, welche Dateien gelesen werden sollten. Eine Unit, die aktiviert, aber inaktiv ist, erzählt eine andere Geschichte als eine, die gerade läuft.

Ist die aktive Unit strongswan-starter, ist ipsec.conf die entscheidende Datei. Ist es charon-systemd mit swanctl, ist ipsec.conf reine Dekoration.

Nutzen Sie den passenden Steuerungsweg

Jedes Frontend hat seine eigene Sicht auf Verbindungen und Assoziationen. swanctl --list-conns zeigt geladene Definitionen, und swanctl --list-sas zeigt aktive Assoziationen. Der alte Weg nutzt ipsec statusall.

Ihre Vermischung erzeugt irreführende Fehler. Ein fehlender VICI-Socket oder eine abgelehnte Steuerungsanfrage ist ein Problem des Verwaltungswegs, kein Beleg dafür, dass die Gegenstelle die Authentifizierung abgelehnt hat.

Lesen Sie die Sicht, die zum laufenden Daemon gehört, und interpretieren Sie dann das Ergebnis. Fehlt die Verbindung in dieser Sicht, liegt das Problem beim Laden, nicht bei der Aushandlung.

Format ist nicht die IKE-Version

Ein altes Profil wählt IKEv1 mit keyexchange=ikev1. Eine swanctl-Verbindung verwendet eine Versionsangabe, wobei 1 IKEv1 auswählt. Das sind zwei Vokabulare für dieselbe Idee, keine Umwandlung.

Peer-Adressen, lokale und entfernte Identitäten, Anmeldedatenquellen, Vorschläge und Child-Selektoren müssen bewusst zugeordnet werden. Einen left/right-Block in die swanctl-Syntax zu kopieren, leistet nichts davon.

Nur die Protokollversion zu ändern ist die häufigste halbe Migration. Sie erzeugt eine Datei, die lädt und dann aus Gründen, die nichts mit der Version zu tun haben, die Authentifizierung verfehlt. IKEv1 selbst ist durch RFC 9395 veraltet, daher verdient eine bestehende Gegenstelle, die es noch verlangt, eine dokumentierte Kompatibilitätsbedingung und einen Migrationspfad, keine neue Voreinstellung.

Prüfen Sie den Loader, bevor Sie das Profil anfassen

Führen Sie zuerst die Loader-Prüfung aus, laden Sie dann die gewünschte Verbindung, bewerten Sie dann die Aushandlung und danach den geschützten Verkehrsweg. Jede Stufe hat eine andere Fehlersignatur.

Die beiden Steuerungswege beantworten die Ladefrage direkt:

swanctl --list-conns
ipsec statusall

Nur einer dieser Befehle gehört zu Ihrem Host. Beide auszuführen und die Ausgabe zu vergleichen ist ein Weg herauszufinden, welcher Sie anlügt, keine Diagnosemethode.

Behandeln Sie Paketeigentum, Konfigurationsladen und Protokollkompatibilität als drei getrennte Fragen. Eine Datei, die für ein Frontend gültig ist, wird sonst immer wieder bearbeitet, während ein anderer Daemon läuft.