Um perfil carregado do strongSwan não é um túnel ativo

Listar uma conexão na configuração do strongSwan prova apenas que uma definição foi carregada. Não significa que o par tenha sido contatado, que exista uma SA de IKE ou que algum tráfego esteja protegido. O daemon trata definições e associações vivas como objetos separados, e a distância entre eles é uma escolha de projeto deliberada. Saber qual objeto você está inspecionando transforma uma falha vaga em um próximo comando concreto.

Carregar não é conectar

Uma conexão carregada é uma declaração sobre o que poderá ser negociado depois: endereços do par, credenciais, propostas e seletores de tráfego. Nada nessa declaração exige que o daemon tenha discado para alguém. Um gateway pode esperar pelo outro lado, iniciar na inicialização ou esperar que um tráfego correspondente o desperte. As três são válidas, e as três parecem idênticas no arquivo de configuração até você ler a política de início.

Os operadores entram em apuros ao ler a lista de definições como uma lista de status. O perfil está lá, então o túnel é dado como ativo, e a hora seguinte vai embora depurando rotas para uma associação que nunca foi construída.

O erro oposto é igualmente comum. Um perfil ausente manda as pessoas caçarem uma falha de rede quando a configuração nunca foi carregada. Nomeie o objeto e depois execute o comando que o observa.

Três objetos, três observações

O strongSwan mantém uma definição carregada, uma SA de IKE e uma SA CHILD. A primeira é configuração, a segunda é uma relação de controle autenticada e a terceira é proteção negociada para o tráfego selecionado. Eles têm até nomes separados, então um perfil chamado hq pode possuir um child chamado hq-lan.

A tabela associa cada camada ao comando que a mostra. Leia a linha antes de ler o log.

Solicitar o child constrói primeiro a sua SA de IKE pai quando não existe nenhuma. Solicitar apenas a SA de IKE é uma chamada diferente. Um canal de controle que se autentica bem não garante o child que você pediu.

Essa diferença importa durante uma falha parcial. Uma SA de IKE pode estar saudável enquanto o child falha por uma divergência de seletor ou uma proposta que o par não aceita. Os dois objetos falham por motivos diferentes, então merecem observações separadas.

Escolha a ação de início deliberadamente

No swanctl.conf, o start_action de um child decide o comportamento após o carregamento. O padrão none deixa a definição para iniciação manual ou uso como respondedor. start disca, enquanto trap deixa uma política que negocia assim que aparece tráfego correspondente.

Assim, tanto «o carregamento nunca inicia um túnel» quanto «o carregamento sempre inicia um» estão errados. A ação faz parte do perfil e deve corresponder ao papel do par. Dois gateways que esperam um pelo outro produzem silêncio, não um túnel.

Com trap, o tráfego precisa corresponder aos seletores, então um ping não relacionado não acorda nada. Com start, o endereço do par precisa ser utilizável e os dois lados precisam concordar sobre autenticação e propostas. Nenhuma das ações substitui a verificação dessas premissas.

A recuperação é uma política separada

A inicialização não é um keepalive. Detecção de par morto, fechamento explícito pelo par, renovação de chaves e reinício do processo são eventos de ciclo de vida diferentes, com configurações próprias. Configure cada um deliberadamente em vez de esperar que um início inicial cubra todos.

Um túnel que sobe na inicialização e morre uma hora depois é uma questão de recuperação. A política de início fez o seu trabalho e depois deixou de importar. Veja as configurações de DPD e de renovação de chaves antes de culpar a negociação inicial.

Substituir definições carregadas é uma operação própria. Políticas de início não padrão têm ações inversas documentadas, e uma recarga é uma mudança operacional em vez de uma suposição de que toda associação foi atualizada no local. Faça recargas em etapas, onde uma reconexão seja aceitável. Mantenha a configuração antiga até a nova estar comprovada.

Verifique o que existe antes de depurar o roteamento

Execute as três observações em ordem: definições carregadas, SA de IKE ativas e entradas de child. Cada resposta estreita a próxima pergunta. Pule uma etapa e você acaba depurando uma camada que nunca foi construída.

Comece pelo que está carregado e pelo que está de fato estabelecido:

swanctl --list-conns
swanctl --list-sas

Se o child estiver faltando enquanto o perfil está correto, inicie-o pelo nome e observe o que acontece. A saída geralmente diz se o pai subiu primeiro.

swanctl --initiate --child hq-lan

Uma SA CHILD ativa não é a linha de chegada. Regras de encaminhamento, rotas e a autorização da própria aplicação ainda precisam se alinhar. O ciclo de vida responde o que foi negociado; ele não pode decidir quem pode usar o serviço.