ipsec.conf eller swanctl.conf? Vælg én strongSwan-frontend
ipsec.conf og swanctl.conf hører til forskellige strongSwan-indlæsere. Fastslå den kørende tjeneste, før du oversætter en gammel IKEv1-profil.
En fungerende IKEv1-profil fra en ældre guide lander på Ubuntu 24.04, og det første forsøg fejler, fordi daemonen aldrig læste filen. Den sædvanlige reaktion er at redigere profilen igen. Det egentlige spørgsmål er, hvilken strongSwan-frontend der er installeret, og hvilken den kørende tjeneste bruger. Indtil det er besvaret, rammer enhver ændring en indlæser, der måske ikke findes.
To filer, to indlæsere, én daemon
Det gamle starter-arrangement læser ipsec.conf og giver forbindelser videre til charon via sin gamle administrationsintegration. Dets operationelle indgangspunkt er kommandoen ipsec.
swanctl-arrangementet indlæser definitioner via VICI, læser swanctl.conf og styres af kommandoen swanctl. Den systemd-native charon-daemon integrerer med den fremgangsmåde.
Begge kan være installeret på samme maskine, og det er dér, forvirringen starter. En fil under /etc beviser kun, at nogen har skrevet den, ikke at den kørende proces har indlæst den. At installere alle alternativer for at se, hvilket der virker, skaber en vært med to administrationsveje og ingen klar ejer. Vælg ét arrangement, og fjern eller deaktiver det andet.
Læs de installerede pakker og units
Start skrivebeskyttet. Pakkenavnene på Ubuntu 24.04 er adskilte: strongswan-starter, strongswan-swanctl og charon-systemd. En manglende pakke er nyttig information, ikke en anvisning om at installere den.
Kortlæg pakkerne og unitene i én gennemgang:
dpkg-query -W strongswan-starter strongswan-swanctl charon-systemd
systemctl list-unit-files '*strongswan*'
Undersøg derefter den aktive unit og dens startkommando. Unitnavnet fortæller, hvilken daemon der ejer konfigurationen, og kommandolinjen bekræfter, hvilke filer den blev bedt om at læse. En unit, der er aktiveret men inaktiv, fortæller en anden historie end en, der kører nu.
Hvis den aktive unit er strongswan-starter, er ipsec.conf den fil, der betyder noget. Hvis det er charon-systemd med swanctl, er ipsec.conf ren dekoration.
Brug den matchende administrationsvej
Hver frontend har sit eget billede af forbindelser og associationer. swanctl --list-conns viser indlæste definitioner, og swanctl --list-sas viser aktive associationer. Den gamle vej bruger ipsec statusall.
At blande dem giver misvisende fejl. En manglende VICI-socket eller en afvist administrationsanmodning er et problem med administrationsvejen, ikke bevis for at modparten afviste godkendelsen.
Læs det billede, der hører til den kørende daemon, og fortolk derefter resultatet. Hvis forbindelsen mangler i det billede, er problemet indlæsning, ikke forhandling.
Format er ikke IKE-versionen
En gammel profil vælger IKEv1 med keyexchange=ikev1. En swanctl-forbindelse bruger en versionindstilling, hvor 1 vælger IKEv1. Det er to ordforråd for den samme idé, ikke en konvertering.
Modpartens adresser, lokale og fjernidentiteter, legitimationskilder, forslag og child-vælgere skal bevidst kortlægges. At indsætte en left/right-blok i swanctl-syntaks gør intet af det.
At ændre kun protokolversionen er den mest almindelige halvmigrering. Det giver en fil, der indlæses og derefter ikke godkendes af årsager, der intet har med versionen at gøre. IKEv1 selv er forældet af RFC 9395, så en eksisterende modpart, der stadig kræver det, fortjener en dokumenteret kompatibilitetsbegrænsning og en migreringsvej, ikke en ny standard.
Kontrollér indlæseren, før du rører profilen
Kør først indlæserkontrollen, indlæs derefter den tilsigtede forbindelse, vurder derefter forhandlingen og til sidst den beskyttede trafikvej. Hvert trin har sin egen fejlsignatur.
De to administrationsveje svarer direkte på indlæsningsspørgsmålet:
swanctl --list-conns
ipsec statusall
Kun én af disse kommandoer hører til din vært. At køre begge og sammenligne output er en måde at finde ud af, hvilken der lyver for dig, ikke en diagnostisk metode.
Behandl pakkeejerskab, konfigurationsindlæsning og protokolkempatibilitet som tre separate spørgsmål. En fil, der er gyldig for én frontend, bliver ellers redigeret igen og igen, mens en anden daemon er den, der kører.