Por que uma política de segurança IPsec não é uma entrada na tabela de rotas

Faça ping em 10.20.0.5 pelo túnel e nada volta, enquanto a tabela de rotas insiste que essa sub-rede é alcançável. O roteamento e o IPsec respondem a perguntas diferentes, e apenas uma delas é sobre alcançabilidade. A consulta direta escolhe um caminho, depois a base de dados de política de segurança decide se esse caminho deve ser protegido, deixado como está ou recusado. Quando os dois discordam, o pacote morre em silêncio, então leia-os nessa ordem.

Comece pela consulta, não pela tabela

Pergunte ao kernel o que ele realmente faria: ip route get 10.20.0.5 mostra a rota escolhida, a interface de saída e o endereço de origem que usaria. Um prefixo, uma regra de política, uma marca ou uma origem preferida podem mudar essa resposta, e é por isso que a consulta ao vivo supera ler a tabela a olho.

Teste um destino dentro do intervalo protegido, não o endereço do gateway. Alcançar o gateway do outro lado só prova que existe alguma rota; não diz nada sobre a sub-rede de que você realmente precisa. Depois confirme que a interface escolhida pela consulta é a que você espera que o túnel use.

Faça coincidir os seletores dos dois lados

A base de dados de política tem as suas próprias entradas, e cada uma nomeia uma direção, uma origem, um destino e um protocolo, e depois diz o que deve acontecer aos pacotes que coincidem. Use ip xfrm policy para as listar; os indicadores mostram se a ação é proteger, contornar ou bloquear. Uma política cujos seletores são mais amplos ou mais estreitos do que o seu fluxo de teste não coincidirá com ele, e o pacote sai sem proteção. Essa é a falha que procura, não uma rota em falta.

Compare os valores reais: origem, destino, protocolo e portas. Se a consulta resolveu um par de endereços enquanto a entrada de política cobre outro, as duas vistas descrevem tráfego diferente. Execute novamente as duas com o mesmo tuple antes de tirar uma conclusão, ou vai editar uma política que nunca esteve no caminho.

Uma correspondência de política não é estado instalado

Uma política correspondente diz apenas que o pacote deve ser protegido; o kernel ainda precisa de uma associação de segurança para fazer a proteção. Liste-as com ip xfrm state, ou com swanctl --list-sas quando o strongSwan conduz a negociação, e leia os seletores e os contadores de cada entrada.

Quando uma política coincide e nenhuma associação cobre os mesmos seletores, o pacote é descartado em vez de enviado em texto claro. É esse descarte que deve procurar quando o túnel está ativo mas uma única sub-rede falha. Os contadores dizem o resto: uma associação que nunca aumenta nunca foi selecionada, enquanto uma que aumenta e ainda assim acaba num descarte aponta para o lado remoto. Corrigir seletores e renovar chaves são reparações diferentes, por isso decida qual precisa antes de tocar na configuração.

O que um túnel baseado em rota ainda exige

Uma interface XFRM faz o túnel parecer um dispositivo para o qual pode encaminhar, o que é realmente útil. Não elimina a política e o estado que decidem o que acontece quando o pacote chega lá. A rota contribui com um próximo salto e nada mais.

Se o dispositivo existe e a rota aponta para ele enquanto nenhuma associação coincide com os seletores internos, o pacote é descartado, e nenhuma quantidade de edição de rotas produz chaves ou seletores. Verifique a interface com a mesma origem e destino que encaminhou, e depois compare isso com a lista de estados.

Esclareça a propriedade antes de editar qualquer coisa

Um firewall do host acrescenta uma terceira decisão que nenhuma das duas bases de dados conhece. Uma rota correta mais uma política correspondente mais uma associação instalada ainda podem terminar num pacote descartado, e a aplicação relata apenas o tempo limite. Confirme que o firewall permite o tráfego protegido antes de culpar o IPsec. Capturar no dispositivo do túnel e na interface física mostra de que lado da criptografia o pacote desapareceu.

A propriedade da configuração decide se a sua correção sobrevive a um reinício. Um componente pode instalar estado enquanto outro gere rotas, e uma edição manual no segundo é substituída na próxima vez que o túnel sobe. Altere a configuração proprietária e depois volte a ler as duas vistas; RFC 4301 mantém as duas bases de dados separadas quando tem de explicar a divisão a outra pessoa.