Modo trap do strongSwan: por que o túnel IPsec espera tráfego

Um túnel IPsec inativo sob demanda não mostra nenhum CHILD SA até um pacote corresponder à sua política trap. Leia o estado, verifique o gatilho e saiba quando start se encaixa.

Nenhum CHILD SA aparece na saída de status, o túnel parece morto e, então, um ping para a sub-rede remota o levanta. Numa configuração IPsec sob demanda, essa sequência é o desenho, não uma falha. Uma política trap instala um seletor e espera, e o primeiro pacote que corresponde a ela é o que inicia o IKE e a negociação do CHILD SA.

Parte da confusão é de vocabulário: “up” é usado para dois estados diferentes. A configuração está carregada e a política do kernel existe, mas a associação de dados não. Um monitor que só conta SAs ativas reportará um site saudável como fora do ar enquanto ninguém lhe enviar tráfego.

Um túnel inativo sob demanda não tem CHILD SA para mostrar

Uma entrada trap não autentica nada por si mesma. Ela pede ao kernel que mantenha uma política para o tráfego selecionado e levante uma acquisition quando um pacote precisar dessa política. O daemon recebe a acquisition, associa-a à definição child e negocia a partir daí. Até esse ponto também não há IKE SA para mostrar, por isso as duas listas podem estar vazias ao mesmo tempo.

É essa ordem que torna os logs legíveis. Primeiro vem a acquisition, depois IKE_SA_INIT e IKE_AUTH, depois o CHILD SA. Se o log termina logo após a acquisition, o gatilho funcionou. A negociação falhou, e a próxima pergunta é sobre credenciais, propostas ou alcance, não sobre a trap.

Com o backend do kernel Linux você pode ver a política antes que qualquer SA exista. Execute ip xfrm policy e procure o seletor com direção out e um template apontando para a conexão. Essa entrada é o estado sob demanda, e sua presença é a primeira coisa a confirmar.

start_action decide se algo sequer espera

Cada child em swanctl.conf carrega um start_action. start inicia quando a configuração carrega, trap instala a política e espera, e none deixa o início para outra coisa. Só trap produz o comportamento “ping e ele sobe” descrito acima.

children {
    office-lan {
        local_ts = 192.168.50.0/24
        remote_ts = 192.168.70.0/24
        start_action = trap
    }
}

Os dois seletores de tráfego definem o que conta como interessante, e um pacote de um host fora desses prefixos não dispara a trap; ele é roteado como de costume. Alargar os seletores para deixar o gatilho mais ávido também alarga o escopo que o túnel afirma proteger, então derive-os do tráfego que você realmente pretende cifrar.

A referência do swanctl.conf lista os valores aceitos, junto com as ações separadas close e DPD que regem o que acontece depois que a SA existe.

Descubra se o gatilho disparou

Comece com swanctl --list-conns e confirme que o child está carregado com a ação pretendida. Depois envie um pacote de um host dentro de local_ts para um endereço dentro de remote_ts e observe swanctl --list-sas. Se a saída não mudar, nenhuma acquisition chegou ao daemon.

Dois motivos comuns de uma trap silenciosa: o pacote passou por source-NAT antes de atingir a política e já não corresponde a local_ts, ou a conexão nunca carregou por um erro de sintaxe ou de credenciais. Execute novamente swanctl --load-all e leia a saída antes de mexer nos seletores. Uma conexão que não carregou não instala política, então não há nada que o tráfego possa disparar.

A direção também importa: uma trap instalada para tráfego de saída não inicia com um pacote de entrada. Se o lado remoto deve levantar o túnel, ele precisa da própria trap, ou este lado precisa de start.

Esperar o primeiro pacote nem sempre é a troca certa

Sessões interativas sentem o custo da configuração. A primeira requisição paga pela troca IKE e pela negociação CHILD, e um cliente com prazo curto pode desistir antes da SA existir. Um start proativo elimina esse atraso do primeiro pacote. Mas mantém um túnel aberto para tráfego que talvez nunca chegue.

Três fatos decidem a escolha: com que frequência o caminho é usado, se a primeira requisição tem prazo apertado e se o peer é alcançável na inicialização. Tráfego em lote ocasional e um peer que pode estar offline na inicialização favorecem ambos trap. Um cliente sensível a latência e um peer sempre alcançável favorecem start. Se ambos os lados podem iniciar, combinem quem possui o gatilho para não haver negociações duplicadas.

Uma política instalada também não é garantia à prova de vazamentos. Se o requisito é fail-closed, o firewall deve descartar tráfego sem SA, e essa regra vive fora da definição child.

Anote as três linhas que encerram a próxima discussão

Escreva os seletores, a ação de inicialização e a saída do comando que mostra a política presente sem SA. Essas três linhas separam “sob demanda e inativo” de “não carrega” na próxima vez que alguém relatar o túnel como fora do ar. Custam um minuto para registrar. Sem elas, a mesma investigação recomeça do zero.

Teste a partir de um host que esteja realmente dentro do seletor. Um ping do próprio roteador costuma seguir outro caminho e não prova nada sobre a política que protege a sub-rede atrás dele.

Artigos relacionados