A VPN de Windows leva todo o tráfico? Elimine a súa ruta predeterminada

Conéctase á VPN da oficina e cada páxina do navegador comeza a pasar por esa rede: o servidor de ficheiros vai rápido, todo o demais vai lento, filtrado ou desapareceu. O cliente non se comporta mal; o perfil pediu un túnel completo. O interruptor que o detén é unha caixa nun diálogo que a aplicación Configuración moderna non mostra, e a pasarela volve ter voz en cada conexión. Este percorrido segue a orde que a interface de Windows presenta realmente e despois cobre as comprobacións que seguen fallando cando a táboa de rutas parece correcta.

Comece nas propiedades do adaptador, non en Configuración

A aplicación Configuración lista o perfil en Rede e Internet e despois en VPN, pero só expón opcións xerais. A decisión da pasarela predeterminada vive no adaptador. Abra a lista clásica de adaptadores con Win+R e ncpa.cpl, faga clic dereito na conexión VPN, elixa Propiedades, seleccione Protocolo de Internet versión 4, elixa Propiedades outra vez e despois Avanzado. Desmarque Usar a pasarela predeterminada na rede remota e confirme a saída dos tres diálogos.

Vólvase conectar antes de probar, porque a caixa aplícase cando se establece o túnel e unha sesión existente conserva a táboa que construíu. Se o adaptador falta mentres o cliente está desconectado, concéctese unha vez e volva abrir a xanela. Un cliente de provedor que instala un adaptador TAP ou Wintun sen páxina de propiedades IPv4 non ten este diálogo en absoluto; para eses, a mesma decisión é unha opción de túnel dividido dentro dos axustes propios do cliente, e a caixa do adaptador é o lugar equivocado onde buscar.

O mesmo cambio desde PowerShell

Para un perfil creado na tenda de VPN de Windows, o axuste é scriptable, que é o que quere se a máquina se reconstrúe a miúdo:

Set-VpnConnection -Name "Office" -SplitTunneling $true
Get-VpnConnection -Name "Office" | Select-Object Name,SplitTunneling

Ese cmdlet só alcanza os perfís desa tenda. Unha conexión engadida por un cliente de terceiros non aparecerá, e o comando falla cun erro de nome que parece unha errata. Fíxese tamén no que o interruptor non fai: impide que o cliente instale unha ruta predeterminada, pero non elimina as rutas que a pasarela empurra ao conectar, así que a seguinte sección segue a ser necesaria en moitas redes.

Cando a pasarela volve empurrar a predeterminada

Lea primeiro a táboa. Dúas entradas predeterminadas con métricas distintas significan que o cambio do perfil funcionou e que a ruta empurrada a substituíu de todos os xeitos:

route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-NetAdapter | Select-Object Name,ifIndex

Elimine a ruta predeterminada que pertence ao túnel e conserve a física. Use o índice de interface do terceiro comando, non o alias do adaptador, porque os scripts que pasan un alias rompen en canto cambia o nome visible:

Remove-NetRoute -DestinationPrefix 0.0.0.0/0 -InterfaceIndex 21 -Confirm:$false
route delete 0.0.0.0 10.8.0.1

A eliminación leva a oficina consigo, así que volva engadir os prefixos corporativos a través da pasarela do túnel. Esta é a liña que a xente salta, e é a razón pola que «a VPN deixou de funcionar» segue a un cambio de túnel dividido correcto:

route add 10.0.0.0 mask 255.0.0.0 10.8.0.1 metric 5 if 21

Nada disto sobrevive a unha reconexión, o cal é un comportamento honesto e non un erro: o adaptador reconstrúese e o cliente volve aplicar o que acordaron o perfil e a pasarela. Se a predeterminada reaparece cada vez, a pasarela está configurada para rexeitar o túnel dividido e seguirá empurrándoa, ou pechará a sesión. Esa é a política do operador da rede, e a petición pertence alí e non a un script local que loita contra ela unha vez por conexión.

Revise DNS, IPv6 e as métricas tras unha reconexión

Eliminar unha ruta predeterminada IPv4 non demostra nada sobre a outra familia nin sobre a resolución de nomes. Un túnel pode levar IPv6 mentres a predeterminada IPv4 queda local, e unha lista de resolutores empurrada pode manter os nomes internos funcionando mentres as consultas que a usan viaxan por outro camiño. Revise as tres antes de darlo por feito:

Get-NetRoute -DestinationPrefix ::/0
Get-DnsClientServerAddress -InterfaceAlias "Office"
Get-DnsClientNrptPolicy

Se o estado volve en cada conexión, mova os comandos a unha acción por conexión en lugar de editar a táboa a man: unha tarefa programada activada polo evento de conexión, ou o axuste de túnel dividido do propio cliente cando o ten. Manteña o índice de interface nunha variable e consúlteo en tempo de execución, xa que pode cambiar cando se engaden ou quitan adaptadores.

Decida a que renunciou

O tráfico de Internet local xa non o inspecciona nin o filtra a oficina, e todo o que se publica só a través do túnel agora necesita a súa propia ruta. Algunhas organizacións consideran o túnel dividido unha violación da política, así que confírmelo antes de cambiar un dispositivo xestionado; unha predeterminada empurrada ás veces é o mecanismo de aplicación e non un accidente. A documentación de Set-VpnConnection enumera o parámetro de túnel dividido e os tipos de perfil aos que se aplica.

Despois verifique nunha orde fixa: quen posúe a ruta predeterminada, a navegación normal, un host corporativo por enderezo, un nome interno e os mesmos catro tras unha soa reconexión. Se a navegación funciona e o host corporativo falla, falta a ruta de prefixo e non a predeterminada que quitou, e iso é moito máis barato de arranxar que reconstruír o perfil.