Како да проверите што VPN на Windows навистина рутира во PowerShell

Поврзав VPN клиент на преносен сметач со Windows 11, плочката премина во Connected, се отвори внатрешно споделување на датотеки, а јавниот сајт сѐ уште се вчитуваше директно од канцеларискиот Wi-Fi. Оваа смеса изгледа како раскинат тунел. Тоа е нормален излез на профил што дел од сообраќајот го праќа преку VPN, а остатокот го остава на физичкиот адаптер. Присилното тунелирање менува која стандардна рута Windows ја претпочита; не брише поспецифични рути и не ветува дека сообраќајот ќе запре кога врската ќе падне. Следи редоследот по кој работам кога клиент тврди покриеност: состојба на клиентот, зачуван профил, применети рути, резолвер, потоа вистински текови.

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

Клиентот е вистинското место за почеток само затоа што ви кажува кој профил е активен. Отворете ги својствата на врската и запишете го точното име на профилот, дали е создаден за тековниот корисник или за сите на сметачот, и кој адаптер се појавува во ncpa.cpl по поврзувањето. На мојот тест преносен сметач адаптерот го носеше името на профилот, што го олесни читањето на излезот од рутите. На други сметачи се појавува како запис WAN Miniport и името не ви кажува ништо.

Она што клиентот не може да ви го каже е покриеноста. Поврзана плочка го опишува состојбата на тунелот, а не попис на дестинации. Клиентите од трети страни исто така ја чуваат сопствената конфигурација, па матичниот Windows профил и секое својство што ќе го прочитате од него може да немаат никаква врска со она што го инсталирал тој клиент. Ако VPN дојде преку AnyConnect, OpenVPN GUI, WireGuard или агент на добавувач, проверките со PowerShell подолу главно не важат и наместо тоа треба да ги читате сопствените поставки за split-tunnel и рутирање на тој клиент.

Читајте го зачуваниот профил, не плочката

За матичен Windows профил (IKEv2, L2TP, SSTP или оној што го турка MDM) зачуваната одлука за split-tunnel е едно својство:

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

Додајте -AllUserConnection кога профилот е создаден за сите на уредот. Без тоа ја читате листата на тековниот корисник, која може да е празна или да содржи друг запис со слично име. Вредноста False во SplitTunneling значи дека профилот е зачуван како целосен тунел: Windows инсталира стандардна рута низ VPN адаптерот. True значи split tunnel, и покриеноста тогаш целосно зависи од рутите и правилата за разрешување имиња што ги турка тој профил.

Третирајте ја таа вредност како конфигурација, не како набљудување. Таа запишува што побарал профилот при поврзувањето. 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 навистина ќе ги користи? Извршете го за внатрешен домаќин, јавен домаќин и сѐ што сметате за намерен исклучок. Профилот со целосен тунел треба да го покаже тунелскиот интерфејс за јавната адреса. Профилот со split tunnel обично го покажува физичкиот адаптер таму, додека внатрешните префикси сѐ уште се разрешуваат кон 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 серверите на тунелот, дури и кога патеката на податоци до тие сервери во режим на split tunnel останува на физичкиот адаптер. Таква е замислата и затоа тест во прелистувач што отвора јавен сајт не ви кажува ништо за внатрешните имиња. Ако адаптерот ги наведува очекуваните сервери, но пребарувањата сѐ уште одат на друго место, споредете го редоследот на правилата на NRPT и проверете дали не се совпаѓа прво поспецифичен именичен простор.

Проверете ги тековите, па одлучете што всушност баравте

Поминете низ дестинациите по фиксен редослед за да бидат резултатите споредливи меѓу сметачи: јавна адреса, внатрешна адреса, внатрешно име и еден намерен исклучок како локален печатач или видео повик. Запишете ги интерфејсот и изворната адреса што Find-NetRoute ги враќа за секоја. По секоја промена на политика, поврзете се повторно и повторете ги истите четири проверки; табелата со рути по повторното поврзување е единствениот доказ дека новиот профил стапил на сила.

Потоа одделете го рутирањето од спроведувањето. Присилното тунелирање го претпочита тунелот за опфатениот сообраќај додека е подигнат. Тоа не е kill switch. Ако барањето е ништо да не ја напушта машината кога тунелот паѓа, тоа мора да дојде од блокирачка замисла: профил на ѕид за заштита врзан со состојбата на тунелот, профил постојано вклучен со филтри за сообраќај или сопствената опција за затворање при неуспех на клиентот на добавувачот. Присилното тунелирање исто така мора да ја остави сопствената адреса на VPN серверот достапна надвор од тунелот, а нејзиното блокирање во името на «наметнување на сѐ» е сигурен начин да се заклучите од врската што се обидувате да ја спроведете.

Пред да промените нешто, поминете го овој список. Секоја ставка што не успева го стеснува каде е вистинскиот проблем.

• Името и опсегот на профилот се потврдени, со -AllUserConnection за профили на ниво на сметач.
• SplitTunneling е прочитано и третирано како конфигурација, а не како доказ за покриеност.
• Рутите на тунелскиот адаптер се наведени одделно за IPv4 и IPv6.
• Find-NetRoute е извршено за една јавна, една внатрешна и една исклучочна дестинација.
• Правилата на NRPT се проверени пред да се обвинат рутите за неуспех на име.
• Барањето за блокирање е прочитано повторно: преферираното рутирање не е исто како спроведеното блокирање.

Одлуката за целосен или split тунел му припаѓа на оној што го поседува профилот, а белешките на Microsoft за рутирање го опишуваат однесувањето што Windows го спроведува кога профил ќе го постави. Microsoft: присилно и split тунелирање е референцата што ја држам отворена додека го читам излезот.