¿ipsec.conf o swanctl.conf? Elija un frontend de strongSwan

Un perfil IKEv1 que funciona, sacado de una guía antigua, llega a Ubuntu 24.04, y el primer intento falla porque el demonio nunca leyó el archivo. La respuesta habitual es volver a editar el perfil. La pregunta real es qué frontend de strongSwan está instalado y cuál usa el servicio en ejecución. Hasta que eso se responda, cada edición apunta a un cargador que puede no existir.

Dos archivos, dos cargadores, un demonio

El antiguo esquema starter lee ipsec.conf y entrega las conexiones a charon mediante su integración de gestión heredada. Su punto de entrada operativo es el comando ipsec.

El esquema swanctl carga definiciones por VICI, lee swanctl.conf y se controla con el comando swanctl. El demonio charon nativo de systemd se integra con ese enfoque.

Ambos pueden instalarse en la misma máquina, y ahí empieza la confusión. Un archivo bajo /etc solo demuestra que alguien lo escribió, no que el proceso en ejecución lo haya cargado. Instalar todas las alternativas para ver cuál funciona crea un host con dos rutas de gestión y sin propietario claro. Elija un esquema y elimine o desactive el otro.

Lea los paquetes y las unidades instalados

Empiece en modo de solo lectura. Los nombres de los paquetes en Ubuntu 24.04 están separados: strongswan-starter, strongswan-swanctl y charon-systemd. Un paquete ausente es información útil, no una instrucción para instalarlo.

Inventaríe los paquetes y las unidades en una sola pasada:

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

Después inspeccione la unidad activa y su comando de arranque. El nombre de la unidad dice qué demonio posee la configuración, y la línea de comandos confirma qué archivos se le pidió leer. Una unidad habilitada pero inactiva cuenta una historia distinta de la que se ejecuta ahora.

Si la unidad activa es strongswan-starter, el archivo que importa es ipsec.conf. Si es charon-systemd con swanctl, ipsec.conf es solo decoración.

Use la ruta de control correspondiente

Cada frontend tiene su propia visión de las conexiones y las asociaciones. swanctl --list-conns muestra las definiciones cargadas y swanctl --list-sas muestra las asociaciones activas. La ruta antigua usa ipsec statusall.

Mezclarlos produce errores engañosos. Un socket VICI ausente o una solicitud de control rechazada es un problema de la ruta de gestión, no una prueba de que el par haya rechazado la autenticación.

Lea la visión que pertenece al demonio en ejecución, y luego interprete el resultado. Si la conexión no aparece en esa visión, el problema es la carga, no la negociación.

El formato no es la versión de IKE

Un perfil antiguo selecciona IKEv1 con keyexchange=ikev1. Una conexión swanctl usa un ajuste de versión, donde 1 selecciona IKEv1. Son dos vocabularios para la misma idea, no una conversión.

Las direcciones del par, las identidades local y remota, las fuentes de credenciales, las propuestas y los selectores hijo deben mapearse a propósito. Pegar un bloque left/right en la sintaxis de swanctl no hace nada de eso.

Cambiar solo la versión del protocolo es la media migración más común. Produce un archivo que carga y luego falla la autenticación por motivos ajenos a la versión. IKEv1 está desaconsejado por el RFC 9395, así que un par existente que aún lo exige merece una restricción de compatibilidad documentada y una ruta de migración, no un valor por defecto nuevo.

Compruebe el cargador antes de tocar el perfil

Ejecute primero la comprobación del cargador, luego cargue la conexión prevista, después evalúe la negociación y por último la ruta del tráfico protegido. Cada etapa tiene una firma de fallo distinta.

Las dos rutas de control responden directamente a la pregunta de la carga:

swanctl --list-conns
ipsec statusall

Solo uno de esos comandos pertenece a su host. Ejecutar ambos y comparar la salida es una forma de descubrir cuál le miente, no un método de diagnóstico.

Trate la propiedad de los paquetes, la carga de la configuración y la compatibilidad del protocolo como tres preguntas separadas. Un archivo válido para un frontend se editará una y otra vez mientras otro demonio es el que se ejecuta.