VPN в Windows поема целия трафик? Премахнете маршрута му по подразбиране

Свързвате се с офис VPN и всяка страница в браузъра започва да минава през тази мрежа: файловият сървър е бърз, всичко останало е бавно, филтрирано или изчезнало. Клиентът не се държи неправилно; профилът е поискал пълен тунел. Превключвателят, който го спира, е една отметка в диалог, който модерното приложение Настройки не показва, и шлюзът отново има думата при всяко свързване. Това ръководство следва реда, който интерфейсът на Windows действително предлага, а след това обхваща проверките, които все още се провалят, след като таблицата с маршрути изглежда правилна.

Започнете от свойствата на адаптера, не от Настройки

Приложението Настройки изброява профила под Мрежа и интернет, после VPN, но показва само общи опции. Решението за шлюза по подразбиране живее на адаптера. Отворете класическия списък с адаптери с Win+R и ncpa.cpl, щракнете с десния бутон върху VPN връзката, изберете Свойства, изберете Интернет протокол версия 4, изберете отново Свойства, после Разширени. Изчистете Използване на шлюз по подразбиране в отдалечената мрежа и потвърдете излизането от трите диалога.

Свържете се отново преди тестване, защото отметката се прилага при установяване на тунела и съществуваща сесия запазва таблицата, която е изградила. Ако адаптерът липсва, докато клиентът е изключен, свържете се веднъж и отворете отново прозореца. Клиент на доставчик, който инсталира TAP или Wintun адаптер без страница със свойства на IPv4, изобщо няма този диалог; за тях същото решение е опция за разделен тунел в собствените настройки на клиента, а отметката на адаптера е грешното място за търсене.

Същата промяна от PowerShell

За профил, създаден в хранилището на Windows VPN, настройката е скриптуема, което е точно това, което искате, ако машината се преинсталира често:

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

Този cmdlet достига само до профили в това хранилище. Връзка, добавена от клиент на трета страна, няма да се появи и командата се проваля с грешка в името, която изглежда като печатна грешка. Обърнете внимание и на това, което превключвателят не прави: той спира клиента да инсталира маршрут по подразбиране, но не премахва маршрутите, които шлюзът изпраща при свързване, така че следващият раздел все още е необходим в много мрежи.

Когато шлюзът изпрати маршрута по подразбиране обратно

Първо прочетете таблицата. Два записа по подразбиране с различни метрики означават, че промяната на профила е проработила и изпратеният маршрут все пак я е заменил:

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

Изтрийте маршрута по подразбиране, който принадлежи на тунела, и запазете физическия. Използвайте индекса на интерфейса от третата команда, а не псевдонима на адаптера, защото скриптовете, които подават псевдоним, се чупят веднага щом показваното име се промени:

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

Изтриването отнася офиса със себе си, затова добавете корпоративните префикси обратно през шлюза на тунела. Това е редът, който хората пропускат, и това е причината „VPN спря да работи“ да следва успешна промяна на разделен тунел:

route add 10.0.0.0 mask 255.0.0.0 10.8.0.1 metric 5 if 21

Нищо от това не оцелява при повторно свързване, което е честно поведение, а не грешка: адаптерът се изгражда наново и клиентът прилага отново това, за което профилът и шлюзът са се споразумели. Ако маршрутът по подразбиране се появява всеки път, шлюзът е конфигуриран да отказва разделен тунел и ще продължи да го изпраща или ще прекъсне сесията. Това е политика на оператора на мрежата и заявката принадлежи там, а не в локален скрипт, който се бори с нея веднъж при всяко свързване.

Проверете отново DNS, IPv6 и метриките след едно повторно свързване

Премахването на маршрут по подразбиране IPv4 не доказва нищо за другото семейство или за разрешаването на имена. Тунелът може да носи IPv6, докато IPv4 маршрутът по подразбиране остава локален, а изпратен списък с резолвери може да поддържа вътрешните имена работещи, докато заявките, които го използват, минават по друг път. Проверете и трите, преди да го обявите за готово:

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

Ако състоянието се връща при всяко свързване, преместете командите в действие при свързване, вместо да редактирате таблицата на ръка: планирана задача, задействана от събитието за връзка, или собствената настройка за разделен тунел на клиента, където има такава. Дръжте индекса на интерфейса в променлива и го търсете по време на изпълнение, защото може да се промени, когато адаптери се добавят или премахват.

Решете от какво се отказахте

Локалният интернет трафик вече не се инспектира или филтрира от офиса и всичко, публикувано само през тунела, сега се нуждае от собствен маршрут. Някои организации смятат разделения тунел за нарушение на политиката, затова потвърдете това, преди да променяте управлявано устройство; изпратеният маршрут по подразбиране понякога е механизъм за налагане, а не случайност. Документацията на Set-VpnConnection изброява параметъра за разделен тунел и типовете профили, за които се прилага.

След това проверете в фиксиран ред: кой притежава маршрута по подразбиране, обикновеното сърфиране, един корпоративен хост по адрес, едно вътрешно име и същите четири след едно повторно свързване. Ако сърфирането работи, а корпоративният хост се проваля, липсва префиксният маршрут, а не премахнатият по подразбиране, и това е много по-евтино за поправяне, отколкото пресъздаването на профила.