Rota VPN ou regra de firewall: qual está descartando o pacote?

Duas decisões independentes acontecem com o mesmo pacote, e qualquer uma delas pode encerrar a requisição em silêncio. A consulta de rota escolhe uma interface e um próximo salto, depois o filtro de pacotes decide se essa combinação é permitida. Um tempo limite diz que uma das duas recusou, não qual. Percorra as etapas em ordem e o reparo normalmente deixa de ser um palpite.

Duas decisões, um pacote, dois donos

A consulta de rota consulta primeiro as regras de política, depois a tabela para a qual apontam, e escolhe o prefixo mais específico que corresponde ao destino. Um cliente que instalou uma rota de túnel é dono dessa decisão, e nada em uma regra de firewall pode substituí-la. Quando a consulta aponta para um lugar inesperado, cada etapa seguinte trabalha no pacote errado.

A filtragem é separada. Em um host Linux, os ganchos do netfilter dividem o tráfego conforme para quem é o pacote: a saída deixa a máquina, a entrada termina nela, o encaminhamento a atravessa. Um gateway que aceita clientes VPN e os encaminha para uma LAN precisa do caminho de encaminhamento, e é exatamente a cadeia que a maioria das configurações padrão deixa vazia.

A seleção de origem pertence à mesma decisão, e é aí que a maioria das incompatibilidades se esconde. O kernel escolhe um endereço de origem da interface de saída, a menos que a rota indique um, então uma regra de filtro escrita para a sub-rede LAN nunca corresponde a um pacote que sai com o endereço do túnel.

Leia o que a consulta realmente escolheu

Imprima a decisão em vez de inferi-la. O comando abaixo resolve a rota que o kernel usaria para esse destino, incluindo a interface e a origem que escolheria:

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

Clientes VPN costumam instalar regras de política em prioridades abaixo da tabela principal, então uma tabela principal limpa não prova nada por si só. Compare as prioridades das regras com as tabelas que elas selecionam, e verifique se a rota do túnel sobrevive a uma reconexão em vez de ser adicionada à mão uma vez.

O IPsec baseado em política acrescenta um terceiro estágio de correspondência que o roteamento não cobre, como descrevem as notas de encaminhamento do strongSwan para configurações de túnel e transporte. A política de segurança seleciona o tráfego por prefixo e protocolo, enquanto a rota apenas decide para onde iria um pacote desprotegido. Uma sub-rede roteada mas sem seletor correspondente ou fica desprotegida ou é descartada, conforme a configuração, e nenhum dos resultados parece um problema de firewall. Imprima a política e compare seus seletores com os prefixos que você esperava que o túnel carregasse.

A filtragem se aplica em um gancho, não em uma rota

Uma regra que permite o ouvinte VPN é uma regra sobre tráfego endereçado ao próprio gateway. Ela não diz nada sobre clientes que alcançam hosts atrás desse gateway, porque o tráfego encaminhado atravessa uma cadeia diferente. Ler o conjunto de regras como uma lista plana é a razão usual para uma regra de aparência correta nunca disparar.

Os contadores resolvem a questão rapidamente. Uma regra com contagem de pacotes zero nunca foi alcançada, o que aponta para a cadeia errada, a interface errada ou um descarte anterior. Uma regra com contagem crescente sob uma política de descarte é o limite que você procurava, e o pacote está sendo descartado em vez de roteado errado.

Envie uma sonda pelo caminho que o cliente usa

Testes executados no próprio gateway passam pela saída e pela entrada, com o endereço de origem do próprio gateway. Esse é um caminho diferente da requisição encaminhada de um cliente, então um curl local bem-sucedido prova menos do que parece. Teste a partir da máquina que falha, ou fixe explicitamente a interface e a origem.

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

Uma captura nas duas pontas separa os casos restantes. Um SYN que sai do cliente e nunca chega significa roteamento, criptografia ou uma lista de acesso a montante. Um SYN que chega e não obtém resposta significa o serviço ou seu filtro de host, e o túnel nunca foi o problema.

O tráfego de retorno merece uma olhada própria. Roteamento assimétrico mais filtragem de caminho reverso descartam respostas que chegam na interface errada, o que aparece como conexão unidirecional em vez de porta bloqueada. Verifique o valor de sysctl antes de culpar o firewall por um sintoma que ele não causou.

O registro funciona como segunda opinião, não como primeiro passo. Uma declaração de log temporária na cadeia de encaminhamento nomeia a interface e os endereços que a atingiram, e é fácil de remover depois. Deixe-a permanentemente e você terá construído um problema de volume de logs em vez de uma resposta.

Coloque cada mudança onde ela sobrevive a uma reconexão

Uma rota adicionada com ip route add vive até a interface cair. Guarde-a no perfil de conexão: o NetworkManager aceita rotas extras na conexão, e o netplan as mantém entre inicializações. A mesma regra vale para uma exceção de firewall do lado do cliente, que desaparece após o próximo recarregamento.

As regras do lado do servidor pertencem ao arquivo de configuração que o serviço carrega na inicialização, não a uma sessão interativa que termina quando você a fecha. Escreva a regra, recarregue e confirme que o contador se moveu, porque um recarregamento que rejeitou a sintaxe deixa o conjunto de regras antigo no lugar em silêncio.

Depois repita a requisição original da aplicação do início ao fim e registre qual camada mudou. Uma correção de rota que também precisava de uma mudança de filtro ainda vai falhar, e a segunda falha é muito mais fácil de ler quando você sabe que a primeira sumiu. Anote a data e a versão do cliente ao lado do resultado, pois os padrões de roteamento e filtragem se movem entre versões. Mantenha essa nota no ticket para que a próxima pessoa comece onde você parou em vez de repetir a caminhada de duas etapas.