ipsec.conf aŭ swanctl.conf? Elektu unu strongSwan-frontend

Funkcianta IKEv1-profilo el pli malnova gvidilo alvenas sur Ubuntu 24.04, kaj la unua provo malsukcesas ĉar la demono neniam legis la dosieron. La kutima reago estas redekti la profilon. La vera demando estas, kiu strongSwan-frontend estas instalita kaj kiun uzas la ruliĝanta servo. Ĝis tio estos respondita, ĉiu redakto celas ŝargilon, kiu eble ne ekzistas.

Du dosieroj, du ŝargiloj, unu demono

La malnova aranĝo starter legas ipsec.conf kaj transdonas konektojn al charon per sia malnova administra integriĝo. Ĝia operacia enirpunkto estas la komando ipsec.

La aranĝo swanctl ŝargas difinojn per VICI, legas swanctl.conf kaj estas stirata de la komando swanctl. La systemd-nativa demono charon integriĝas kun tiu aliro.

Ambaŭ povas esti instalitaj sur la sama maŝino, kaj ĝuste tie komenciĝas la konfuzo. Dosiero sub /etc pruvas nur, ke iu ĝin skribis, ne ke la ruliĝanta procezo ŝargis ĝin. Instali ĉiun alternativon por vidi, kiu funkcias, kreas gastiganton kun du administraj vojoj kaj sen klara posedanto. Elektu unu aranĝon kaj forigu aŭ malŝaltu la alian.

Legu la instalitajn pakaĵojn kaj unuojn

Komencu nurlege. La pakaĵnomoj sur Ubuntu 24.04 estas apartaj: strongswan-starter, strongswan-swanctl kaj charon-systemd. Mankanta pakaĵo estas utila informo, ne instrukcio instali ĝin.

Inventaru la pakaĵojn kaj la unuojn en unu paŝo:

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

Poste ekzamenu la aktivan unuon kaj ĝian startkomandon. La unuonomo diras, kiu demono posedas la agordon, kaj la komandlinio konfirmas, kiujn dosierojn ĝi devis legi. Unuo, kiu estas ŝaltita sed neaktiva, rakontas alian historion ol tiu, kiu nun ruliĝas.

Se la aktiva unuo estas strongswan-starter, la dosiero, kiu gravas, estas ipsec.conf. Se ĝi estas charon-systemd kun swanctl, ipsec.conf estas nur ornamaĵo.

Uzu la kongruan stirvojon

Ĉiu frontend havas sian propran vidon de konektoj kaj asocioj. swanctl --list-conns montras ŝargitajn difinojn, kaj swanctl --list-sas montras aktivajn asociojn. La malnova vojo uzas ipsec statusall.

Miksi ilin produktas misgvidajn erarojn. Mankanta VICI-ingo aŭ rifuzita stirkonsulto estas problemo de la administra vojo, ne pruvo, ke la partnero rifuzis aŭtentikigon.

Legu la vidon, kiu apartenas al la ruliĝanta demono, kaj poste interpretu la rezulton. Se la konekto mankas en tiu vido, la problemo estas ŝargado, ne intertraktado.

Formato ne estas la IKE-versio

Malnova profilo elektas IKEv1 per keyexchange=ikev1. swanctl-konekto uzas versian agordon, kie 1 elektas IKEv1. Tiuj estas du vortaroj por la sama ideo, ne konvertiĝo.

La adresoj de la partnero, lokaj kaj malproksimaj identecoj, akreditaĵfontoj, proponoj kaj child-selektiloj devas esti intence mapitaj. Alglui blokon left/right en la sintakson de swanctl faras nenion el tio.

Ŝanĝi nur la protokolversion estas la plej ofta duonmigrado. Ĝi produktas dosieron, kiu ŝargiĝas kaj poste malsukcesas aŭtentikigi pro kaŭzoj neligitaj al la versio. IKEv1 mem estas eksvalidigita de RFC 9395, do ekzistanta partnero, kiu ankoraŭ postulas ĝin, meritas dokumentitan kongruec-limigon kaj migradvojon, ne novan defaŭlton.

Kontrolu la ŝargilon antaŭ ol tuŝi la profilon

Unue rulu la ŝargilkontrolon, poste ŝargu la celatan konekton, poste taksu la intertraktadon, kaj fine la vojon de protektita trafiko. Ĉiu etapo havas alian fiaskosignaturon.

La du stirvojoj rekte respondas la ŝargan demandon:

swanctl --list-conns
ipsec statusall

Nur unu el tiuj komandoj apartenas al via gastiganto. Ruli ambaŭ kaj kompari la eligon estas maniero malkovri, kiu mensogas al vi, ne diagnoza metodo.

Traktu pakaĵposedon, agordan ŝargadon kaj protokolan kongruecon kiel tri apartajn demandojn. Dosiero valida por unu frontend alie estos redaktata denove kaj denove, dum alia demono estas tiu, kiu ruliĝas.