Túnel completo no strongSwan exige 0.0.0.0/0 nos dois lados

Uma conexão strongSwan que funciona para uma única sub-rede privada não transportará tráfego de internet só porque alguém editou uma linha. Um túnel completo é um acordo entre dois lados sobre quais endereços a child SA protege, e cada lado nomeia o outro em relação a si mesmo. Acerte um lado e erre o outro, e a child SA ou não sobe ou sobe mais estreita do que o pretendido. As cinco verificações abaixo seguem esse acordo do cliente, pela gateway, até a internet.

Verifique primeiro o seletor do cliente

O cliente descreve o que quer proteger no lado remoto como remote_ts, e tudo o que ele envia parte do seu próprio endereço atribuído. Para tráfego de internet esse valor precisa cobrir os destinos que o usuário realmente alcançará, o que na prática significa todo o espaço IPv4. Um cliente que ainda lista uma sub-rede pede um túnel dividido, seja qual for o nome do perfil na interface. O lado de origem costuma ser dynamic porque o endereço é atribuído na conexão. Uma origem fixa escrita ali quebra assim que o conjunto de endereços muda.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

O fragmento não é um arquivo de conexão completo, e este assume que autenticação, identidades e o conjunto de endereços virtuais já estão configurados. O seletor de origem do cliente e o endereço atribuído pelo servidor ainda precisam coincidir, senão a child SA sobe com um escopo que nenhum dos lados esperava. Carregue-o com swanctl --load-all e leia a saída antes de supor sucesso. Um arquivo que é analisado ainda pode ser rejeitado por um seletor que não se sobrepõe à proposta do outro lado.

Verifique o seletor da gateway no lado dela

A gateway lê o mesmo conceito na direção oposta. Os destinos de internet são locais para a gateway, então o local_ts dela é o amplo e o remote_ts descreve o conjunto de clientes. Essa inversão é o erro mais comum numa configuração de túnel completo, e sobrevive à revisão porque as duas linhas parecem plausíveis isoladamente.

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

Copiar o fragmento do cliente para o arquivo da gateway produz um par de seletores que não descreve nada útil, porque os dois lados reivindicariam o mesmo papel. O guia de encaminhamento do strongSwan documenta explicitamente o emparelhamento de cliente e gateway, e vale lê-lo ao lado do arquivo de conexão em vez de depois da falha. O arquivo da gateway também precisa da definição do conjunto que remote_ts referencia. Um seletor que nomeia um conjunto inexistente carrega sem reclamação e falha ao conectar.

O antigo ipsec.conf usa papéis esquerdo e direito com chaves diferentes, e uma linha rightsubnet não é um substituto direto do valor de swanctl. Mantenha as duas sintaxes em arquivos separados em vez de colar uma dentro da outra. Misturá-las num mesmo diretório é como uma conexão que funciona recua em silêncio após um reinício.

Verifique a child SA negociada, não o arquivo

Uma configuração salva prova a intenção e nada mais. O outro lado pode estreitar o que foi pedido, e uma child SA existente não é substituída só porque o arquivo abaixo mudou. Confirme o que está realmente instalado antes de mudar qualquer outra coisa.

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

O primeiro comando mostra o que o daemon carregou, o segundo mostra as child SA estabelecidas e o terceiro as políticas que o kernel aplicará. Se o arquivo diz 0.0.0.0/0 e a listagem mostra uma única sub-rede, a negociação estreitou o escopo e reler o arquivo não explicará isso. Encerre a child, reinicie-a e compare as três saídas novamente. Uma child que volta com o mesmo escopo estreito está sendo estreitada pelo outro lado e não pelo arquivo local, e isso é uma conversa com o outro administrador em vez de uma edição local.

Leia as duas direções na listagem de políticas, porque um túnel que instala uma direção e não a outra é um problema de roteamento disfarçado de configuração. As políticas de ida e volta devem nomear o mesmo par de seletores em imagem espelhada, e um espelho ausente é um defeito no daemon ou na proposta, não no texto do seletor.

Verifique o encaminhamento e a rota de retorno

Um seletor admite tráfego até a gateway, mas não faz a gateway encaminhar esse tráfego adiante. O encaminhamento precisa estar ativo, o firewall precisa permitir o fluxo e a resposta precisa encontrar o caminho de volta ao conjunto de clientes. São três requisitos separados, e cada um falha com um sintoma diferente. Uma regra de encaminhamento ausente se comporta como um buraco negro, enquanto uma rota de retorno ausente se comporta como um túnel de mão única.

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

Endereços privados de clientes normalmente precisam de tradução de origem deliberada antes de sair por uma interface pública, enquanto uma atribuição roteada explicitamente exige outro tratamento. Se houver NAT, mantenha as exceções suportadas pela implementação para que o tráfego que uma política de segurança deve inspecionar não seja traduzido por cima dela. Uma regra masquerade ampla copiada de outra gateway altera muito mais fluxos do que o autor pretendia. Escreva a regra apenas para o conjunto de clientes e deixe um comentário explicando por que ela existe.

No cliente, confirme as rotas instaladas pelo backend em vez das rotas que você supôs. Um gestor com a instalação de rotas desativada precisa de um desenho de roteamento mantido à mão, e esse desenho deve ser atualizado sempre que o túnel mudar. Verifique a tabela de roteamento após reconectar, não apenas após um arranque novo.

Verifique o que o túnel ainda não cobre

O par de seletores cobre IPv4 e nada mais. IPv6, DNS e qualquer política no nível da aplicação são decisões separadas que um seletor IPv4 amplo ignora em silêncio. Um túnel que transporta cada pacote IPv4 ainda pode vazar cada consulta de nome.

Declare explicitamente o caminho DNS pretendido, porque um túnel completo que ainda resolve nomes pelo resolvedor local vaza consultas para fora do túnel e quebra nomes privados. Se o cliente receber um endereço IPv6, essa família de endereços precisa do mesmo tratamento, senão o host preferirá um caminho que o túnel não protege. Teste com um nome que só o lado privado consegue responder, e trate uma resposta pública como vazamento.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Confirme a cadeia com esses dois comandos mais os seletores negociados da listagem acima. Se o traceroute mostra o router local como primeiro salto, o tráfego não usa o túnel, digam o que disserem os seletores. O acesso à internet só está completo quando o tráfego escolhido é admitido, encaminhado e devolvido pela gateway projetada. Encontrar 0.0.0.0/0 num perfil é o começo dessa cadeia, não a prova.