Um aplicativo vinculado ao endereço da VPN ainda usa a rota errada

Um aplicativo se vincula ao endereço da VPN, e a conexão ainda sai pela rota padrão comum. Nada falhou no bind; ele fez exatamente o que um bind faz. Vincular um socket a um endereço local escolhe o endereço de origem que o kernel coloca no cabeçalho. Isso não instala uma rota e não cria uma regra de política que envie os pacotes com essa origem para um túnel específico.

O restante deste manual é a ordem de verificação que uso, junto com o comando que produz cada observação.

O que um bind realmente decide

Um bind atribui um endereço local ao socket. Depois o kernel executa a mesma consulta de rota que teria executado de outra forma, a menos que uma regra de política mude qual tabela essa consulta lê.

Por isso um pacote pode sair com um endereço de origem da VPN em uma interface física. Do outro lado ele chega de um intervalo privado que a rede nunca esperou naquele caminho, o tráfego de retorno não tem rota de volta, e a conexão trava ou é reiniciada.

A referência de sockets IP do Linux documenta a semântica do bind. A metade de roteamento vive em ip-rule e ip-route, e são páginas de manual separadas por um motivo.

Confirme que o endereço pertence a este namespace

Um endereço ao qual você pode se vincular precisa existir em uma interface dentro do namespace de rede onde o aplicativo roda. Um endereço de par, um endereço de gateway ou um endereço que só existe em outro namespace não pode ser vinculado, e a chamada falha com EADDRNOTAVAIL.

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

Execute esses três no mesmo contexto do aplicativo: mesmo namespace e mesmo usuário, se conseguir obtê-lo. Um diagrama net30 antigo não é prova de qual endereço sua topologia atual atribuiu ao cliente. Leia a interface que está realmente ativa.

Leia a consulta para essa origem e esse destino

Um único comando responde à pergunta que o bind não respondeu:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

A primeira linha imprime a rota que um pacote dessa origem até esse destino seguiria, incluindo a interface de saída e a origem preferida. Se ela nomear a interface física, o bind e a rota discordam, e o pacote sairá com uma origem para a qual o caminho não consegue voltar.

Depois o ip rule show diz se alguma regra teria escolhido outra tabela. As prioridades importam aqui, porque ganha a primeira regra correspondente e uma regra que captura tudo acima da sua torna a sua invisível.

Instale uma regra de política apenas se esse for o desenho

O roteamento baseado na origem é um desenho deliberado, não um reparo para um aplicativo. Se o dono da política quer que o tráfego da sub-rede do túnel use o túnel, a regra pertence à configuração dele e não a um comando pontual no seu laptop.

Uma forma viável é uma tabela dedicada com uma rota padrão pelo túnel, mais uma regra que envie o intervalo de origem da VPN para essa tabela. Adicione as exceções de que o desenho precisa, porque uma tabela contendo apenas um padrão de túnel vai capturar destinos que devem permanecer locais ou acessíveis pelo caminho físico.

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

Desfaça com ip rule del e ip route flush table 100. Tudo o que é adicionado assim desaparece na reinicialização, a menos que um gerenciador o escreva, o que é ao mesmo tempo uma propriedade de segurança e um motivo para não guardar a única cópia no histórico do seu shell.

Verifique com três observações

Registre a origem que o aplicativo pediu, a rota que a consulta escolheu e a origem que o servidor realmente viu.

Esses três podem discordar, e cada discordância aponta para um lugar diferente. Uma captura na interface do túnel prova que o pacote saiu com a origem correta. Uma captura na interface física prova que ele saiu pelo caminho errado. A visão do lado do servidor é a única que prova o caminho de ponta a ponta.

Se o aplicativo oferece uma opção de vinculação a um dispositivo ou um modo de roteamento por aplicativo, trate-a como um mecanismo diferente com restrições diferentes. Configurações de aparência semelhante não terminam todas na mesma decisão do kernel.