Por que uma rota VPN ampla quebra alguns sites públicos

A maioria das páginas carrega, duas ou três expiram, e o navegador culpa a conexão. Os sites que falham têm algo em comum que os que funcionam não têm: seus endereços resolvidos caem dentro de um prefixo instalado pela VPN. Uma rota ampla o bastante para cobrir um intervalo público capturará tráfego que o túnel nunca deveria transportar, e o sintoma parece um problema do site em vez de uma decisão de roteamento.

Resolva o nome que falha e depois olhe a tabela de roteamento, não o navegador.

Compare o endereço, não o nome do site

Procure o endereço que o cliente realmente tentou e verifique qual rota corresponde a ele. Um destino dentro de 45.61.20.10 cai sob 45.0.0.0/8 se esse prefixo estiver presente, mesmo que o site em si não tenha nada a ver com o túnel. Comparar o endereço que falha com os prefixos instalados é um problema de subtração, não um chute.

O Windows pode responder às duas metades diretamente, e uma consulta mostra qual interface e qual próximo salto venceram a seleção. Resolva o nome duas vezes se o site devolver vários endereços. Anote cada um com a rota que correspondeu. Endereços diferentes podem produzir respostas diferentes, e apenas um deles pode ser o caso que falha.

Resolve-DnsName www.example.org
Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,InterfaceIndex,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 45.61.20.10
Get-VpnConnection | Format-List Name,SplitTunneling,Routes

Leia o prefixo correspondente mais específico, não a primeira linha que parecer familiar. Uma rota presente na tabela não prova que venceu a consulta; a correspondência mais longa é que decide. Dois prefixos podem corresponder a um endereço, e apenas um recebe o pacote. O perdedor permanece na tabela e parece igualmente real em uma listagem.

Anote o prefixo, sua interface e o endereço resolvido. Esses três valores são todo o diagnóstico.

Descubra quem instalou a rota

As rotas vêm de quatro lugares: o perfil VPN nativo, uma política de gerenciamento, um script de conexão ou um cliente completamente diferente. Excluir a entrada ativa pode confirmar sua relevância, mas a próxima conexão a recria a partir da configuração salva, então a fonte é o que deve mudar.

Verifique primeiro a lista de rotas do perfil, depois a política de gerenciamento, depois qualquer script executado ao conectar. Essa ordem corresponde à frequência com que cada um se mostra responsável. Ela também mantém a mudança em uma camada em vez de três.

Leia com atenção o comportamento nativo baseado em classes

Os perfis nativos do Windows têm uma configuração documentada, NativeProfile/DisableClassBasedDefaultRoute, que controla uma rota automática inferida do endereço da interface. Um endereço de perfil que comece com 45 pode produzir uma entrada 45.0.0.0/8 sob esse comportamento, e é assim que um único endereço público captura todo um intervalo de classe A.

O nome da propriedade convida a uma leitura errada: defini-la como true desativa a inferência, e false a ativa. Também não é o mesmo objeto que uma rota padrão, e não governa clientes de terceiros que instalam seus próprios prefixos.

Se a inferência é a causa demonstrada, corrija o perfil por meio do proprietário de gerenciamento e forneça explicitamente os prefixos privados previstos. Se um script adicionou a entrada, repare o script. Substituir uma rota ampla sem explicação por outra muda o sintoma sem responder à pergunta.

Repare a fonte e depois verifique novamente os dois caminhos

Após a mudança, reconecte e repita a consulta para um site público que falha e para um recurso que deve usar o túnel. O primeiro agora deve resolver para a interface física, e o segundo deve continuar selecionando a VPN. Não pare no primeiro sucesso; uma correção que também quebra o acesso privado trocou uma falha por outra.

Revise ao mesmo tempo o plano de endereços do servidor. Um pool que se sobrepõe ao espaço público causa esse tipo de problema repetidamente. Um intervalo escolhido de propósito pelo operador merece outra conversa, não uma renumeração automática.

Aumentar a MTU ou limpar o DNS não corrigirá um prefixo que ainda direciona esse endereço para o túnel. Teste primeiro a seleção e depois o caminho.