Aplicação vinculada a uma interface? O caminho VPN dela não é o padrão

Uma aplicação na máquina sai pela VPN e outra não, e os dois usuários juram que não mudaram nada. A diferença costuma ser uma decisão de vínculo tomada pela própria aplicação: um socket preso a um dispositivo, um endereço de origem escolhido antes da conexão ou um namespace com a própria tabela de roteamento. Cada uma muda qual caminho se aplica, e nenhuma aparece numa verificação genérica de IP no navegador.

Três vínculos diferentes, três efeitos diferentes

Vincular-se a um dispositivo e vincular-se a um endereço de origem são operações relacionadas com consequências diferentes. Um vínculo a dispositivo pode forçar o tráfego a sair por uma interface e ignorar a busca normal de rota daquele socket. O vínculo a um endereço de origem ainda passa pela seleção de rota, mas a origem escolhida pode corresponder a uma regra de política e enviar o pacote para outro lugar. A distinção soa acadêmica até uma regra rotear por origem. Então ela decide tudo.

O namespace de rede é o terceiro caso. Tem as suas próprias interfaces e a sua própria tabela de roteamento, então uma aplicação lá dentro não sofre nada com o padrão do host. Tratar os três como a mesma coisa produz explicações confiantes que não passam no primeiro teste.

Determine o que a aplicação realmente define

Leia a configuração de rede da aplicação ou o comportamento documentado antes de mexer nas rotas. Se ela expõe uma escolha de interface, um campo de endereço de origem ou uma opção de namespace, essa configuração é a primeira coisa a inspecionar. Caso contrário, o vínculo pode ser interno e visível apenas por rastreamento ou pelos próprios diagnósticos.

No Linux, opções de socket como SO_BINDTODEVICE têm âmbito e requisitos de permissão documentados, e um processo sem privilégios pode nem conseguir defini-las. Essa restrição é uma pista útil: se a opção não pode ser aplicada, a aplicação provavelmente não é a origem da diferença.

O roteamento por política lê a origem

Quando há roteamento por política configurado, uma regra pode escolher uma tabela com base na origem do pacote. Por isso um socket que vincula um endereço de origem pode seguir uma regra que o caminho padrão nunca toca, mesmo que nenhuma interface seja nomeada explicitamente.

Reproduza a busca com a mesma família de endereços, origem e namespace que a aplicação usa. Uma busca genérica de rota a partir de um shell no namespace do host responde a outra pergunta, e essa discrepância é o motivo mais comum de uma rota que funciona parecer quebrada.

Túnel dividido e processos auxiliares

O túnel dividido por aplicação acrescenta outra camada. O cliente pode corresponder ao pacote ou ao processo da aplicação, e um auxiliar que abre o próprio socket é um sujeito separado. Um lançador e o seu serviço em segundo plano podem produzir conexões diferentes sob o mesmo nome visível.

Verifique se a regra de túnel dividido cobre o processo que realmente se conecta. Se a aplicação se vincula a uma interface específica e o cliente VPN corresponde por pacote, as duas decisões podem divergir sem que nenhuma esteja errada.

Teste o caminho próprio da aplicação

Execute um novo pedido a partir da aplicação depois de cada alteração. Um navegador a mostrar a saída que você queria não é prova equivalente para outro programa vinculado a outra interface, e conexões em cache podem continuar a usar o caminho antigo muito depois de uma configuração mudar. Feche a sessão antiga antes de julgar a nova regra. Senão o teste mede o passado.

A referência de sockets do Linux documenta SO_BINDTODEVICE e os seus requisitos. Leia primeiro a configuração da própria aplicação, reproduza a busca no mesmo contexto e só depois decida se é preciso mudar a rota ou o vínculo.