ipsec.conf o swanctl.conf? Trieu un frontend de strongSwan

Un perfil IKEv1 que funciona, tret d'una guia antiga, arriba a Ubuntu 24.04, i el primer intent falla perquè el dimoni no va llegir mai el fitxer. La resposta habitual és tornar a editar el perfil. La pregunta real és quin frontend de strongSwan està instal·lat i quin fa servir el servei en execució. Fins que això no es respongui, cada edició apunta a un carregador que potser no existeix.

Dos fitxers, dos carregadors, un dimoni

L'antic esquema starter llegeix ipsec.conf i passa les connexions a charon mitjançant la seva integració de gestió heretada. El seu punt d'entrada operatiu és l'ordre ipsec.

L'esquema swanctl carrega definicions per VICI, llegeix swanctl.conf i es controla amb l'ordre swanctl. El dimoni charon natiu de systemd s'integra amb aquest enfocament.

Tots dos es poden instal·lar a la mateixa màquina, i aquí comença la confusió. Un fitxer sota /etc només demostra que algú el va escriure, no que el procés en execució l'hagi carregat. Instal·lar totes les alternatives per veure quina funciona crea un amfitrió amb dos camins de gestió i sense propietari clar. Trieu un esquema i elimineu o desactiveu l'altre.

Llegiu els paquets i les unitats instal·lats

Comenceu en mode només lectura. Els noms dels paquets a Ubuntu 24.04 són separats: strongswan-starter, strongswan-swanctl i charon-systemd. Un paquet absent és informació útil, no una instrucció per instal·lar-lo.

Inventarieu els paquets i les unitats d'una sola passada:

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

Després inspeccioneu la unitat activa i la seva ordre d'arrencada. El nom de la unitat indica quin dimoni posseeix la configuració, i la línia d'ordres confirma quins fitxers se li va ordenar llegir. Una unitat habilitada però inactiva explica una història diferent de la que s'executa ara.

Si la unitat activa és strongswan-starter, el fitxer que importa és ipsec.conf. Si és charon-systemd amb swanctl, ipsec.conf és només decoració.

Feu servir el camí de control corresponent

Cada frontend té la seva pròpia visió de les connexions i les associacions. swanctl --list-conns mostra les definicions carregades i swanctl --list-sas mostra les associacions actives. El camí antic fa servir ipsec statusall.

Barrejar-los produeix errors enganyosos. Un sòcol VICI absent o una sol·licitud de control rebutjada és un problema del camí de gestió, no una prova que el parell hagi rebutjat l'autenticació.

Llegiu la visió que pertany al dimoni en execució, i després interpreteu el resultat. Si la connexió no apareix en aquesta visió, el problema és la càrrega, no la negociació.

El format no és la versió d'IKE

Un perfil antic selecciona IKEv1 amb keyexchange=ikev1. Una connexió swanctl fa servir un paràmetre de versió, on 1 selecciona IKEv1. Són dos vocabularis per a la mateixa idea, no una conversió.

Les adreces del parell, les identitats local i remota, les fonts de credencials, les propostes i els selectors fill s'han de mapar a propòsit. Enganxar un bloc left/right a la sintaxi de swanctl no fa res d'això.

Canviar només la versió del protocol és la migració a mitges més habitual. Produeix un fitxer que es carrega i després no autentica per motius aliens a la versió. IKEv1 mateix està obsolet per l'RFC 9395, així que un parell existent que encara el requereix mereix una restricció de compatibilitat documentada i un camí de migració, no un valor per defecte nou.

Comproveu el carregador abans de tocar el perfil

Executeu primer la comprovació del carregador, després carregueu la connexió prevista, després avalueu la negociació i després el camí del trànsit protegit. Cada etapa té una signatura de fallada diferent.

Els dos camins de control responen directament a la pregunta de la càrrega:

swanctl --list-conns
ipsec statusall

Només una d'aquestes ordres pertany al vostre amfitrió. Executar totes dues i comparar la sortida és una manera de descobrir quina us menteix, no un mètode de diagnòstic.

Tracteu la propietat dels paquets, la càrrega de la configuració i la compatibilitat del protocol com a tres qüestions separades. Un fitxer vàlid per a un frontend s'editarà una i altra vegada mentre un altre dimoni és el que s'executa.