Как да проверите какво действително насочва VPN в Windows чрез PowerShell

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

Започнете от клиента, после спрете да му вярвате

Клиентът е правилното място за начало само защото казва кой профил е активен. Отворете свойствата на връзката и запишете точното име на профила, дали е създаден за текущия потребител или за всички на машината, и кой адаптер се появява в ncpa.cpl след свързване. На моя тестов ноутбук адаптерът носеше името на профила, което правеше изхода от маршрути лесен за четене. На други машини се показва като запис WAN Miniport и името не ви казва нищо.

Това, което клиентът не може да ви каже, е покритието. Свързаната плочка описва състоянието на тунела, а не инвентар на дестинациите. Клиентите на трети страни също пазят собствена конфигурация, така че родният профил на Windows и всяко свойство, което ще прочетете от него, може да няма нищо общо с това, което този клиент е инсталирал. Ако VPN е дошъл през AnyConnect, OpenVPN GUI, WireGuard или агент на доставчик, проверките с PowerShell по-долу най-често не важат и вместо това трябва да прочетете собствените настройки за разделен тунел и маршрутизация на този клиент.

Четете запазения профил, а не плочката

За родния профил на Windows (IKEv2, L2TP, SSTP или такъв, избутан от MDM) запазеното решение за разделен тунел е едно свойство:

Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffix

Добавете -AllUserConnection, когато профилът е създаден за всички на устройството. Без него четете списъка на текущия потребител, който може да е празен или да съдържа друг запис с подобно име. Стойност False в SplitTunneling означава, че профилът е запазен като пълен тунел: Windows инсталира маршрут по подразбиране през VPN адаптера. True означава разделен тунел и тогава покритието зависи изцяло от маршрутите и правилата за разрешаване на имена, които профилът избутва.

Отнасяйте се към тази стойност като конфигурация, не като наблюдение. Тя записва какво профилът е поискал при свързването. Windows може да остане с различни приложени маршрути — заради по-конкретен маршрут на друг интерфейс, настройка на политика или остатъчен запис от предишна връзка, — затова булевата стойност никога не решава въпроса сама.

Сравнете запазената стойност с приложената таблица на маршрутите

След свързването изброете маршрутите на тунелния адаптер, вместо да превъртате цялата таблица:

$vpn = Get-NetAdapter | Where-Object InterfaceDescription -match 'VPN|WAN Miniport'
Get-NetRoute -InterfaceIndex $vpn.ifIndex | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.20.4.15 | Select-Object -First 1

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

Два капана обясняват повечето доклади от типа «маршрутизира накриво». Най-конкретният префикс винаги печели, така че /24 на физическия адаптер бие маршрут по подразбиране на VPN, колкото и ниска да е метриката на тунела. Метриката само решава равенство между маршрути за един и същ префикс. А IPv4 и IPv6 се решават поотделно: профил, който покрива 0.0.0.0/0, може да остави IPv6 на локалната връзка, което кара сайт с два стека да изглежда наполовина тунелиран. Проверете Get-NetRoute -AddressFamily IPv6, преди да заключите, че тунелът е наред.

Проверете разрешаването на имена отделно с NRPT

Вътрешни имена, които се провалят, докато вътрешните IP адреси работят, сочат към политика на резолвера, не към маршрутизация. Windows решава DNS за всяко пространство от имена чрез таблицата на политиката за разрешаване на имена, която е независима от таблицата на маршрутите:

Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndex

Когато правило съвпадне с *.corp.example, заявките за това пространство от имена отиват към DNS сърверите на тунела, дори когато пътят на данните към тези сървери остава на физическия адаптер в режим на разделен тунел. Това е замисълът и затова браузерен тест, който отваря публичен сайт, не ви казва нищо за вътрешните имена. Ако адаптерът изброява очакваните сървери, но търсенията все още отиват другаде, сравнете реда на правилата на NRPT и проверете дали по-конкретно пространство от имена не съвпада първо.

Проверете потоците, после решете какво всъщност сте поискали

Минете през дестинациите в фиксиран ред, така че резултатите да са сравними между машините: публичен адрес, вътрешен адрес, вътрешно име и едно умишлено изключение, например локален принтер или видеовръзка. Запишете интерфейса и изходния адрес, които Find-NetRoute връща за всяко. След всяка промяна на политиката се свържете отново и повторете същите четири проверки; таблицата на маршрутите след повторното свързване е единственото доказателство, че новият профил е в сила.

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

Преди да промените нещо, минете през този списък. Всеки провален пункт стеснява къде е истинският проблем.

• Името и обхватът на профила потвърдени, с -AllUserConnection за профили за цялата машина.
• SplitTunneling прочетено и третирано като конфигурация, а не като доказателство за покритие.
• Маршрутите на тунелния адаптер изброени отделно за IPv4 и IPv6.
• Find-NetRoute стартирано за една публична, една вътрешна и една изключена дестинация.
• Правилата на NRPT проверени, преди да обвинявате маршрутите за провал на име.
• Изискването за блокиране прочетено отново: предпочитаната маршрутизация не е същото като наложеното блокиране.

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