Como enviar apenas uma sub-rede privada pela VPN

Uma sub-rede privada pelo túnel e todo o resto pelo seu caminho habitual é um pedido pequeno com muitas formas de dar errado. O que decide o resultado não é a caixa chamada split tunneling, mas onde a decisão é aplicada: na própria tabela de rotas do cliente, numa rota empurrada pelo servidor ou numa política negociada pelas duas pontas. Escolha a camada errada e você terá ou um túnel completo que nunca quis, ou uma rota para um túnel que o outro lado se recusa a aceitar. Eu uso um teste de três condições antes de abrir qualquer configuração e depois escolho um dos mecanismos abaixo.

Três condições que definem o desenho

Primeiro, você precisa do prefixo e da máscara exatos do dono da rede. A rede 10.x não é um prefixo; 10.20.0.0/16 é. Confirme que ela não se sobrepõe à sua LAN doméstica, a uma ponte do Docker ou a outra VPN que você execute, porque uma sobreposição torna a rota ambígua e o kernel escolhe a entrada que você não pretendia.

Segundo, quem responde ao tráfego de volta. Encaminhar um pacote para o túnel só o leva ao servidor VPN. Se a sub-rede fica atrás de outro roteador que não tem rota de volta para o seu conjunto de clientes, o servidor precisa mascarar o tráfego, ou esse roteador precisa aprender o seu conjunto. Nenhuma rota no lado do cliente corrige um caminho de volta que falta.

Terceiro, o ponto de aplicação. Alguns clientes instalam uma rota e o sistema operacional faz o resto. Outros negociam uma política, e uma política que o gateway não aceita não produz túnel algum: os pacotes são descartados sem erro evidente. Descubra qual dos dois é o seu caso antes de escrever qualquer coisa.

WireGuard: AllowedIPs é a tabela de rotas

No cliente, AllowedIPs lista os destinos que podem entrar no túnel, e wg-quick transforma cada entrada numa rota comum. Então a metade cliente desta tarefa é uma única linha.

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

Agora compare a entrada do servidor para o mesmo cliente. Ela descreve o que o servidor enviará ao cliente, que normalmente é o endereço de túnel do cliente, e não a sub-rede privada.

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

Trocar essas duas é o erro que vejo com mais frequência. Colocar 10.20.0.0/16 na seção peer do servidor declara que a sub-rede inteira fica atrás daquele cliente, e isso é uma pretensão de site para site, não uma permissão. Pacotes que não casam com o AllowedIPs de nenhum peer são descartados em silêncio, então uma entrada errada parece exatamente um problema de firewall.

Se você mesmo gerencia as rotas, defina Table = off sob [Interface] e adicione a rota que quiser. Aí nada é adicionado automaticamente, portanto a rota pertence àquilo que levanta a interface.

OpenVPN: empurre a rota e depois garanta que ela chega

Num servidor normal a mudança é uma diretiva na configuração do servidor, ao lado do conjunto de clientes.

push "route 10.20.0.0 255.255.0.0"

O cliente a adiciona quando se conecta. O modo de falha aparece quando o mesmo perfil também empurra redirect-gateway, ou quando alguém já adicionou route-nopull: o primeiro transforma a sessão num túnel completo, e o segundo descarta todas as rotas empurradas, inclusive a sua.

Um cliente que precisa de comportamento estreito diante de um servidor de túnel completo deve ignorar apenas as partes de que não quer. No OpenVPN 2.4 e posteriores, pull-filter existe exatamente para isso.

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

Mantenha as famílias de endereços separadas: uma rota IPv4 empurrada não faz nada por um serviço interno que resolve em IPv6, e esse serviço falha pelo túnel enquanto todo o resto parece certo.

Quando a sub-rede privada não está no servidor VPN mas atrás de outro cliente, é preciso avisar o servidor. Adicione um arquivo por cliente via client-config-dir contendo iroute 10.20.0.0 255.255.0.0, mais a route correspondente para que os outros clientes aprendam o caminho. Sem iroute o servidor não tem motivo para enviar esse prefixo justamente por aquele túnel.

IPsec: os seletores de tráfego precisam concordar

Com IPsec não há rota a empurrar. As duas pontas negociam quais endereços vivem dentro do túnel, e o tráfego fora dos seletores acordados não é cifrado nem enviado por ele. Num cliente strongSwan os seletores são explícitos.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Se o gateway está configurado com 0.0.0.0/0 dos dois lados, o estreitamento do IKEv2 costuma reduzir a SA filha à interseção das duas propostas, que é o resultado desejado. Alguns gateways, porém, rejeitam uma proposta que não corresponde aos seus seletores configurados, e o log então mostra uma SA filha falhada em vez de uma queixa de roteamento. Quando isso acontece, a mudança pertence ao gateway, porque uma rota no cliente não pode criar um túnel para um seletor que o outro lado não aceitará.

No Windows o cliente embutido esconde a mesma decisão atrás de dois ajustes. A divisão do túnel precisa estar ligada, e o prefixo precisa ser registrado no perfil.

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

É o registro do prefixo que faz ele sobreviver a uma reconexão, o que uma rota adicionada à mão não faz.

Mantenha o endpoint e o DNS fora da decisão

O endpoint da VPN precisa continuar alcançável sem o túnel, senão o túnel desaba sobre si mesmo. Quando só 10.20.0.0/16 é roteado isso é automático, já que o endpoint é um endereço público. Num perfil de túnel completo não é, e o cliente precisa de uma rota de host explícita até o endpoint antes de o túnel subir.

DNS é uma segunda decisão que o empurrão de rota não toma por você. Nomes internos costumam resolver por um resolvedor que só a rede privada alcança. Se o servidor empurra um servidor DNS, todo nome passa por ele; se não empurra, os nomes internos ou falham ou resolvem publicamente para algo que você não pretendia. O DNS dividido mantém um domínio de busca no resolvedor interno, mas isso depende do suporte do cliente, então trate como tarefa própria e não como efeito colateral do roteamento.

Verifique, reinicie e verifique de novo

Três sondagens cobrem a questão do roteamento. Pergunte ao kernel para onde iria um endereço remoto, busque algo de dentro da sub-rede e depois confirme que um pedido público comum ainda sai pela sua conexão normal.

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

A primeira linha nomeia uma interface. Se nomear a sua interface física, a rota nunca entrou. No Windows, Find-NetRoute -RemoteIPAddress 10.20.5.7 responde à mesma pergunta, e a última sondagem ainda deve mostrar o seu endereço habitual e não o do servidor VPN.

Depois reinicie. Rotas adicionadas à mão desaparecem, enquanto rotas do perfil, de uma configuração empurrada ou de AllowedIPs voltam. Se o acesso estreito funciona antes do reinício e falha depois, a culpa está em como o túnel inicia, não na rota em si.

Antes de considerar terminado, confirme quatro coisas: o prefixo veio do dono da rede e não se sobrepõe a nada local, o caminho de volta existe ou uma regra de mascaramento o substitui, o mecanismo que você configurou é o que aplica o roteamento na sua plataforma, e as mesmas sondagens passam depois de um reinício limpo. As notas de encaminhamento do strongSwan valem a leitura se o caminho de volta é a parte que não para de falhar.