ipsec.conf of swanctl.conf? Kies ien strongSwan-frontend

In wurkjend IKEv1-profyl út in âldere hânlieding lânet op Ubuntu 24.04, en de earste poging mislearret om't de daemon it bestân nea lêzen hat. De gewoane reaksje is om it profyl wer te bewurkjen. De echte fraach is hokker strongSwan-frontend ynstallearre is en hokker de rinnende tsjinst brûkt. Oant dat beantwurde is, rjochtet elke bewurking him op in lader dy't miskien net bestiet.

Twa bestannen, twa laders, ien daemon

De âlde starter-opset lêst ipsec.conf en jout ferbiningen oan charon troch syn âlde behear-yntegraasje. It operasjonele ynfierpuntsje is it ipsec-kommando.

De swanctl-opset lânet definysjes fia VICI, lêst swanctl.conf en wurdt oanstjoerd troch it swanctl-kommando. De systemd-eigen charon-daemon yntegrearret mei dy oanpak.

Beide kinne op deselde masine ynstallearre wêze, en dêr begjint de betizing. In bestân ûnder /etc bewiist allinnich dat immen it skreaun hat, net dat it rinnende proses it laden hat. It ynstallearjen fan elk alternatyf om te sjen hokker wurket, makket in host mei twa behearspaden en gjin dúdlike eigner. Kies ien opset en ferwiderje of skeakelje de oare út.

Lês de ynstallearre pakketten en units

Begjin allinnich-lêze. De pakketnammen op Ubuntu 24.04 binne apart: strongswan-starter, strongswan-swanctl en charon-systemd. In ûntbrekkend pakket is nuttige ynformaasje, gjin opdracht om it te ynstallearjen.

Ynfentarisearje de pakketten en de units yn ien gong:

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

Undersykje dan de aktive unit en syn startkommando. De unitnamme fertelt hokker daemon de konfiguraasje besit, en de kommandorigel befêstiget hokker bestannen it lêze moast. In unit dy't ynskeakele mar net aktyf is, fertelt in oar ferhaal as ien dy't no rint.

As de aktive unit strongswan-starter is, is ipsec.conf it bestân dat der ta docht. As it charon-systemd mei swanctl is, is ipsec.conf gewoan fersiering.

Brûk it byhearrende behearspaad

Elke frontend hat syn eigen byld fan ferbiningen en assosjaasjes. swanctl --list-conns toant laden definysjes en swanctl --list-sas toant aktive assosjaasjes. It âlde paad brûkt ipsec statusall.

Se trochinoar helje jout misliedende flaters. In ûntbrekkende VICI-socket of in wegere behearoanfraach is in probleem fan it behearspaad, net it bewiis dat de partner de autentikaasje wegere.

Lês it byld dat by de rinnende daemon heart, en ynterpretearje dan it resultaat. As de ferbining yn dat byld ûntbrekt, is it probleem it laden, net de ûnderhanneling.

Formaat is net de IKE-ferzje

In âld profyl kiest IKEv1 mei keyexchange=ikev1. In swanctl-ferbining brûkt in ferzje-ynstelling, wêrby't 1 IKEv1 kiest. Dat binne twa wurdlisten foar itselde idee, gjin konverzje.

Adressen fan de partner, lokale en fiere identiteiten, boarnen fan bewizen, foarstellen en child-selekteurs moatte mei opsetsin yn kaart brocht wurde. In left/right-blok yn swanctl-syntaks plakke docht dêr neat fan.

Allinnich de protokolferzje feroarje is de meast foarkommende heale migraasje. It makket in bestân dat lânet en dan net autentisearret om redenen dy't neat mei de ferzje te meitsjen hawwe. IKEv1 sels is ferâldere troch RFC 9395, dus in besteande partner dy't it noch ferget, fertsjinnet in dokumintearre kompatibiliteitsbeheining en in migraasjepaad, net in nije standert.

Kontrolearje de lader foardat jo it profyl oanreitsje

Fier earst de laderkontrôle út, laad dan de bedoelde ferbining, beoardielje dan de ûnderhanneling en dan it paad fan beskerme ferkear. Elke stap hat in oare mislearringssignatuer.

De twa behearspaden beantwurdzje de ladingsfraach direkt:

swanctl --list-conns
ipsec statusall

Allinnich ien fan dy kommando's heart by jo host. Beide rinne litte en de útfier fergelykje is in manier om te ûntdekken hokker tsjin jo liicht, gjin diagnostyske metoade.

Behannelje pakketbesit, konfiguraasjeladen en protokolkompatibiliteit as trije aparte fragen. In bestân dat jildich is foar ien frontend sil oars wer en wer bewurke wurde wylst in oare daemon rint.