La VPN de Windows s'ho emporta tot? Traieu la seva ruta per defecte

Us connecteu a la VPN de l'oficina i cada pàgina del navegador comença a passar per aquella xarxa: el servidor de fitxers va ràpid, tota la resta va lenta, filtrada o ha desaparegut. El client no es comporta malament; el perfil ha demanat un túnel complet. L'interruptor que ho atura és una casella en un diàleg que l'aplicació Configuració moderna no mostra, i la passarel·la torna a tenir veu a cada connexió. Aquest recorregut segueix l'ordre que la interfície de Windows presenta realment i després cobreix les comprovacions que encara fallen quan la taula de rutes sembla correcta.

Comenceu a les propietats de l'adaptador, no a Configuració

L'aplicació Configuració llista el perfil a Xarxa i Internet i després a VPN, però només exposa opcions generals. La decisió de la passarel·la predeterminada viu a l'adaptador. Obriu la llista clàssica d'adaptadors amb Win+R i ncpa.cpl, feu clic dret a la connexió VPN, trieu Propietats, seleccioneu Protocol d'Internet versió 4, torneu a triar Propietats i després Avançat. Desmarqueu Utilitza la passarel·la predeterminada a la xarxa remota i confirmeu la sortida dels tres diàlegs.

Torneu-vos a connectar abans de provar, perquè la casella s'aplica quan s'estableix el túnel i una sessió existent conserva la taula que ha construït. Si l'adaptador falta mentre el client està desconnectat, connecteu-vos un cop i torneu a obrir la finestra. Un client de proveïdor que instal·la un adaptador TAP o Wintun sense pàgina de propietats IPv4 no té aquest diàleg; per a aquests, la mateixa decisió és una opció de túnel dividit dins la configuració pròpia del client, i la casella de l'adaptador és el lloc equivocat on buscar.

El mateix canvi des de PowerShell

Per a un perfil creat a la botiga de VPN de Windows, el paràmetre es pot scriptar, que és el que voleu si la màquina es reconstrueix sovint:

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

Aquest cmdlet només arriba als perfils d'aquella botiga. Una connexió afegida per un client de tercers no apareixerà, i l'ordre falla amb un error de nom que sembla una errata. Fixeu-vos també en què no fa l'interruptor: impedeix que el client instal·li una ruta per defecte, però no elimina les rutes que la passarel·la empeny en connectar-se, així que la secció següent encara cal en moltes xarxes.

Quan la passarel·la torna a empenye la ruta per defecte

Llegiu primer la taula. Dues entrades per defecte amb mètriques diferents volen dir que el canvi del perfil ha funcionat i que la ruta empenyuda l'ha substituïda igualment:

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

Suprimiu la ruta per defecte que pertany al túnel i conserveu la física. Feu servir l'índex d'interfície de la tercera ordre, no l'àlies de l'adaptador, perquè els scripts que passen un àlies es trenquen tan bon punt canvia el nom de visualització:

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

La supressió s'endú l'oficina amb ella, així que torneu a afegir els prefixos corporatius a través de la passarel·la del túnel. Aquesta és la línia que la gent salta, i és la raó per la qual «la VPN ha deixat de funcionar» segueix un canvi de túnel dividit correcte:

route add 10.0.0.0 mask 255.0.0.0 10.8.0.1 metric 5 if 21

Res d'això no sobreviu a una reconnexió, que és un comportament honest i no un error: l'adaptador es reconstrueix i el client torna a aplicar el que el perfil i la passarel·la han acordat. Si la ruta per defecte reapareix cada cop, la passarel·la està configurada per refusar el túnel dividit i continuarà empenyent-la, o bé tancarà la sessió. Aquesta és la política de l'operador de la xarxa, i la petició hi pertany, no a un script local que hi lluita un cop per connexió.

Reviseu DNS, IPv6 i les mètriques després d'una reconnexió

Eliminar una ruta per defecte IPv4 no demostra res sobre l'altra família ni sobre la resolució de noms. Un túnel pot portar IPv6 mentre la ruta per defecte IPv4 es queda local, i una llista de resolutors empenyuda pot mantenir els noms interns funcionant mentre les consultes que la fan servir viatgen per un altre camí. Reviseu les tres coses abans de donar-ho per fet:

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

Si l'estat reverteix a cada connexió, moveu les ordres a una acció per connexió en comptes d'editar la taula a mà: una tasca programada activada per l'esdeveniment de connexió, o el paràmetre de túnel dividit del propi client quan en té. Guardeu l'índex d'interfície en una variable i consulteu-lo en temps d'execució, perquè pot canviar quan s'afegeixen o es treuen adaptadors.

Decidiu què heu cedit

El trànsit d'internet local ja no el inspecciona ni el filtra l'oficina, i qualsevol cosa publicada només a través del túnel ara necessita la seva pròpia ruta. Algunes organitzacions consideren el túnel dividit una violació de política, així que confirmeu-ho abans de canviar un dispositiu gestionat; una ruta per defecte empenyuda de vegades és el mecanisme d'aplicació i no un accident. La documentació de Set-VpnConnection llista el paràmetre de túnel dividit i els tipus de perfil als quals s'aplica.

Després verifiqueu en un ordre fix: qui posseeix la ruta per defecte, la navegació ordinària, un amfitrió corporatiu per adreça, un nom intern i els mateixos quatre després d'una sola reconnexió. Si la navegació funciona i l'amfitrió corporatiu falla, falta la ruta de prefix i no la ruta per defecte que heu tret, i això és molt més barat d'arreglar que reconstruir el perfil.