ipsec.conf eller swanctl.conf? Velg én strongSwan-frontend

En fungerende IKEv1-profil fra en eldre veiledning havner på Ubuntu 24.04, og det første forsøket mislykkes fordi daemonen aldri leste filen. Den vanlige reaksjonen er å redigere profilen på nytt. Det egentlige spørsmålet er hvilken strongSwan-frontend som er installert, og hvilken den kjørende tjenesten bruker. Inntil det er besvart, retter hver endring seg mot en laster som kanskje ikke finnes.

To filer, to lastere, én daemon

Den gamle starter-ordningen leser ipsec.conf og overlater tilkoblinger til charon gjennom sin gamle administrasjonsintegrasjon. Dens operasjonelle inngangspunkt er kommandoen ipsec.

swanctl-ordningen laster definisjoner via VICI, leser swanctl.conf og styres av kommandoen swanctl. Den systemd-native charon-daemonen integreres med denne tilnærmingen.

Begge kan være installert på samme maskin, og det er der forvirringen starter. En fil under /etc beviser bare at noen har skrevet den, ikke at den kjørende prosessen har lastet den. Å installere alle alternativene for å se hvilket som virker lager en vert med to administrasjonsveier og uten en klar eier. Velg én ordning og fjern eller deaktiver den andre.

Les de installerte pakkene og enhetene

Start skrivebeskyttet. Pakkenavnene på Ubuntu 24.04 er atskilt: strongswan-starter, strongswan-swanctl og charon-systemd. En manglende pakke er nyttig informasjon, ikke en instruks om å installere den.

Kartlegg pakkene og enhetene i én gjennomgang:

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

Undersøk deretter den aktive enheten og startkommandoen dens. Enhetsnavnet forteller hvilken daemon som eier konfigurasjonen, og kommandolinjen bekrefter hvilke filer den ble bedt om å lese. En enhet som er aktivert men inaktiv, forteller en annen historie enn en som kjører nå.

Hvis den aktive enheten er strongswan-starter, er ipsec.conf filen som betyr noe. Hvis det er charon-systemd med swanctl, er ipsec.conf bare dekorasjon.

Bruk den samsvarende administrasjonsveien

Hver frontend har sitt eget bilde av tilkoblinger og assosiasjoner. swanctl --list-conns viser lastede definisjoner, og swanctl --list-sas viser aktive assosiasjoner. Den gamle veien bruker ipsec statusall.

Å blande dem gir misvisende feil. En manglende VICI-socket eller en avvist kontrollforespørsel er et problem med administrasjonsveien, ikke bevis for at motparten avviste autentiseringen.

Les bildet som hører til den kjørende daemonen, og tolk deretter resultatet. Hvis tilkoblingen mangler i det bildet, er problemet lasting, ikke forhandling.

Format er ikke IKE-versjonen

En gammel profil velger IKEv1 med keyexchange=ikev1. En swanctl-tilkobling bruker en versjonsinnstilling, der 1 velger IKEv1. Det er to ordforråd for den samme ideen, ikke en konvertering.

Motpartens adresser, lokale og eksterne identiteter, kilder for påloggingsinformasjon, forslag og child-velgere må kartlegges med vilje. Å lime inn en left/right-blokk i swanctl-syntaks gjør ingenting av det.

Å endre bare protokollversjonen er den vanligste halvmigreringen. Det gir en fil som lastes og deretter feiler autentiseringen av årsaker som ikke har med versjonen å gjøre. IKEv1 selv er foreldet av RFC 9395, så en eksisterende motpart som fortsatt krever det, fortjener en dokumentert kompatibilitetsbegrensning og en migreringsvei, ikke en ny standardverdi.

Kontroller lasteren før du rører profilen

Kjør lasterkontrollen først, last deretter den tiltenkte tilkoblingen, vurder deretter forhandlingen og til slutt veien for beskyttet trafikk. Hvert trinn har en annen feilsignatur.

De to administrasjonsveiene svarer direkte på lastespørsmålet:

swanctl --list-conns
ipsec statusall

Bare én av disse kommandoene hører til verten din. Å kjøre begge og sammenligne utdataene er en måte å finne ut hvilken som lyver for deg, ikke en diagnostisk metode.

Behandle pakkeeierskap, konfigurasjonslasting og protokollkompatibilitet som tre separate spørsmål. En fil som er gyldig for én frontend vil ellers bli redigert igjen og igjen mens en annen daemon er den som kjører.