Porque a sua tabela de rotas VPN do Windows mostra 0.0.0.0/1 e 128.0.0.0/1

Ligue-se a uma VPN do Windows e abra a tabela de rotas, e duas entradas destacam-se: 0.0.0.0/1 e 128.0.0.0/1. Não são um erro de escrita e não substituem a rota predefinida. A sua presença depende de uma opção de perfil, e o par é a forma como um túnel completo é construído, não uma funcionalidade de túnel dividido. Leia a opção, o prefixo e a interface em conjunto antes de alterar uma única linha.

O que a opção de gateway predefinido instala

A opção de perfil que envia tudo pelo túnel funciona ao acrescentar esses dois prefixos. Retire a opção e eles desaparecem, deixando uma rota que cobre apenas a sub-rede entregue ao adaptador do túnel. A caixa de seleção controla o par; não reescreve a única rota predefinida. Por isso a tabela depois de desmarcar se parece com uma reescrita parcial e não com uma eliminação.

0.0.0.0/1 cobre a metade inferior do espaço IPv4 e 128.0.0.0/1 a metade superior, por isso juntas cobrem todos os endereços unicast. Cada uma é mais específica do que uma rota predefinida 0.0.0.0/0, o que significa que a correspondência do prefixo mais longo envia o tráfego comum para o túnel enquanto a rota física predefinida fica onde estava. Manter essa rota predefinida não é cosmético: os pacotes que envolvem a carga cifrada são endereçados ao endereço público do servidor e têm de sair pelo adaptador físico. Substitua a rota predefinida em vez de a dividir, e o transporte do próprio túnel tentará entrar no túnel, o que é um ciclo e não uma ligação.

Por isso vale a pena parar perante uma 0.0.0.0/0 literal que aponte para o adaptador VPN. O cliente nativo normalmente não escreve tal coisa, pelo que uma rota manual ou a configuração de outro cliente alterou a tabela às escondidas. Encontre-a antes de depurar qualquer coisa mais abaixo.

Desmontar é mais barato do que guardar um gateway

Desmontar é o argumento prático a favor de duas entradas em vez de uma. O cliente possui exatamente duas rotas enquanto está ligado e elimina-as ao desligar, deixando o que o adaptador físico tiver nesse momento. Um cliente que tivesse substituído a única rota predefinida teria de recordar o gateway anterior, e após uma alteração da concessão DHCP poderia restaurar um que já não existe. Duas entradas próprias não transportam esse estado.

Outros clientes chegam ao mesmo desenho. Um perfil OpenVPN com redirect-gateway def1 instala esses dois prefixos em vez de eliminar a rota predefinida, e o cliente Windows segue o padrão pelo mesmo motivo de encaminhamento.

É também por isso que uma tabela pode parecer um túnel completo quando esperava uma divisão. O par é a forma como o túnel completo é construído, não prova de um erro de túnel dividido. Se o perfil estiver definido para usar o gateway remoto, tudo é encaminhado, faça o que fizer uma aplicação local para chegar.

O prefixo mais longo vence antes de qualquer métrica

O comprimento do prefixo decide a consulta antes de qualquer outro campo. A métrica apenas desfaz empates entre rotas com um prefixo idêntico, por isso uma entrada /1 vence uma rota predefinida /0 mesmo quando a métrica é pior. A ligação à interface decide o que resta quando duas rotas partilham um prefixo e o Windows tem de escolher que adaptador envia o pacote.

route print -4
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.50.5.20

Uma tabela de túnel dividido contém a rota física predefinida, as duas meias-rotas, a rota da sub-rede do túnel e qualquer prefixo de escritório que tenha acrescentado. A rota física predefinida pode estar numa métrica mais baixa ou mais alta consoante o cliente e o perfil, e enquanto o par /1 existir essa diferença não muda nada. Muda tudo no momento em que o par é removido, e é então que surge um gateway obsoleto ou uma interface errada. Leia a tabela toda e não a linha que esperava alterar.

Escolha um único proprietário para o prefixo do escritório

Para um túnel dividido, nomeie apenas o prefixo que tem de usar a VPN e escolha uma forma de o possuir. Apontar a rota para o endereço de túnel atribuído funciona até esse endereço mudar, enquanto a ligação à interface sobrevive à mudança de endereço mas quebra quando o índice é reatribuído após a reconstrução do perfil. O cmdlet ligado ao perfil evita ambos os problemas, ao custo de precisar do perfil.

route -p add 10.50.0.0 mask 255.255.0.0 172.16.8.1
route -p add 10.50.0.0 mask 255.255.0.0 0.0.0.0 IF 31
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.50.0.0/16

O cmdlet liga o prefixo ao perfil nomeado, por isso a rota aparece com a ligação e desaparece com ela, que é o que um portátil gerido quer. Uma rota persistente sobrevive a reinícios e sobrevive ao perfil que a motivou, e é assim que uma VPN retirada deixa entradas durante anos. Escolha um método por prefixo e registe a escolha, porque uma rota persistente mais uma rota de perfil para o mesmo prefixo produzem duplicados difíceis de deslindar durante a desmontagem. Escolha o que escolher, a propriedade deve ser visível no ticket e não apenas na máquina.

A propriedade é a pergunta a que esta secção responde, não a sintaxe. Dois proprietários para um prefixo é o modo de falha que vale a pena evitar.

Verifique com um destino, não com um site

Teste o destino que tem de atravessar o túnel, não um site que informe um endereço de saída. Find-NetRoute devolve a rota selecionada e o endereço de origem, por isso vê se ganhou o prefixo do escritório ou a rota física predefinida, e depois abre a partilha em si.

Find-NetRoute -RemoteIPAddress 10.50.5.20
Get-VpnConnection -Name Office

Um site de endereço de saída é uma verificação fraca, porque DNS, IPv6 e um proxy do navegador podem enviar esse pedido por um caminho diferente. IPv4 e IPv6 também têm definições separadas na mesma caixa de diálogo, e desmarcar uma caixa deixa a outra família intacta, por isso uma máquina de pilha dupla pode levar IPv6 pelo túnel enquanto IPv4 segue a rota dividida. Verifique ambas as famílias antes de classificar o perfil como dividido. Se a rota estiver correta e o serviço continuar a falhar, a camada restante é a filtragem e não o encaminhamento.

Uma firewall gerida pelo cliente pode bloquear a sub-rede do escritório com uma tabela de rotas perfeita. Essa política pertence a quem implementou o perfil, não a quem edita rotas.