ipsec.conf sau swanctl.conf? Alegeți un frontend strongSwan

Un profil IKEv1 funcțional dintr-un ghid mai vechi ajunge pe Ubuntu 24.04, iar prima încercare eșuează pentru că demonul nu a citit niciodată fișierul. Reacția obișnuită este să editați din nou profilul. Adevărata întrebare este ce frontend strongSwan este instalat și pe care îl folosește serviciul care rulează. Până când nu se răspunde la asta, fiecare modificare țintește un loader care poate nu există.

Două fișiere, două loadere, un demon

Vechiul aranjament starter citește ipsec.conf și predă conexiunile către charon prin integrarea sa veche de administrare. Punctul său de intrare operațional este comanda ipsec.

Aranjamentul swanctl încarcă definiții prin VICI, citește swanctl.conf și este condus de comanda swanctl. Demonul charon nativ systemd se integrează cu această abordare.

Ambele pot fi instalate pe aceeași mașină, și de acolo începe confuzia. Un fișier sub /etc dovedește doar că cineva l-a scris, nu că procesul care rulează l-a încărcat. Instalarea fiecărei alternative pentru a vedea care funcționează creează un host cu două căi de administrare și fără un proprietar clar. Alegeți un aranjament și eliminați sau dezactivați-l pe celălalt.

Citiți pachetele și unitățile instalate

Începeți doar în citire. Numele pachetelor pe Ubuntu 24.04 sunt separate: strongswan-starter, strongswan-swanctl și charon-systemd. Un pachet lipsă este o informație utilă, nu o instrucțiune de a-l instala.

Inventariați pachetele și unitățile într-o singură trecere:

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

Apoi inspectați unitatea activă și comanda ei de pornire. Numele unității spune care demon deține configurația, iar linia de comandă confirmă ce fișiere i s-a cerut să citească. O unitate activată dar inactivă spune o altă poveste decât una care rulează acum.

Dacă unitatea activă este strongswan-starter, fișierul care contează este ipsec.conf. Dacă este charon-systemd cu swanctl, ipsec.conf este doar decor.

Folosiți calea de control potrivită

Fiecare frontend are propria vedere asupra conexiunilor și asocierilor. swanctl --list-conns arată definițiile încărcate, iar swanctl --list-sas asocierile active. Calea veche folosește ipsec statusall.

Amestecarea lor produce erori înșelătoare. Un socket VICI lipsă sau o cerere de control refuzată este o problemă a căii de administrare, nu dovada că partenerul a refuzat autentificarea.

Citiți vederea care aparține demonului care rulează, apoi interpretați rezultatul. Dacă conexiunea lipsește din acea vedere, problema este încărcarea, nu negocierea.

Formatul nu este versiunea IKE

Un profil vechi selectează IKEv1 cu keyexchange=ikev1. O conexiune swanctl folosește o setare de versiune, unde 1 selectează IKEv1. Acestea sunt două vocabulare pentru aceeași idee, nu o conversie.

Adresele partenerului, identitățile locală și la distanță, sursele de credențiale, propunerile și selectorii child trebuie mapate intenționat. Lipirea unui bloc left/right în sintaxa swanctl nu face nimic din toate acestea.

Schimbarea doar a versiunii protocolului este cea mai frecventă semi-migrare. Produce un fișier care se încarcă și apoi eșuează autentificarea din motive fără legătură cu versiunea. IKEv1 însuși este învechit prin RFC 9395, așa că un partener existent care încă îl cere merită o restricție de compatibilitate documentată și o cale de migrare, nu o valoare implicită nouă.

Verificați loaderul înainte de a atinge profilul

Rulați mai întâi verificarea loaderului, apoi încărcați conexiunea dorită, apoi evaluați negocierea și la final calea traficului protejat. Fiecare etapă are o semnătură de eșec diferită.

Cele două căi de control răspund direct la întrebarea încărcării:

swanctl --list-conns
ipsec statusall

Doar una dintre aceste comenzi aparține hostului dumneavoastră. Rularea ambelor și compararea ieșirii este o modalitate de a afla care vă minte, nu o metodă de diagnosticare.

Tratați proprietatea pachetelor, încărcarea configurației și compatibilitatea protocolului ca trei întrebări separate. Un fișier valid pentru un frontend va fi altfel editat iar și iar în timp ce alt demon rulează.