O que o roteamento por políticas muda no tráfego VPN, e o que não muda

O roteamento por políticas responde a uma pergunta diferente da que a maioria das notas de solução de problemas faz. A tabela principal diz para onde vai um destino; as regras de política dizem qual tabela é consultada afinal, e podem decidir isso a partir do endereço de origem, de uma marca de pacote, ou da interface por onde um pacote chegou. Quando um túnel se comporta de forma inconsistente, o conjunto de regras costuma ser a causa e a tabela de roteamento costuma não ser.

As regras escolhem a tabela e depois a tabela escolhe a rota

Cada regra carrega uma prioridade, uma condição de correspondência e uma tabela de destino. O kernel percorre as regras em ordem de prioridade e para na primeira correspondência, depois faz uma busca comum pelo prefixo mais longo naquela tabela. Uma regra que aponta para uma tabela vazia cai para o que a regra seguinte selecionar, e é assim que uma regra escrita com cuidado pode parecer não fazer nada.

Por isso despejar a tabela principal raramente explica um cliente VPN que funciona. Os clientes costumam inserir regras com números de prioridade baixos, muito antes da regra padrão da tabela principal, então o pacote nunca chega à rota que você estava encarando. Baixar uma métrica na tabela principal não muda nada para o tráfego que já foi desviado.

Uma regra também pode transformar de propósito um prefixo em buraco negro ou torná-lo inalcançável. Alguns clientes adicionam essa regra como interruptor de segurança, e então a queda parece um túnel quebrado em vez de um configurado.

Leia o conjunto de regras como uma sequência, não como uma lista

Imprima as regras com suas prioridades e as tabelas a que se referem, e depois imprima cada tabela que carregue uma rota padrão ou uma rota de túnel. A ordem é a parte que importa, e é a parte que uma captura de tela costuma omitir:

ip rule show
ip route show table all | sed -n '1,60p'
ip route get 198.51.100.20 from 10.8.0.2
ip route get 198.51.100.20 from 10.8.0.2 mark 0x1

Os dois últimos comandos são os que transformam uma teoria em observação, porque perguntam o que o kernel faria para aquela origem e aquela marca. Se a resposta muda quando a marca muda, há uma regra baseada na marca em jogo e qualquer teste que omita a marca está testando um pacote diferente. A conexão externa merece uma regra própria. Um túnel que roteia todo o tráfego por si mesmo deve excluir o endereço de endpoint a que se conecta, senão os pacotes cifrados são enviados de volta ao túnel que acabaram de deixar. A maioria dos clientes insere essa exclusão automaticamente, e um conjunto de regras editado à mão é onde ela desaparece.

Marcas e sockets: duas formas como os clientes dividem o tráfego

Alguns clientes marcam pacotes no firewall e adicionam uma regra que corresponde à marca. Outros usam roteamento no nível do socket, colocando uma rota no socket antes que ele se conecte. O primeiro é visível em ip rule; o segundo não, e não aparecerá numa busca genérica.

Se um programa de teste se comporta de forma diferente da aplicação que deveria representar, verifique se a aplicação coloca uma marca ou se liga a um dispositivo. Essa diferença não é mistério depois que o mecanismo é nomeado, e explica por que um curl de um shell e uma aba do navegador podem tomar caminhos diferentes na mesma máquina. As duas técnicas são roteamento por políticas no sentido amplo: escolhem um caminho com algo diferente do destino. Nenhuma das duas autoriza o tráfego, e nenhuma substitui as regras do firewall ou as credenciais que o par espera.

Rastreie a propriedade antes de adicionar outra regra

As regras são instaladas por alguma coisa. Um cliente VPN, um gerenciador de rede e um script escrito à mão podem cada um adicionar regras na inicialização, e a lógica de reconexão pode deixar o conjunto anterior para trás. Duas regras obsoletas de um perfil anterior continuarão a orientar o tráfego muito depois de o perfil ter sido excluído.

Descubra qual processo é dono da regra pela prioridade e pela forma, e verifique se esse dono reescreve o conjunto a cada conexão. Se reescreve, uma regra manual adicionada hoje desaparece amanhã, e a correção pertence à configuração do cliente e não a um arquivo de histórico do shell. Limpar todo o conjunto de regras para testar é um atalho tentador com um custo previsível: também remove as regras de que o cliente precisa para manter o próprio túnel a funcionar. Apague uma regra de cada vez, ou teste numa máquina que possa reiniciar.

Prove o alcance com dois fluxos, não com um

Uma correção só se verifica com um fluxo que deveria ser afetado e um fluxo que não deveria. Escolha um destino que a política encaminhe para o túnel, e um que deva ficar de fora, e depois compare as buscas e as capturas de ambos:

ip route get 198.51.100.20 from 192.0.2.44
ip route get 198.51.100.21 from 192.0.2.44
tcpdump -ni any host 198.51.100.21 and port 443

Quando as duas buscas devolvem interfaces diferentes, a regra está fazendo algo. Quando devolvem a mesma interface, a regra corresponde mais amplamente do que se pretendia, e essa é a falha que envia em silêncio uma sub-rede inteira por um túnel pensado para uma única aplicação.

Anote as prioridades das regras e o serviço proprietário no ticket, junto com os dois endereços de teste. A pessoa seguinte fica então com um par reproduzível em vez de uma descrição de sintoma, e pode dizer em um minuto se o roteamento por políticas ainda está em jogo.