ipsec.conf ou swanctl.conf? Escolha um frontend strongSwan

Um perfil IKEv1 funcional, tirado de um guia antigo, chega ao Ubuntu 24.04, e a primeira tentativa falha porque o daemon nunca leu o ficheiro. A reação habitual é editar o perfil outra vez. A verdadeira questão é qual frontend do strongSwan está instalado e qual o serviço em execução utiliza. Até isso ser respondido, cada edição aponta para um carregador que pode não existir.

Dois ficheiros, dois carregadores, um daemon

O antigo esquema starter lê o ipsec.conf e entrega as ligações ao charon através da sua integração de gestão antiga. O seu ponto de entrada operacional é o comando ipsec.

O esquema swanctl carrega definições através do VICI, lê o swanctl.conf e é conduzido pelo comando swanctl. O daemon charon nativo do systemd integra-se com essa abordagem.

Ambos podem ser instalados na mesma máquina, e é aí que começa a confusão. Um ficheiro em /etc prova apenas que alguém o escreveu, não que o processo em execução o tenha carregado. Instalar todas as alternativas para ver qual funciona cria um anfitrião com dois caminhos de gestão e sem dono claro. Escolha um esquema e remova ou desative o outro.

Leia os pacotes e as unidades instalados

Comece apenas para leitura. Os nomes dos pacotes no Ubuntu 24.04 são separados: strongswan-starter, strongswan-swanctl e charon-systemd. Um pacote ausente é informação útil, não uma instrução para o instalar.

Inventarie os pacotes e as unidades numa só passagem:

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

Depois inspecione a unidade ativa e o seu comando de arranque. O nome da unidade diz qual daemon detém a configuração, e a linha de comando confirma que ficheiros lhe foi pedido que lesse. Uma unidade ativada mas inativa conta uma história diferente da que está a correr agora.

Se a unidade ativa for strongswan-starter, o ficheiro que importa é o ipsec.conf. Se for charon-systemd com swanctl, o ipsec.conf é apenas decoração.

Use o caminho de controlo correspondente

Cada frontend tem a sua própria visão das ligações e associações. swanctl --list-conns mostra as definições carregadas e swanctl --list-sas mostra as associações ativas. O caminho antigo usa ipsec statusall.

Misturá-los produz erros enganadores. Um socket VICI ausente ou um pedido de controlo recusado é um problema do caminho de gestão, não a prova de que o par recusou a autenticação.

Leia a visão que pertence ao daemon em execução, e depois interprete o resultado. Se a ligação não aparece nessa visão, o problema é o carregamento, não a negociação.

O formato não é a versão do IKE

Um perfil antigo seleciona IKEv1 com keyexchange=ikev1. Uma ligação swanctl usa uma definição de versão, em que 1 seleciona IKEv1. São dois vocabulários para a mesma ideia, não uma conversão.

Os endereços do par, as identidades local e remota, as fontes de credenciais, as propostas e os seletores filho têm de ser mapeados de propósito. Colar um bloco left/right na sintaxe do swanctl não faz nada disso.

Alterar apenas a versão do protocolo é a meia-migração mais comum. Produz um ficheiro que carrega e depois falha a autenticação por motivos alheios à versão. O próprio IKEv1 está descontinuado pelo RFC 9395, por isso um par existente que ainda o exige merece uma restrição de compatibilidade documentada e um caminho de migração, não um novo valor predefinido.

Verifique o carregador antes de tocar no perfil

Execute primeiro a verificação do carregador, depois carregue a ligação pretendida, depois avalie a negociação e por fim o caminho do tráfego protegido. Cada etapa tem uma assinatura de falha diferente.

Os dois caminhos de controlo respondem diretamente à pergunta do carregamento:

swanctl --list-conns
ipsec statusall

Apenas um desses comandos pertence ao seu anfitrião. Executar ambos e comparar a saída é uma forma de descobrir qual lhe mente, não um método de diagnóstico.

Trate a propriedade dos pacotes, o carregamento da configuração e a compatibilidade do protocolo como três perguntas separadas. Um ficheiro válido para um frontend será editado repetidamente enquanto outro daemon é o que corre.