ipsec.conf ar swanctl.conf? Pasirinkite vieną strongSwan frontend

Veikiantis IKEv1 profilis iš senesnio vadovo atsiduria Ubuntu 24.04, o pirmas bandymas nepavyksta, nes demonas niekada neperskaitė failo. Įprasta reakcija yra dar kartą redaguoti profilį. Tikrasis klausimas yra, kuris strongSwan frontend įdiegtas ir kurį naudoja veikianti tarnyba. Kol į tai neatsakyta, kiekvienas pakeitimas nukreiptas į įkėlėją, kurio gali ir nebūti.

Du failai, du įkėlėjai, vienas demonas

Senoji starter tvarka skaito ipsec.conf ir perduoda jungtis charon per savo senąją valdymo integraciją. Jos veikimo įėjimo taškas yra ipsec komanda.

swanctl tvarka įkelia apibrėžtis per VICI, skaito swanctl.conf ir valdoma swanctl komandos. systemd gimtoji charon demonas integruojasi su šiuo požiūriu.

Abu gali būti įdiegti toje pačioje mašinoje, ir būtent ten prasideda painiava. Failas po /etc įrodo tik tai, kad kažkas jį parašė, o ne kad veikiantis procesas jį įkėlė. Visų alternatyvų diegimas norint pamatyti, kuri veikia, sukuria mazgą su dviem valdymo keliais ir be aiškaus savininko. Pasirinkite vieną tvarką ir pašalinkite arba išjunkite kitą.

Perskaitykite įdiegtus paketus ir unit

Pradėkite tik skaitymo režimu. Paketų pavadinimai Ubuntu 24.04 yra atskiri: strongswan-starter, strongswan-swanctl ir charon-systemd. Trūkstamas paketas yra naudinga informacija, o ne nurodymas jį įdiegti.

Vienu ėjimu surašykite paketus ir unit:

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

Tada patikrinkite aktyvų unit ir jo paleidimo komandą. Unit pavadinimas pasako, kuris demonas valdo konfigūraciją, o komandų eilutė patvirtina, kuriuos failus jam buvo liepta skaityti. Įjungtas, bet neaktyvus unit pasakoja kitokią istoriją nei dabar veikiantis.

Jei aktyvus unit yra strongswan-starter, svarbus failas yra ipsec.conf. Jei tai charon-systemd su swanctl, ipsec.conf tėra puošmena.

Naudokite atitinkamą valdymo kelią

Kiekvienas frontend turi savo jungčių ir asociacijų vaizdą. swanctl --list-conns rodo įkeltas apibrėžtis, o swanctl --list-sas – aktyvias asociacijas. Senas kelias naudoja ipsec statusall.

Jų maišymas sukuria klaidinančias klaidas. Trūkstamas VICI lizdas arba atmestas valdymo prašymas yra valdymo kelio problema, o ne įrodymas, kad partneris atmetė autentifikaciją.

Perskaitykite vaizdą, kuris priklauso veikiančiam demonui, o tada interpretuokite rezultatą. Jei jungties tame vaizde nėra, problema yra įkėlime, o ne derybose.

Formatas nėra IKE versija

Senas profilis pasirenka IKEv1 su keyexchange=ikev1. swanctl jungtis naudoja versijos nuostatą, kur 1 pasirenka IKEv1. Tai du žodynai tai pačiai idėjai, o ne konvertavimas.

Partnerio adresai, vietinės ir nuotolinės tapatybės, kredencialų šaltiniai, pasiūlymai ir child selektoriai turi būti sąmoningai susieti. left/right bloko įklijavimas į swanctl sintaksę nepadaro nieko iš to.

Keisti tik protokolo versiją yra labiausiai paplitusi pusinė migracija. Ji sukuria failą, kuris įkeliamas ir tada nepraeina autentifikacijos dėl priežasčių, nesusijusių su versija. Pats IKEv1 yra pasenęs pagal RFC 9395, todėl esamas partneris, kuris jo vis dar reikalauja, nusipelno dokumentuoto suderinamumo apribojimo ir migracijos kelio, o ne naujos numatytosios reikšmės.

Patikrinkite įkėlėją prieš liesdami profilį

Pirmiausia atlikite įkėlėjo patikrą, tada įkelkite numatytą jungtį, tada įvertinkite derybas ir galiausiai apsaugoto srauto kelią. Kiekvienas etapas turi skirtingą gedimo parašą.

Du valdymo keliai tiesiogiai atsako į įkėlimo klausimą:

swanctl --list-conns
ipsec statusall

Tik viena iš šių komandų priklauso jūsų mazgui. Abiejų paleidimas ir išvesties palyginimas yra būdas sužinoti, kuri jums meluoja, o ne diagnostikos metodas.

Traktuokite paketų nuosavybę, konfigūracijos įkėlimą ir protokolo suderinamumą kaip tris atskirus klausimus. Vienam frontend tinkamas failas kitu atveju bus redaguojamas vėl ir vėl, kol veikia kitas demonas.