IPsec com várias sub-redes perde o tráfego de retorno? Conte os reqid
O tráfego em um só sentido por um túnel com várias sub-redes costuma ser uma divergência de política e reqid, não de criptografia ou roteamento. Leia os bancos xfrm na ordem certa.
O tráfego sai de um site e nunca volta, os dois gateways relatam uma negociação concluída, e a única pista é uma pilha de pacotes de saída sem respostas. Em um endpoint Linux, a causa habitual não é a força da criptografia, a MTU ou uma tabela de rotas. É a granularidade das entradas de política e o número que liga cada política a uma associação de segurança. O procedimento abaixo lê esses dois bancos antes de mexer em qualquer outra coisa.
Separe o sintoma antes de mudar qualquer coisa
Uma falha em um só sentido com uma negociação IKE concluída reduz o problema ao caminho de dados. Ou a política de saída correspondia e a resposta foi descartada, ou a resposta nunca chegou porque o outro lado não tinha por onde enviá-la. Do ponto de vista de uma aplicação, os dois casos parecem iguais, e os bancos xfrm os distinguem.
Não comece pela MTU. Uma MTU errada produz travamentos e sintomas de fragmentação, não uma separação limpa de direção com contadores de saída subindo.
Leia o banco de políticas e o banco de estados
No Linux a criptografia é decidida pelas entradas de política, então uma política correspondente, não uma rota, é o que coloca um pacote no túnel. Execute ip xfrm policy para ver os seletores, a direção, a prioridade e o modelo de cada entrada, e ip xfrm state para ver as associações estabelecidas com seus reqid. A política e a associação são ligadas por esse reqid.
Olhe as três direções. Saída e entrada cobrem o tráfego de e para este host; a direção de encaminhamento importa quando o host roteia por outros. Uma entrada ausente ou divergente em uma direção explica um resultado em um só sentido sem nenhuma falha criptográfica.
A assimetria clássica: um reqid para várias sub-redes
Uma falha comum vem de um par que instala políticas para todas as sub-redes negociadas sob um único reqid, o que acontece com generate_policy require do racoon. O tráfego sai então pela associação estabelecida por último, enquanto o outro lado mantém uma associação separada por sub-rede. As respostas chegam por uma associação cujo reqid não identifica a política que deveria aceitá-las, e o kernel as descarta após a descriptografia.
A correção é uma mudança de configuração, não uma regra de firewall: generate_policy unique; dá a cada política seu próprio reqid, de modo que as associações por política do par tenham parceiras correspondentes. Aplique, renegocie e conte os reqid distintos para as sub-redes esperadas antes de declarar sucesso.
Se duas sub-redes ainda compartilham um reqid enquanto o outro lado espera dois, você encontrou a assimetria. Registre o mapeamento, porque ele é a prova de que a próxima mudança a corrigiu ou a preservou.
Os seletores vêm da negociação, não da sua configuração
Os intervalos protegidos são o que ambos os lados acordaram, não o que um dos lados pediu. Um cliente que oferece um par de hosts contra um intervalo remoto amplo recebe a versão estreitada do gateway, e o cliente não pode ampliá-la. Leia os seletores instalados em vez dos do seu arquivo local.
Quando o objetivo é o oposto, manter um destino fora do túnel, acrescente uma política de desvio com um número de prioridade menor para que ela vença a entrada instalada automaticamente. Uma política sem modelo permite texto simples, o que a torna uma exceção deliberada para um registro de mudanças em vez de uma etapa de depuração.
Verifique nesta ordem, e saiba como reverter
Liste as políticas de cada sub-rede nas duas direções, incluindo o encaminhamento se o host rotear. Conte os reqid distintos e confirme um por política no lado que o espera. Compare os seletores instalados com os negociados. Releia os contadores por associação após uma renovação de chave, porque a associação inspecionada pode já ter sumido. Verifique as rotas por último, já que uma rota ausente para a sub-rede remota produz um sintoma semelhante em um só sentido com contadores de política limpos.
Antes de alterar o par, salve a saída atual dos dois comandos xfrm. Se o novo ajuste não restaurar a direção de retorno, restaurar essa saída é uma reversão mais rápida do que reconstruir o túnel de memória, e mantém a comparação honesta.