ipsec.conf alebo swanctl.conf? Vyberte jeden frontend strongSwan

Funkčný profil IKEv1 zo staršieho návodu pristane na Ubuntu 24.04 a prvý pokus zlyhá, pretože démon súbor nikdy neprečítal. Zvyčajnou reakciou je profil znova upraviť. Skutočná otázka znie, ktorý frontend strongSwan je nainštalovaný a ktorý používa bežiaca služba. Kým na to nie je odpoveď, každá úprava mieri na zavádzač, ktorý nemusí existovať.

Dva súbory, dva zavádzače, jeden démon

Staršie usporiadanie starter číta ipsec.conf a odovzdáva pripojenia charonu cez svoju starú integračnú správu. Jeho prevádzkovým vstupným bodom je príkaz ipsec.

Usporiadanie swanctl načítava definície cez VICI, číta swanctl.conf a riadi sa príkazom swanctl. Démon charon natívny pre systemd sa s týmto prístupom integruje.

Oba môžu byť nainštalované na tom istom stroji a práve tam sa začína zmätok. Súbor v /etc dokazuje len to, že ho niekto napísal, nie že ho bežiaci proces načítal. Inštalácia všetkých alternatív, aby sme zistili, ktorá funguje, vytvorí hostiteľa s dvoma cestami správy a bez jasného vlastníka. Vyberte jedno usporiadanie a druhé odstráňte alebo vypnite.

Prečítajte nainštalované balíčky a unity

Začnite iba na čítanie. Názvy balíčkov na Ubuntu 24.04 sú oddelené: strongswan-starter, strongswan-swanctl a charon-systemd. Chýbajúci balíček je užitočná informácia, nie pokyn na jeho inštaláciu.

Zinventarizujte balíčky a unity na jeden prechod:

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

Potom preskúmajte aktívny unit a jeho príkaz na spustenie. Názov unitu hovorí, ktorý démon vlastní konfiguráciu, a príkazový riadok potvrdzuje, ktoré súbory mal čítať. Unit, ktorý je povolený, ale neaktívny, rozpráva iný príbeh než ten, ktorý práve beží.

Ak je aktívnym unitom strongswan-starter, rozhoduje súbor ipsec.conf. Ak je to charon-systemd so swanctl, ipsec.conf je len dekorácia.

Použite zodpovedajúcu cestu správy

Každý frontend má vlastný pohľad na pripojenia a asociácie. swanctl --list-conns zobrazuje načítané definície a swanctl --list-sas aktívne asociácie. Staršia cesta používa ipsec statusall.

Ich miešanie vytvára zavádzajúce chyby. Chýbajúci socket VICI alebo odmietnutá požiadavka správy je problém cesty správy, nie dôkaz, že protistrana odmietla autentifikáciu.

Prečítajte pohľad, ktorý patrí bežiacemu démonovi, a potom interpretujte výsledok. Ak v tomto pohľade pripojenie chýba, problém je v načítaní, nie v rokovaní.

Formát nie je verzia IKE

Starší profil volí IKEv1 pomocou keyexchange=ikev1. Pripojenie swanctl používa nastavenie verzie, kde 1 volí IKEv1. To sú dva slovníky pre tú istú myšlienku, nie prevod.

Adresy protistrany, miestne a vzdialené identity, zdroje prihlasovacích údajov, návrhy a selektory child treba mapovať zámerne. Vloženie bloku left/right do syntaxe swanctl nerobí nič z toho.

Zmena iba verzie protokolu je najčastejšia polovičná migrácia. Vytvorí súbor, ktorý sa načíta a potom neprejde autentifikáciou z dôvodov nesúvisiacich s verziou. Sám IKEv1 je podľa RFC 9395 zastaraný, takže existujúca protistrana, ktorá ho stále vyžaduje, si zaslúži zdokumentované obmedzenie kompatibility a cestu migrácie, nie nové predvolené nastavenie.

Skôr než sa dotknete profilu, skontrolujte zavádzač

Najprv spustite kontrolu zavádzača, potom načítajte zamýšľané pripojenie, potom vyhodnoťte rokovanie a nakoniec cestu chránenej prevádzky. Každá fáza má iný podpis zlyhania.

Obe cesty správy priamo odpovedajú na otázku načítania:

swanctl --list-conns
ipsec statusall

Len jeden z týchto príkazov patrí vášmu hostiteľovi. Spustiť oba a porovnať výstup je spôsob, ako zistiť, ktorý vám klame, nie diagnostická metóda.

Vlastníctvo balíčkov, načítanie konfigurácie a kompatibilitu protokolu berte ako tri oddelené otázky. Súbor platný pre jeden frontend sa inak bude upravovať znova a znova, kým beží iný démon.