Por qué su tabla de rutas VPN de Windows muestra 0.0.0.0/1 y 128.0.0.0/1

Conéctese a una VPN de Windows y abra la tabla de rutas, y dos entradas destacan: 0.0.0.0/1 y 128.0.0.0/1. No son un error tipográfico y no sustituyen a la ruta predeterminada. Que aparezcan depende de una opción del perfil, y el par es la forma en que se construye un túnel completo, no una función de túnel dividido. Lea la opción, el prefijo y la interfaz juntos antes de cambiar una sola línea.

Qué instala la opción de puerta de enlace predeterminada

La opción del perfil que lo envía todo por el túnel funciona añadiendo esos dos prefijos. Quite la opción y desaparecen, dejando una ruta que solo cubre la subred entregada al adaptador del túnel. La casilla controla el par; no reescribe la única ruta predeterminada. Por eso la tabla tras desmarcar parece una reescritura parcial en lugar de un borrado.

0.0.0.0/1 cubre la mitad inferior del espacio IPv4 y 128.0.0.0/1 la mitad superior, así que juntas cubren todas las direcciones unicast. Cada una es más específica que una ruta predeterminada 0.0.0.0/0, lo que significa que la coincidencia del prefijo más largo envía el tráfico ordinario al túnel mientras la ruta física predeterminada se queda donde estaba. Conservar esa ruta predeterminada no es cosmético: los paquetes que envuelven la carga cifrada van dirigidos a la dirección pública del servidor y tienen que salir por el adaptador físico. Sustituya la ruta predeterminada en lugar de dividirla, y el transporte del propio túnel intentará entrar en el túnel, lo que es un bucle y no una conexión.

Por eso merece la pena detenerse ante una 0.0.0.0/0 literal que apunte al adaptador VPN. El cliente nativo normalmente no la escribe, así que una ruta manual o la configuración de otro cliente ha cambiado la tabla a sus espaldas. Encuéntrela antes de depurar cualquier cosa más abajo.

Desmontar es más barato que guardar una puerta de enlace

Desmontar es el argumento práctico a favor de dos entradas en lugar de una. El cliente posee exactamente dos rutas mientras está conectado y las elimina al desconectar, dejando lo que el adaptador físico tenga en ese momento. Un cliente que hubiera sustituido la única ruta predeterminada tendría que recordar la puerta de enlace anterior, y tras un cambio de concesión DHCP podría restaurar una que ya no existe. Dos entradas propias no llevan ese estado.

Otros clientes llegan al mismo diseño. Un perfil de OpenVPN con redirect-gateway def1 instala esos dos prefijos en lugar de borrar la ruta predeterminada, y el cliente de Windows sigue el patrón por el mismo motivo de enrutamiento.

También es por eso que una tabla puede parecer un túnel completo cuando esperaba una división. El par es la forma en que se construye el túnel completo, no una prueba de un error de túnel dividido. Si el perfil está configurado para usar la puerta de enlace remota, todo se enruta, haga lo que haga una aplicación local por llegar.

El prefijo más largo gana antes que cualquier métrica

La longitud del prefijo decide la consulta antes que cualquier otro campo. La métrica solo desempata entre rutas con un prefijo idéntico, así que una entrada /1 gana a una ruta predeterminada /0 incluso cuando su métrica es peor. La vinculación a la interfaz decide qué queda cuando dos rutas comparten prefijo y Windows tiene que elegir qué adaptador envía el paquete.

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

Una tabla de túnel dividido contiene la ruta física predeterminada, las dos medias rutas, la ruta de la subred del túnel y cualquier prefijo de oficina que haya añadido. La ruta física predeterminada puede estar en una métrica más baja o más alta según el cliente y el perfil, y mientras exista el par /1 esa diferencia no cambia nada. Lo cambia todo en el momento en que se quita el par, que es cuando aparece una puerta de enlace obsoleta o una interfaz equivocada. Lea toda la tabla y no la línea que esperaba cambiar.

Elija un solo propietario para el prefijo de la oficina

Para un túnel dividido, nombre solo el prefijo que tiene que usar la VPN y elija una forma de poseerlo. Apuntar la ruta a la dirección de túnel asignada funciona hasta que esa dirección cambia, mientras que vincularla a la interfaz sobrevive al cambio de dirección pero se rompe cuando el índice se reasigna tras reconstruir el perfil. El cmdlet vinculado al perfil evita ambos problemas, a costa de necesitar el 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

El cmdlet vincula el prefijo al perfil nombrado, así que la ruta aparece con la conexión y se va con ella, que es lo que quiere un portátil gestionado. Una ruta persistente sobrevive a los reinicios y sobrevive al perfil que la motivó, y así es como una VPN retirada deja entradas durante años. Elija un método por prefijo y anote la elección, porque una ruta persistente más una ruta de perfil para el mismo prefijo producen duplicados que son dolorosos de desenredar durante el desmontaje. Elija lo que elija, la propiedad debería ser visible en el ticket y no solo en la máquina.

La propiedad es la pregunta que responde esta sección, no la sintaxis. Dos propietarios para un prefijo es el modo de fallo que vale la pena evitar.

Verifique con un destino, no con un sitio web

Pruebe el destino que tiene que cruzar el túnel, no un sitio web que informe de una dirección de salida. Find-NetRoute devuelve la ruta seleccionada y la dirección de origen, así que puede ver si ganó el prefijo de la oficina o la ruta física predeterminada, y luego abre el recurso compartido en sí.

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

Un sitio de dirección de salida es una comprobación débil, porque DNS, IPv6 y un proxy del navegador pueden enviar esa petición por un camino distinto. IPv4 e IPv6 también tienen ajustes separados en el mismo diálogo, y desmarcar una casilla deja intacta la otra familia, así que una máquina de doble pila puede llevar IPv6 por el túnel mientras IPv4 sigue la ruta dividida. Compruebe ambas familias antes de calificar el perfil de dividido. Si la ruta es correcta y el servicio sigue fallando, la capa restante es el filtrado y no el enrutamiento.

Un cortafuegos gestionado por el cliente puede bloquear la subred de la oficina con una tabla de rutas perfecta. Esa política pertenece a quien desplegó el perfil, no a quien edita rutas.