Por qué una ruta VPN amplia rompe algunos sitios públicos

La mayoría de las páginas cargan, dos o tres agotan el tiempo de espera y el navegador culpa a la conexión. Los sitios que fallan tienen algo en común que los que funcionan no tienen: sus direcciones resueltas caen dentro de un prefijo que instaló la VPN. Una ruta lo bastante amplia para cubrir un rango público capturará tráfico que el túnel nunca debió transportar, y el síntoma parece un problema del sitio web en lugar de una decisión de enrutamiento.

Resuelva el nombre que falla y luego mire la tabla de enrutamiento, no el navegador.

Compare la dirección, no el nombre del sitio

Busque la dirección que el cliente intentó realmente y luego compruebe qué ruta coincide con ella. Un destino dentro de 45.61.20.10 cae bajo 45.0.0.0/8 si ese prefijo está presente, aunque el sitio en sí no tenga nada que ver con el túnel. Comparar la dirección que falla con los prefijos instalados es un problema de resta, no una adivinanza.

Windows puede responder ambas mitades directamente, y una consulta muestra qué interfaz y qué siguiente salto ganaron la selección. Resuelva el nombre dos veces si el sitio devuelve varias direcciones. Anote cada una con la ruta que coincidió. Direcciones distintas pueden producir respuestas distintas, y solo una de ellas puede ser el 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 el prefijo coincidente más específico, no la primera línea que parezca familiar. Una ruta presente en la tabla no demuestra que ganara la consulta; lo hace la coincidencia más larga. Dos prefijos pueden coincidir con una dirección, y solo uno recibe el paquete. El perdedor permanece en la tabla y parece igual de real en un listado.

Anote el prefijo, su interfaz y la dirección resuelta. Esos tres valores son todo el diagnóstico.

Averigüe quién instaló la ruta

Las rutas llegan de cuatro sitios: el perfil VPN nativo, una política de administración, un script de conexión o un cliente completamente distinto. Borrar la entrada activa puede confirmar su relevancia, pero la siguiente conexión la recrea a partir de la configuración guardada, así que lo que debe cambiar es la fuente.

Revise primero la lista de rutas del perfil, luego la política de administración, luego cualquier script que se ejecute al conectar. Ese orden coincide con la frecuencia con la que cada uno resulta ser el responsable. También mantiene el cambio en una capa en lugar de tres.

Lea con cuidado el comportamiento nativo basado en clases

Los perfiles nativos de Windows tienen un ajuste documentado, NativeProfile/DisableClassBasedDefaultRoute, que controla una ruta automática inferida de la dirección de la interfaz. Una dirección de perfil que empiece por 45 puede producir una entrada 45.0.0.0/8 con ese comportamiento, y así una sola dirección pública captura todo un rango de clase A.

El nombre de la propiedad invita a una lectura equivocada: ponerlo en true desactiva la inferencia, y false la activa. Tampoco es el mismo objeto que una ruta predeterminada, y no gobierna a los clientes de terceros que instalan sus propios prefijos.

Si la inferencia es la causa demostrada, corrija el perfil a través de su propietario de administración y proporcione explícitamente los prefijos privados previstos. Si un script añadió la entrada, repare el script. Sustituir una ruta amplia sin explicación por otra cambia el síntoma sin responder a la pregunta.

Repare la fuente y luego vuelva a comprobar ambos caminos

Después del cambio, vuelva a conectarse y repita la consulta para un sitio público que falla y para un recurso que debe usar el túnel. El primero debería resolverse ahora a la interfaz física, y el segundo debería seguir seleccionando la VPN. No se detenga en el primer éxito; una corrección que también rompe el acceso privado ha cambiado una falla por otra.

Revise al mismo tiempo el plan de direcciones del servidor. Un grupo que se solapa con el espacio público causa esta clase de problema una y otra vez. Un rango que el operador eligió a propósito merece otra conversación, no una renumeración automática.

Subir la MTU o vaciar el DNS no corregirá un prefijo que sigue dirigiendo esa dirección al túnel. Compruebe primero la selección y luego el camino.