ipsec.conf vai swanctl.conf? Izvēlieties vienu strongSwan frontend

Darbojošs IKEv1 profils no vecākas rokasgrāmatas nonāk uz Ubuntu 24.04, un pirmais mēģinājums neizdodas, jo dēmons failu nekad nav lasījis. Parastā reakcija ir profilu vēlreiz rediģēt. Īstais jautājums ir, kurš strongSwan frontend ir instalēts un kuru izmanto darbojošais pakalpojums. Kamēr tas nav atbildēts, katrs labojums ir vērsts uz ielādētāju, kura var arī nebūt.

Divi faili, divi ielādētāji, viens dēmons

Vecā starter kārtība lasa ipsec.conf un nodod savienojumus charon caur savu veco pārvaldības integrāciju. Tās darbības ieejas punkts ir ipsec komanda.

swanctl kārtība ielādē definīcijas caur VICI, lasa swanctl.conf un tiek vadīta ar swanctl komandu. systemd vietējais charon dēmons integrējas ar šo pieeju.

Abus var instalēt vienā mašīnā, un tieši tur sākas apjukums. Fails zem /etc pierāda tikai to, ka kāds to ir uzrakstījis, nevis to, ka darbojošais process to ir ielādējis. Visu alternatīvu instalēšana, lai redzētu, kura strādā, rada resursdatoru ar diviem pārvaldības ceļiem un bez skaidra īpašnieka. Izvēlieties vienu kārtību un noņemiet vai atspējojiet otru.

Izlasiet instalētās pakotnes un unit

Sāciet tikai lasīšanas režīmā. Pakotņu nosaukumi Ubuntu 24.04 ir atsevišķi: strongswan-starter, strongswan-swanctl un charon-systemd. Trūkstoša pakotne ir noderīga informācija, nevis norādījums to instalēt.

Vienā piegājienā uzskaitiet pakotnes un unit:

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

Pēc tam pārbaudiet aktīvo unit un tā palaišanas komandu. Unit nosaukums pasaka, kurš dēmons pārvalda konfigurāciju, un komandrinda apstiprina, kuri faili tam bija jālasa. Unit, kas ir iespējots, bet nav aktīvs, stāsta citu stāstu nekā tas, kas darbojas tagad.

Ja aktīvais unit ir strongswan-starter, svarīgais fails ir ipsec.conf. Ja tas ir charon-systemd ar swanctl, ipsec.conf ir tikai rotājums.

Izmantojiet atbilstošo vadības ceļu

Katram frontend ir savs skats uz savienojumiem un asociācijām. swanctl --list-conns rāda ielādētās definīcijas, un swanctl --list-sas rāda aktīvās asociācijas. Vecais ceļš izmanto ipsec statusall.

To sajaukšana rada maldinošas kļūdas. Trūkstošs VICI ligzda vai noraidīts vadības pieprasījums ir vadības ceļa problēma, nevis pierādījums, ka partneris noraidīja autentifikāciju.

Izlasiet skatu, kas pieder darbojošajam dēmonam, un pēc tam interpretējiet rezultātu. Ja savienojuma šajā skatā nav, problēma ir ielādē, nevis sarunās.

Formāts nav IKE versija

Vecais profils izvēlas IKEv1 ar keyexchange=ikev1. swanctl savienojums izmanto versijas iestatījumu, kur 1 izvēlas IKEv1. Tie ir divi vārdnīcas vienai idejai, nevis pārveide.

Partnera adreses, vietējās un attālās identitātes, akreditācijas datu avoti, priekšlikumi un child selektori ir apzināti jākartē. left/right bloka ielīmēšana swanctl sintaksē nepadara neko no tā.

Mainīt tikai protokola versiju ir visizplatītākā pusmigrācija. Tā rada failu, kas ielādējas un pēc tam neiztur autentifikāciju ar versiju nesaistītu iemeslu dēļ. Pats IKEv1 ir novecojis saskaņā ar RFC 9395, tāpēc esošais partneris, kas to joprojām pieprasa, ir pelnījis dokumentētu saderības ierobežojumu un migrācijas ceļu, nevis jaunu noklusējumu.

Pārbaudiet ielādētāju pirms profila aiztikšanas

Vispirms izpildiet ielādētāja pārbaudi, pēc tam ielādējiet paredzēto savienojumu, pēc tam novērtējiet sarunas un visbeidzot aizsargātās plūsmas ceļu. Katram posmam ir cita atteices paraksts.

Divi vadības ceļi tieši atbild uz ielādes jautājumu:

swanctl --list-conns
ipsec statusall

Tikai viena no šīm komandām pieder jūsu resursdatoram. Abu palaišana un izvades salīdzināšana ir veids, kā noskaidrot, kura jums melo, nevis diagnostikas metode.

Uzlūkojiet pakotņu īpašumtiesības, konfigurācijas ielādi un protokola saderību kā trīs atsevišķus jautājumus. Fails, kas der vienam frontend, citādi tiks rediģēts atkal un atkal, kamēr darbojas cits dēmons.