ipsec.conf eller swanctl.conf? Välj en strongSwan-frontend

En fungerande IKEv1-profil från en äldre guide landar på Ubuntu 24.04, och det första försöket misslyckas eftersom daemonen aldrig läste filen. Det vanliga svaret är att redigera profilen igen. Den egentliga frågan är vilken strongSwan-frontend som är installerad och vilken den körande tjänsten använder. Tills det är besvarat riktar sig varje ändring mot en lastare som kanske inte finns.

Två filer, två lastare, en daemon

Det gamla starter-upplägget läser ipsec.conf och lämnar anslutningar till charon via sin gamla administrationsintegration. Dess operativa ingångspunkt är kommandot ipsec.

swanctl-upplägget läser in definitioner via VICI, läser swanctl.conf och styrs av kommandot swanctl. Den systemd-nativa charon-daemonen integreras med det angreppssättet.

Båda kan vara installerade på samma maskin, och det är där förvirringen börjar. En fil under /etc bevisar bara att någon har skrivit den, inte att den körande processen har läst in den. Att installera varje alternativ för att se vilket som fungerar skapar en värd med två administrationsvägar och ingen tydlig ägare. Välj ett upplägg och ta bort eller inaktivera det andra.

Läs de installerade paketen och enheterna

Börja skrivskyddat. Paketnamnen på Ubuntu 24.04 är åtskilda: strongswan-starter, strongswan-swanctl och charon-systemd. Ett saknat paket är användbar information, inte en instruktion att installera det.

Inventera paketen och enheterna i en enda genomgång:

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

Undersök sedan den aktiva enheten och dess startkommando. Enhetsnamnet berättar vilken daemon som äger konfigurationen, och kommandoraden bekräftar vilka filer den blev tillsagd att läsa. En enhet som är aktiverad men inaktiv berättar en annan historia än en som körs nu.

Om den aktiva enheten är strongswan-starter är ipsec.conf filen som spelar roll. Om det är charon-systemd med swanctl är ipsec.conf bara dekoration.

Använd den matchande administrationsvägen

Varje frontend har sin egen bild av anslutningar och associationer. swanctl --list-conns visar inlästa definitioner och swanctl --list-sas visar aktiva associationer. Den gamla vägen använder ipsec statusall.

Att blanda dem ger missvisande fel. En saknad VICI-socket eller en avvisad kontrollbegäran är ett problem med administrationsvägen, inte bevis för att motparten avvisade autentiseringen.

Läs den bild som hör till den körande daemonen, och tolka sedan resultatet. Om anslutningen saknas i den bilden är problemet inläsningen, inte förhandlingen.

Formatet är inte IKE-versionen

En gammal profil väljer IKEv1 med keyexchange=ikev1. En swanctl-anslutning använder en versionsinställning, där 1 väljer IKEv1. Det är två ordförråd för samma idé, inte en konvertering.

Motpartens adresser, lokala och avlägsna identiteter, källor för inloggningsuppgifter, förslag och child-väljare måste kartläggas med avsikt. Att klistra in ett left/right-block i swanctl-syntax gör inget av det.

Att bara ändra protokollversionen är den vanligaste halvmigreringen. Det ger en fil som läses in och sedan misslyckas med autentiseringen av skäl som inte har med versionen att göra. IKEv1 självt är föråldrat av RFC 9395, så en befintlig motpart som fortfarande kräver det förtjänar en dokumenterad kompatibilitetsbegränsning och en migreringsväg, inte ett nytt standardvärde.

Kontrollera lastaren innan du rör profilen

Kör först lastarkontrollen, läs sedan in den avsedda anslutningen, bedöm därefter förhandlingen och till sist vägen för skyddad trafik. Varje steg har en annan felsignatur.

De två administrationsvägarna svarar direkt på inläsningsfrågan:

swanctl --list-conns
ipsec statusall

Bara ett av dessa kommandon hör till din värd. Att köra båda och jämföra utdata är ett sätt att upptäcka vilken som ljuger för dig, inte en diagnostisk metod.

Behandla paketägande, inläsning av konfiguration och protokollkompatibilitet som tre separata frågor. En fil som är giltig för en frontend kommer annars att redigeras om och om igen medan en annan daemon körs.