ipsec.conf ou swanctl.conf? Escolla un frontend de strongSwan

Un perfil IKEv1 que funciona, sacado dunha guía antiga, chega a Ubuntu 24.04, e o primeiro intento falla porque o daemon nunca leu o ficheiro. A resposta habitual é volver editar o perfil. A pregunta real é que frontend de strongSwan está instalado e cal usa o servizo en execución. Ata que iso se responda, cada edición apunta a un cargador que pode non existir.

Dous ficheiros, dous cargadores, un daemon

O antigo esquema starter le ipsec.conf e entrega as conexións a charon mediante a súa integración de xestión heredada. O seu punto de entrada operativo é o comando ipsec.

O esquema swanctl carga definicións por VICI, le swanctl.conf e contrólase co comando swanctl. O daemon charon nativo de systemd intégrase con ese enfoque.

Ambos poden instalarse na mesma máquina, e aí comeza a confusión. Un ficheiro baixo /etc só demostra que alguén o escribiu, non que o proceso en execución o cargase. Instalar todas as alternativas para ver cal funciona crea un host con dúas rutas de xestión e sen propietario claro. Escolla un esquema e elimine ou desactive o outro.

Lea os paquetes e as unidades instalados

Comece en modo de só lectura. Os nomes dos paquetes en Ubuntu 24.04 están separados: strongswan-starter, strongswan-swanctl e charon-systemd. Un paquete ausente é información útil, non unha instrución para instalalo.

Inventaríe os paquetes e as unidades nunha soa pasada:

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

Despois inspeccione a unidade activa e o seu comando de arranque. O nome da unidade di que daemon posúe a configuración, e a liña de comandos confirma que ficheiros se lle pediu ler. Unha unidade habilitada pero inactiva conta unha historia distinta da que se executa agora.

Se a unidade activa é strongswan-starter, o ficheiro que importa é ipsec.conf. Se é charon-systemd con swanctl, ipsec.conf é só decoración.

Use a ruta de control correspondente

Cada frontend ten a súa propia visión das conexións e das asociacións. swanctl --list-conns mostra as definicións cargadas e swanctl --list-sas mostra as asociacións activas. A ruta antiga usa ipsec statusall.

Mesturalos produce erros enganosos. Un socket VICI ausente ou unha solicitude de control rexeitada é un problema da ruta de xestión, non unha proba de que o par rexeitase a autenticación.

Lea a visión que pertence ao daemon en execución, e despois interprete o resultado. Se a conexión non aparece nesa visión, o problema é a carga, non a negociación.

O formato non é a versión de IKE

Un perfil antigo selecciona IKEv1 con keyexchange=ikev1. Unha conexión swanctl usa un axuste de versión, onde 1 selecciona IKEv1. Son dous vocabularios para a mesma idea, non unha conversión.

Os enderezos do par, as identidades local e remota, as fontes de credenciais, as propostas e os selectores fillo deben mapearse a propósito. Pegar un bloque left/right na sintaxe de swanctl non fai nada diso.

Cambiar só a versión do protocolo é a media migración máis común. Produce un ficheiro que carga e logo falla a autenticación por motivos alleos á versión. IKEv1 está desaconsellado polo RFC 9395, así que un par existente que aínda o esixe merece unha restrición de compatibilidade documentada e unha ruta de migración, non un valor por defecto novo.

Comprobe o cargador antes de tocar o perfil

Execute primeiro a comprobación do cargador, logo cargue a conexión prevista, despois avalíe a negociación e por último a ruta do tráfico protexido. Cada etapa ten unha sinatura de fallo distinta.

As dúas rutas de control responden directamente á pregunta da carga:

swanctl --list-conns
ipsec statusall

Só un destes comandos pertence ao seu host. Executar ambos e comparar a saída é unha forma de descubrir cal lle mente, non un método de diagnóstico.

Trate a propiedade dos paquetes, a carga da configuración e a compatibilidade do protocolo como tres preguntas separadas. Un ficheiro válido para un frontend editarase unha e outra vez mentres outro daemon é o que se executa.