ipsec.conf eller swanctl.conf? Vel éin strongSwan-frontend
ipsec.conf og swanctl.conf høyrer til ulike strongSwan-lastarar. Fastset den køyrande tenesta før du omset ein gammal IKEv1-profil.
Ein fungerande IKEv1-profil frå ei eldre rettleiing hamnar på Ubuntu 24.04, og det første forsøket mislukkast fordi daemonen aldri las fila. Den vanlege responsen er å redigere profilen på nytt. Det eigentlege spørsmålet er kva strongSwan-frontend som er installert, og kva den køyrande tenesta brukar. Fram til det er svara, rettar kvar endring seg mot ein lastar som kanskje ikkje finst.
To filer, to lastarar, éin daemon
Den gamle starter-ordninga les ipsec.conf og overlèt tilkoplingar til charon gjennom den gamle administrasjonsintegrasjonen sin. Det operative inngangspunktet hennar er kommandoen ipsec.
swanctl-ordninga lastar definisjonar via VICI, les swanctl.conf og blir styrt av kommandoen swanctl. Den systemd-native charon-daemonen integrerer med denne tilnærminga.
Båe kan vere installerte på same maskin, og det er der forvirringa byrjar. Ei fil under /etc beviser berre at nokon har skrive ho, ikkje at den køyrande prosessen har lasta ho. Å installere alle alternativa for å sjå kva som verkar lagar ein vert med to administrasjonsvegar og utan ein klar eigar. Vel éi ordning og fjern eller slå av den andre.
Les dei installerte pakkane og einingane
Start skriveverna. Pakkenamna på Ubuntu 24.04 er skilde: strongswan-starter, strongswan-swanctl og charon-systemd. Ein manglande pakke er nyttig informasjon, ikkje ein instruks om å installere han.
Kartlegg pakkane og einingane i éin gjennomgang:
dpkg-query -W strongswan-starter strongswan-swanctl charon-systemd
systemctl list-unit-files '*strongswan*'
Undersøk deretter den aktive eininga og startkommandoen hennar. Eininganamnet fortel kva daemon som eig konfigurasjonen, og kommandolinja stadfester kva filer ho vart beden om å lese. Ei eining som er slått på men inaktiv, fortel ei anna historie enn ei som køyrer no.
Viss den aktive eininga er strongswan-starter, er ipsec.conf fila som teller. Viss ho er charon-systemd med swanctl, er ipsec.conf berre dekorasjon.
Bruk den samsvarande administrasjonsvegen
Kvar frontend har sitt eige bilete av tilkoplingar og assosiasjonar. swanctl --list-conns viser lasta definisjonar, og swanctl --list-sas viser aktive assosiasjonar. Den gamle vegen brukar ipsec statusall.
Å blande dei gir misvisande feil. Ein manglande VICI-socket eller ein avvist kontrollførespurnad er eit problem med administrasjonsvegen, ikkje prov på at motparten avviste autentiseringa.
Les biletet som høyrer til den køyrande daemonen, og tolk deretter resultatet. Viss tilkoplinga manglar i det biletet, er problemet lasting, ikkje forhandling.
Format er ikkje IKE-versjonen
Ein gammal profil vel IKEv1 med keyexchange=ikev1. Ei swanctl-tilkopling brukar ei versjonsinnstilling, der 1 vel IKEv1. Det er to ordtilfang for den same ideen, ikkje ei omforming.
Adressene til motparten, lokale og eksterne identitetar, kjelder for påloggingsinformasjon, framlegg og child-veljarar må kartleggjast med vilje. Å lime inn ein left/right-blokk i swanctl-syntaksen gjer ingenting av det.
Å endre berre protokollversjonen er den vanlegaste halvmigreringa. Det gir ei fil som blir lasta og deretter feilar på autentiseringa av årsaker som ikkje har med versjonen å gjere. IKEv1 sjølv er utdatert av RFC 9395, så ein eksisterande motpart som framleis krev det, fortener ei dokumentert kompatibilitetsavgrensing og ein migrasjonsveg, ikkje ein ny standardverdi.
Kontroller lastaren før du rører profilen
Køyr lastarkontrollen fyrst, last deretter den tiltenkte tilkoplinga, vurder så forhandlinga og til slutt vegen for verna trafikk. Kvart trinn har ein annan feilsignatur.
Dei to administrasjonsvegane svarar direkte på lastespørsmålet:
swanctl --list-conns
ipsec statusall
Berre éin av desse kommandoane høyrer til verten din. Å køyre båe og samanlikne utdata er ein måte å finne ut kven som lyg for deg, ikkje ein diagnostisk metode.
Behandle pakkeeige, konfigurasjonslasting og protokollkompatibilitet som tre separate spørsmål. Ei fil som er gyldig for éin frontend vil elles bli redigert igjen og igjen medan ein annan daemon er den som køyrer.