Túnel dividido en Windows: a caixa da pasarela e o prefixo que falta

O túnel informa de que está conectado e a wiki aínda carga. Despois unha descarga atasca e o recurso compartido do estante deixa de responder. O túnel fixo o seu traballo, e o perfil simplemente reclamaba cada destino.

Windows trata unha conexión VPN como unha decisión de encamiñamento. Mentres esa decisión non se estreite, a máquina compórtase como se se tivese mudado á oficina.

Por que un túnel que funciona parece unha caída

Un perfil autorizado a usar a pasarela remota instala unha ruta predeterminada a través do túnel. Entón cada destino que non está na ligazón local sae pola devasa da oficina. Os recursos compartidos locais deixan de responder porque o seu tráfico agora viaxa a outro continente e volve. Nada no estado do cliente o reflicte.

Os síntomas confunden a propósito. A resolución de nomes pode seguir funcionando mentres o recurso compartido esgota o tempo, ou ao revés. O usuario informa de que a VPN está rota, o cliente informa de que está ben, e ambas afirmacións son exactas.

A caixa escondida no diálogo IPv4

O axuste está varios diálogos máis adentro. Abra ncpa.cpl, faga clic dereito na conexión, despois en propiedade de IPv4, despois en Avanzado, e desmarque a opción que permite que a conexión se converta na pasarela predeterminada remota. Esa soa caixa decide se o perfil é un túnel completo. Todo o demais do perfil segue aplicándose.

Compare route print -4 antes e despois de reconectar. A entrada 0.0.0.0 que antes apuntaba ao túnel debería ter desaparecido, e os prefixos corporativos deberían seguir aí.

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

Cambiar a métrica da interface non é un substituto. Unha métrica só decide entre dúas rutas predeterminadas que compiten, e un cliente que reinstala a súa propia ruta predeterminada ao conectar gaña esa competición sexa cal sexa o número configurado.

O prefixo que ninguén listou

O túnel dividido expón exactamente os prefixos rexistrados no perfil. Unha subrede de oficina engadida despois de escribir o perfil queda inalcanzable mentres o túnel está perfectamente san. O informe chega entón como un servidor roto en lugar dunha VPN rota.

Unha ruta engadida a man cobre o oco ata que cambia o enderezo da pasarela. Rexistrar o prefixo na conexión é máis sólido, porque o prefixo segue entón a conexión en lugar dun enderezo adiviñado.

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 a lista gardada e a táboa viva xuntas. Un prefixo gardado pode existir mentres a táboa nunca o recibe, o que ocorre cando un axente de administración filtra rutas despois de que a conexión se ergue. O contrario tamén ocorre, cunha ruta do rexistro apuntando a un adaptador que está caído. Ningunha das dúas vistas por si soa conta toda a historia.

Demostrar o resultado tras un reinicio

Trace en ambos os sentidos e resolva por nome. Un trace público debería saír polo provedor, un trace interno debería entrar no túnel, e un host interno debería responder por nome e non só por enderezo.

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

Repítao tras unha desconexión, unha reconexión e un reinicio. Un prefixo que sobrevive a unha reconexión manual e desaparece tras un reinicio nunca se gardou no perfil.

Teña tamén a impresora e o NAS na proba, porque un túnel dividido que corta os dispositivos xunto ao portátil resolveu un problema creando outro máis pequeno e máis irritante. A referencia de Microsoft sobre Add-VpnConnectionRoute é o lugar onde comprobar a ortografía dos parámetros coa versión do seu módulo.