A política de IPsec está engolindo seu tráfego local: como saber

A impressora sobre a mesa para de responder no momento em que o túnel sobe, e nada na configuração do túnel menciona a impressora. O que costuma ter acontecido é que uma faixa protegida foi escrita ampla o bastante para incluí-la, então a máquina agora tenta criptografar tráfego que deveria ficar no segmento local. Ler a política instalada explica a captura; restringi-la no lugar certo mantém o tráfego remoto protegido. O caminho da requisição que falha até a política correspondente leva alguns minutos.

Percorra o fluxo antes de mudar um seletor

Comece pela requisição que falha e anote quatro valores: o endereço de origem que a máquina usa, o destino exato, a rota que o kernel escolhe e a política que corresponde a esse par.

Esses quatro fatos decidem se a captura é deliberada ou acidental. Um destino que cai dentro do seletor remoto está protegido por projeto, mesmo que o projeto estivesse errado. Um destino fora dele que ainda assim é capturado significa que outra coisa está correspondendo, e mudar o seletor não vai ajudar. Os dois casos são comuns, e um único comando os distingue.

Faça isso antes de editar qualquer coisa, porque o caso interessante é a sub-rede local que se sobrepõe a uma faixa privada que a conexão protege. Prefixos familiares como 192.168.0.0/16 aparecem em muitas redes, e um seletor escrito para um deles pode cobrir silenciosamente o seu.

Três tipos de local que se comportam de forma diferente

Um destino atribuído a este host, um destino no mesmo link e um destino atrás de outra interface são três casos diferentes. O kernel trata cada um de forma diferente quando decide se o tráfego precisa de proteção.

O tráfego gerado pelo próprio gateway também não é o mesmo que o tráfego encaminhado de um cliente. Uma política que parece correta para o tráfego encaminhado pode capturar a própria sessão de gerenciamento do gateway, e é assim que um administrador perde o acesso enquanto conserta o túnel.

O hábito útil é nomear o caso em voz alta: este pacote vem de mim, vai para o meu link ou passa por mim? Cada resposta aponta para um lugar diferente de restringir. Anotar o caso também impede que a próxima pessoa refaça o mesmo trabalho.

Quando a faixa protegida é um espaço privado inteiro, os três casos podem cair dentro dela ao mesmo tempo, e o sintoma passa a ser uma máquina que não alcança nada além do extremo do túnel.

Leia a política instalada, não o arquivo

Os arquivos de configuração descrevem a intenção; o kernel guarda as políticas que de fato correspondem. Mostre os dois e trate uma divergência como o primeiro achado.

Estes comandos mostram a rota escolhida para o destino e as políticas instaladas em cada direção:

ip route get 192.168.50.20
ip xfrm policy list
sudo swanctl --list-conns

A rota diz qual interface o pacote usaria. A lista de políticas diz se um modelo é então aplicado a esse pacote, e a lista de conexões mostra quais seletores o daemon acredita ter instalado. Se o destino aparecer em um seletor remoto, você achou a captura sem adivinhar.

Restrinja o seletor ou contorne o destino

Há dois reparos suportados e eles respondem a perguntas diferentes. Restringir o seletor diz que esta conexão protege apenas uma faixa menor, o que é correto quando a faixa maior foi um erro. Adicionar uma exceção diz que este destino específico nunca deve ser protegido, o que é correto quando a faixa protegida é realmente ampla e um destino é a exceção.

Escolha a primeira quando puder, porque um seletor menor é mais fácil de raciocinar e aparece na definição da conexão. Escolha a segunda quando a faixa ampla for intencional e a exceção for um único host ou sub-rede que você possa nomear.

Ambas pertencem à configuração que possui a conexão. Uma regra de tempo de execução adicionada à mão desaparece na próxima reconexão, e a falha volta num momento em que ninguém lembra do contorno.

Exceções seguras contra reinstalação

Depois da mudança, repita a mesma requisição inofensiva e olhe os mesmos contadores. O destino local deve responder, e o destino remoto pretendido deve continuar mostrando tráfego criptografado.

Estas duas verificações confirmam que a exceção sobreviveu e que a proteção não:

ip xfrm policy list | grep -c out
ping -c 3 192.168.50.20

Depois desconecte e reconecte o túnel de propósito, e repita as duas. Uma exceção que funciona antes da reconexão e falha depois foi aplicada na camada errada, e é a forma mais comum de este problema voltar.