Como enviar um destino IPv4 para fora de um túnel OpenVPN

A maioria das configurações de túnel completo envia cada pacote pela VPN, e a diretiva redirect-gateway é o que torna isso possível. Um único destino ainda pode ser excetuado. Adicionar uma rota de host para esse endereço com o marcador net_gateway diz ao cliente para alcançá-lo pela gateway original da máquina, enquanto todo o resto continua a usar o túnel.

A linha parece inofensiva e muitas vezes é, mas resolve apenas uma questão: para onde vão os pacotes desse endereço IPv4 exato. Não altera o DNS, o IPv6, a política da firewall nem qual processo abriu a ligação, e cada um deles pode anular a exceção silenciosamente.

O que net_gateway realmente nomeia

A entrada de perfil para essa exceção é uma linha: route 198.51.100.77 255.255.255.255 net_gateway. O primeiro endereço é um marcador de documentação para o destino, a máscara torna-o numa rota de um único host, e o último token nomeia o marcador da gateway. OpenVPN resolve os marcadores de gateway quando instala rotas. vpn_gateway significa a gateway do próprio túnel, o lado remoto da ligação VPN. net_gateway significa a gateway predefinida que o host tinha antes de a VPN alterar algo, que normalmente é o router local na rede física.

Um terceiro marcador, remote_host, refere-se ao endereço do servidor VPN, e existe para que o túnel possa alcançar o servidor pelo caminho físico. Confundir estes três é a razão mais comum para uma exceção ir para o lugar errado ou não ser instalada de todo.

O valor é lido no momento da ligação, não é escrito no ficheiro. Se a máquina passar para outra rede, a gateway anterior à VPN muda e a rota segue a nova. Isso é normalmente o que pretende, mas também significa que o comportamento da exceção depende da rede de onde o cliente arrancou.

Porque uma rota de host vence a rota predefinida do túnel

O encaminhamento é decidido pelo prefixo correspondente mais específico. redirect-gateway def1 normalmente não substitui a rota predefinida; acrescenta duas metades, uma rota para a metade inferior do espaço de endereços e outra para a metade superior, para que a rota predefinida original fique preservada para outros usos. Essas metades são mais amplas do que um único endereço.

Uma rota para um endereço com máscara 255.255.255.255 é uma /32, que é o máximo de especificidade que o IPv4 permite. Quando um pacote para esse endereço é avaliado, a /32 corresponde e vence, independentemente de qual rota foi instalada primeiro. Esse é o mecanismo por trás da exceção, e funciona da mesma forma no Linux, macOS e Windows desde que a rota esteja realmente presente.

O Windows acrescenta uma segunda dimensão. Quando duas rotas são igualmente específicas, vence a de métrica mais baixa, e um adaptador VPN pode transportar uma métrica de interface que altera o resultado. Uma /32 continua a ser mais específica do que as metades, por isso a exceção normalmente mantém-se, mas uma rota obsoleta de uma sessão anterior pode produzir um resultado confuso se for igualmente específica.

O que a exceção não cobre

O DNS é a primeira falha. O cliente pode empurrar definições internas do resolver, e o sistema operativo continuará a usá-las para consultas. Uma aplicação que resolve um nome antes de ligar pode receber um endereço interno para um serviço que deveria ir direto, ou um endereço externo que resolve corretamente mas depois tropeça na falha seguinte.

O IPv6 é a segunda. A diretiva de rota só trata de IPv4. Um destino de dupla pilha pode preferir IPv6, que segue o túnel ou a rota predefinida IPv6 do host conforme a política, por isso a exceção IPv4 nunca entra em jogo. Precisa de uma rota IPv6 correspondente, ou de uma decisão deliberada de desativar o IPv6 para esse cliente.

O âmbito das aplicações é a terceira. A regra baseia-se no destino, por isso cada processo que se liga a esse endereço usa o caminho direto, seja ou não o que tinha em mente. Inversamente, um site pode responder a partir de vários endereços, por isso excetuar uma /32 não excetua o site. Se o requisito real for o encaminhamento por aplicação, a tabela de rotas do cliente Community é a ferramenta errada.

Verificar a exceção sem se enganar

Comece pela rota instalada, não pelo navegador. No Linux, pergunte ao kernel qual a rota e o próximo salto que usará para o endereço concreto; no Windows, leia a tabela de rotas para essa /32. Confirme que a gateway é a física e não o túnel. Se a entrada faltar, o perfil não foi aplicado ou o cliente não tinha o privilégio de alterar rotas.

Depois teste dois destinos. Um pedido ao endereço excetuado deve sair pela interface física, e um pedido a um endereço interno de controlo deve continuar a usar o túnel. Testar apenas o endereço excetuado não prova nada sobre o resto do túnel, e testar um site público testa o endereço para o qual esse site resolveu, que pode não ser o da regra.

Por fim, verifique os controlos que podem sobrepor-se à rota. Um kill switch do lado do cliente ou uma definição block-outside-dns do Windows pode proibir o tráfego direto, o que se manifesta como uma ligação que falha apesar de a rota estar correta. Não desative esses controlos para fazer a exceção parecer funcionar; se a política proíbe o caminho direto, a exceção é um problema de conceção para o proprietário do serviço VPN.

Verifique novamente após reconectar ou mudar de rede, porque a gateway anterior à VPN e o caminho disponível são propriedades do momento, não do perfil.