Túnel dividido en Windows: la casilla de puerta de enlace y el prefijo que falta

El túnel informa de que está conectado y la wiki todavía carga. Luego una descarga se atasca y el recurso compartido de la estantería deja de responder. El túnel hizo su trabajo, y el perfil simplemente reclamaba cada destino.

Windows trata una conexión VPN como una decisión de enrutamiento. Mientras esa decisión no se estreche, la máquina se comporta como si se hubiera mudado a la oficina.

Por qué un túnel que funciona parece una caída

Un perfil autorizado a usar la puerta de enlace remota instala una ruta predeterminada a través del túnel. Entonces cada destino que no está en el enlace local sale por el cortafuegos de la oficina. Los recursos compartidos locales dejan de responder porque su tráfico ahora viaja a otro continente y vuelve. Nada en el estado del cliente lo refleja.

Los síntomas confunden a propósito. La resolución de nombres puede seguir funcionando mientras el recurso compartido agota el tiempo, o al revés. El usuario informa de que la VPN está rota, el cliente informa de que está bien, y ambas afirmaciones son exactas.

La casilla escondida en el diálogo IPv4

El ajuste está varios diálogos más adentro. Abra ncpa.cpl, haga clic derecho en la conexión, luego en propiedades de IPv4, luego en Avanzado, y desmarque la opción que permite que la conexión se convierta en la puerta de enlace predeterminada remota. Esa sola casilla decide si el perfil es un túnel completo. Todo lo demás del perfil sigue aplicándose.

Compare route print -4 antes y después de reconectar. La entrada 0.0.0.0 que antes apuntaba al túnel debería haber desaparecido, y los prefijos corporativos deberían seguir ahí.

route print -4 | findstr /c:"0.0.0.0"
Get-VpnConnection -Name 'Work VPN' | Select-Object Name, SplitTunneling, Routes

Cambiar la métrica de la interfaz no es un sustituto. Una métrica solo decide entre dos rutas predeterminadas que compiten, y un cliente que reinstala su propia ruta predeterminada al conectar gana esa contienda sea cual sea el número configurado.

El prefijo que nadie listó

El túnel dividido expone exactamente los prefijos registrados en el perfil. Una subred de oficina añadida después de escribir el perfil queda inalcanzable mientras el túnel está perfectamente sano. El informe llega entonces como un servidor roto en lugar de una VPN rota.

Una ruta añadida a mano cubre el hueco hasta que cambia la dirección de la puerta de enlace. Registrar el prefijo en la conexión es más sólido, porque el prefijo sigue entonces a la conexión en lugar de a una dirección adivinada.

route -p add 172.20.8.0 mask 255.255.255.0 10.8.0.1
Add-VpnConnectionRoute -ConnectionName 'Work VPN' -DestinationPrefix 172.20.8.0/24
Get-VpnConnection -Name 'Work VPN' | Select-Object -ExpandProperty Routes

Lea la lista guardada y la tabla viva juntas. Un prefijo guardado puede existir mientras la tabla nunca lo recibe, lo que ocurre cuando un agente de administración filtra rutas después de que la conexión se levanta. Lo contrario también ocurre, con una ruta del registro apuntando a un adaptador que está caído. Ninguna de las dos vistas por sí sola cuenta toda la historia.

Demostrar el resultado tras un reinicio

Trace en ambos sentidos y resuelva por nombre. Un trazado público debería salir por el proveedor, un trazado interno debería entrar en el túnel, y un host interno debería responder por nombre y no solo por dirección.

tracert -4 www.example.com
tracert -4 wiki.corp.example
ping -4 fileserver.corp.example
ping -4 172.20.8.20

Repítalo tras una desconexión, una reconexión y un reinicio. Un prefijo que sobrevive a una reconexión manual y desaparece tras un reinicio nunca se guardó en el perfil.

Tenga también la impresora y el NAS en la prueba, porque un túnel dividido que corta los dispositivos junto al portátil ha resuelto un problema creando otro más pequeño y más irritante. La referencia de Microsoft sobre Add-VpnConnectionRoute es el lugar donde comprobar la ortografía de los parámetros con la versión de su módulo.