Por que unha ruta VPN ampla rompe algúns sitios públicos

A maioría das páxinas cargan, dúas ou tres esgotan o tempo de espera e o navegador culpa a conexión. Os sitios que fallan teñen algo en común que os que funcionan non teñen: as súas direccións resoltas caen dentro dun prefixo que instalou a VPN. Unha ruta o bastante ampla para cubrir un rango público capturará tráfico que o túnel nunca debía transportar, e o síntoma parece un problema do sitio web en lugar dunha decisión de enrutamento.

Resolva o nome que falla e logo mire a táboa de enrutamento, non o navegador.

Compare a dirección, non o nome do sitio

Busque a dirección que o cliente intentou realmente e logo comprobe que ruta coincide con ela. Un destino dentro de 45.61.20.10 cae baixo 45.0.0.0/8 se ese prefixo está presente, aínda que o sitio en si non teña nada que ver co túnel. Comparar a dirección que falla cos prefixos instalados é un problema de resta, non unha adiviña.

Windows pode responder ambas as metades directamente, e unha consulta mostra que interface e que seguinte salto gañaron a selección. Resolva o nome dúas veces se o sitio devolve varias direccións. Anote cada unha coa ruta que coincidiu. Direccións distintas poden producir respostas distintas, e só unha delas pode ser o caso que falla.

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

Lea o prefixo coincidente máis específico, non a primeira liña que pareza familiar. Unha ruta presente na táboa non demostra que gañase a consulta; faino a coincidencia máis longa. Dous prefixos poden coincidir cunha dirección, e só un recibe o paquete. O perdedor permanece na táboa e parece igual de real nunha listaxe.

Anote o prefixo, a súa interface e a dirección resolta. Eses tres valores son todo o diagnóstico.

Descubra quen instalou a ruta

As rutas chegan de catro sitios: o perfil VPN nativo, unha política de administración, un script de conexión ou un cliente completamente distinto. Borrar a entrada activa pode confirmar a súa relevancia, pero a seguinte conexión vólvea crear a partir da configuración gardada, así que o que debe cambiar é a fonte.

Revise primeiro a lista de rutas do perfil, logo a política de administración, logo calquera script que se execute ao conectar. Ese orde coincide coa frecuencia coa que cada un resulta ser o responsable. Tamén mantén o cambio nunha capa en lugar de tres.

Lea con coidado o comportamento nativo baseado en clases

Os perfís nativos de Windows teñen un axuste documentado, NativeProfile/DisableClassBasedDefaultRoute, que controla unha ruta automática inferida da dirección da interface. Unha dirección de perfil que comece por 45 pode producir unha entrada 45.0.0.0/8 con ese comportamento, e así unha soa dirección pública captura todo un rango de clase A.

O nome da propiedade invita a unha lectura equivocada: poñelo en true desactiva a inferencia, e false actívaa. Tampouco é o mesmo obxecto que unha ruta predeterminada, e non goberna os clientes de terceiros que instalan os seus propios prefixos.

Se a inferencia é a causa demostrada, corrixa o perfil a través do seu propietario de administración e proporcione explicitamente os prefixos privados previstos. Se un script engadiu a entrada, repare o script. Substituír unha ruta ampla sen explicación por outra cambia o síntoma sen responder á pregunta.

Repare a fonte e logo volva comprobar ambos os camiños

Despois do cambio, volva conectar e repita a consulta para un sitio público que falla e para un recurso que debe usar o túnel. O primeiro debería resolverse agora á interface física, e o segundo debería seguir seleccionando a VPN. Non se deteña no primeiro éxito; unha corrección que tamén rompe o acceso privado cambiou un fallo por outro.

Revise ao mesmo tempo o plan de direccións do servidor. Un grupo que se solapa co espazo público causa esta clase de problema unha e outra vez. Un rango que o operador escolleu a propósito merece outra conversación, non unha renumeración automática.

Subir a MTU ou baleirar o DNS non corrixirá un prefixo que segue dirixindo esa dirección ao túnel. Comprobe primeiro a selección e logo o camiño.