ipsec.conf, nebo swanctl.conf? Zvolte jednu frontu strongSwan

Funkční profil IKEv1 ze staršího návodu přistane na Ubuntu 24.04 a první pokus selže, protože démon soubor nikdy nepřečetl. Obvyklou reakcí je profil znovu upravit. Skutečná otázka zní, který frontend strongSwan je nainstalovaný a který používá běžící služba. Dokud na to není odpovězeno, každá úprava míří na zavaděč, který nemusí existovat.

Dva soubory, dva zavaděče, jeden démon

Starší uspořádání starter čte ipsec.conf a předává připojení charonu přes svou starou integraci správy. Jeho provozním vstupním bodem je příkaz ipsec.

Uspořádání swanctl načítá definice přes VICI, čte swanctl.conf a řídí se příkazem swanctl. Démon charon nativní pro systemd se s tímto přístupem integruje.

Oba mohou být nainstalovány na stejném stroji a právě tam začíná zmatek. Soubor v /etc dokazuje jen to, že ho někdo napsal, ne že ho běžící proces načetl. Instalace všech alternativ, abychom zjistili, která funguje, vytvoří hostitele se dvěma cestami správy a bez jasného vlastníka. Zvolte jedno uspořádání a druhé odstraňte nebo vypněte.

Přečtěte nainstalované balíčky a unity

Začněte pouze pro čtení. Názvy balíčků na Ubuntu 24.04 jsou oddělené: strongswan-starter, strongswan-swanctl a charon-systemd. Chybějící balíček je užitečná informace, ne pokyn k jeho instalaci.

Zinventarizujte balíčky a unity na jeden průchod:

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

Potom prohlédněte aktivní unit a jeho příkaz pro spuštění. Název unitu říká, který démon vlastní konfiguraci, a příkazový řádek potvrzuje, které soubory mu bylo nařízeno číst. Unit, který je povolený, ale neaktivní, vypráví jiný příběh než ten, který právě běží.

Pokud je aktivním unitem strongswan-starter, rozhoduje soubor ipsec.conf. Pokud je to charon-systemd se swanctl, je ipsec.conf jen dekorace.

Použijte odpovídající cestu správy

Každý frontend má vlastní pohled na připojení a asociace. swanctl --list-conns ukazuje načtené definice a swanctl --list-sas aktivní asociace. Starší cesta používá ipsec statusall.

Jejich míchání vytváří zavádějící chyby. Chybějící socket VICI nebo odmítnutý požadavek správy je problém cesty správy, ne důkaz, že protějšek odmítl autentizaci.

Přečtěte pohled, který patří běžícímu démonu, a poté výsledek vyložte. Pokud v tomto pohledu připojení chybí, problém je v načítání, ne ve vyjednávání.

Formát není verze IKE

Starší profil volí IKEv1 pomocí keyexchange=ikev1. Připojení swanctl používá nastavení verze, kde 1 volí IKEv1. To jsou dva slovníky pro tutéž myšlenku, ne převod.

Adresy protějšků, místní a vzdálené identity, zdroje přihlašovacích údajů, návrhy i selektory child je třeba záměrně zmapovat. Vložení bloku left/right do syntaxe swanctl neudělá nic z toho.

Změna pouze verze protokolu je nejčastější poloviční migrace. Vytvoří soubor, který se načte a pak neprojde autentizací z důvodů nesouvisejících s verzí. Sám IKEv1 je podle RFC 9395 zastaralý, takže existující protějšek, který ho stále vyžaduje, si zaslouží zdokumentované omezení kompatibility a cestu migrace, ne nové výchozí nastavení.

Než sáhnete na profil, zkontrolujte zavaděč

Nejprve spusťte kontrolu zavaděče, potom načtěte zamýšlené připojení, poté vyhodnoťte vyjednávání a nakonec cestu chráněného provozu. Každá fáze má jiný podpis selhání.

Obě cesty správy odpovídají na otázku načítání přímo:

swanctl --list-conns
ipsec statusall

Jen jeden z těchto příkazů patří vašemu hostiteli. Spustit oba a porovnat výstup je způsob, jak zjistit, který vám lže, ne diagnostická metoda.

Vlastnictví balíčků, načítání konfigurace a kompatibilitu protokolu berte jako tři oddělené otázky. Soubor platný pro jeden frontend se jinak bude upravovat znovu a znovu, zatímco běží jiný démon.