ipsec.conf of swanctl.conf? Kies één strongSwan-frontend

Een werkend IKEv1-profiel uit een oudere handleiding belandt op Ubuntu 24.04, en de eerste poging mislukt omdat de daemon het bestand nooit heeft gelezen. De gebruikelijke reactie is het profiel opnieuw bewerken. De echte vraag is welke strongSwan-frontend is geïnstalleerd en welke de draaiende dienst gebruikt. Tot dat is beantwoord, richt elke bewerking zich op een loader die misschien niet bestaat.

Twee bestanden, twee loaders, één daemon

De oude starter-opstelling leest ipsec.conf en geeft verbindingen aan charon via de oude beheerintegratie. Het operationele toegangspunt is de opdracht ipsec.

De swanctl-opstelling laadt definities via VICI, leest swanctl.conf en wordt aangestuurd door de opdracht swanctl. De systemd-eigen charon-daemon integreert met die aanpak.

Beide kunnen op dezelfde machine zijn geïnstalleerd, en daar begint de verwarring. Een bestand onder /etc bewijst alleen dat iemand het heeft geschreven, niet dat het draaiende proces het heeft geladen. Elk alternatief installeren om te zien welke werkt, levert een host op met twee beheerpaden en geen duidelijke eigenaar. Kies één opstelling en verwijder of schakel de andere uit.

Lees de geïnstalleerde pakketten en units

Begin alleen-lezen. De pakketnamen op Ubuntu 24.04 zijn apart: strongswan-starter, strongswan-swanctl en charon-systemd. Een ontbrekend pakket is nuttige informatie, geen opdracht om het te installeren.

Inventariseer de pakketten en de units in één ronde:

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

Onderzoek daarna de actieve unit en het opstartcommando. De unitnaam vertelt welke daemon de configuratie bezit, en de commandoregel bevestigt welke bestanden moesten worden gelezen. Een unit die is ingeschakeld maar niet actief is, vertelt een ander verhaal dan een die nu draait.

Als de actieve unit strongswan-starter is, is ipsec.conf het bestand dat ertoe doet. Als het charon-systemd met swanctl is, is ipsec.conf alleen versiering.

Gebruik het bijbehorende beheerpad

Elke frontend heeft zijn eigen beeld van verbindingen en associaties. swanctl --list-conns toont geladen definities en swanctl --list-sas toont actieve associaties. Het oude pad gebruikt ipsec statusall.

Ze door elkaar halen levert misleidende fouten op. Een ontbrekende VICI-socket of een geweigerd beheerverzoek is een probleem van het beheerpad, geen bewijs dat de tegenpartij de authenticatie heeft geweigerd.

Lees het beeld dat bij de draaiende daemon hoort, en interpreteer daarna het resultaat. Als de verbinding in dat beeld ontbreekt, is het probleem het laden, niet de onderhandeling.

Formaat is niet de IKE-versie

Een oud profiel kiest IKEv1 met keyexchange=ikev1. Een swanctl-verbinding gebruikt een versie-instelling, waarbij 1 IKEv1 kiest. Dat zijn twee woordenlijsten voor hetzelfde idee, geen conversie.

Adressen van de tegenpartij, lokale en externe identiteiten, bronnen van inloggegevens, voorstellen en child-selectors moeten met opzet worden toegewezen. Een left/right-blok in de swanctl-syntaxis plakken doet daar niets van.

Alleen de protocolversie wijzigen is de meest voorkomende halve migratie. Het levert een bestand op dat laadt en daarna niet authenticeert om redenen die niets met de versie te maken hebben. IKEv1 zelf is verouderd door RFC 9395, dus een bestaande tegenpartij die het nog vereist verdient een gedocumenteerde compatibiliteitsbeperking en een migratiepad, geen nieuwe standaard.

Controleer de loader voordat u het profiel aanraakt

Voer eerst de loadercontrole uit, laad daarna de bedoelde verbinding, beoordeel dan de onderhandeling en ten slotte het pad van beveiligd verkeer. Elke fase heeft een andere faalhandtekening.

De twee beheerpaden beantwoorden de laadvraag rechtstreeks:

swanctl --list-conns
ipsec statusall

Slechts één van die opdrachten hoort bij uw host. Beide uitvoeren en de uitvoer vergelijken is een manier om erachter te komen welke tegen u liegt, geen diagnosemethode.

Behandel pakketeigendom, configuratie laden en protocolcompatibiliteit als drie afzonderlijke vragen. Een bestand dat geldig is voor één frontend wordt anders steeds opnieuw bewerkt terwijl een andere daemon draait.