Како проверити шта VPN у Windows-у заиста рутира у PowerShell-у
Повезана VPN плочица не доказује покривеност. Прочитајте сачувану заставицу профила, живу табелу рута и NRPT правила у овом редоследу.
Повезао сам 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 1Find-NetRoute је корисна половина. Одговара на питање на које клијент никада не одговара: за ово одредиште, који интерфејс и која изворна адреса ће Windows заиста користити? Покрените га за интерни домаћин, јавни домаћин и све што сматрате намерним изузетком. Профил пуног тунела требало би да прикаже тунелски интерфејс за јавну адресу. Профил split tunnel-а обично тамо приказује физички адаптер, док се интерни префикси и даље разрешавају ка VPN-у.
Две замке објашњавају већину извештаја „рутира у погрешном смеру“. Најспецифичнији префикс увек побеђује, па /24 на физичком адаптеру побеђује подразумевану руту на VPN-у колико год ниска метрика тунела била. Метрика само решава нерешено између рута за исти префикс. А IPv4 и IPv6 се решавају одвојено: профил који покрива 0.0.0.0/0 може да остави IPv6 на локалној вези, због чега двоструко-стековни сајт изгледа пола тунелиран. Проверите Get-NetRoute -AddressFamily IPv6 пре него што закључите да је тунел у реду.
| What you see | Most likely cause | Check next |
|---|---|---|
| Public traffic leaves the physical adapter while SplitTunneling reads False | A more specific route on that adapter wins over the tunnel default | Find-NetRoute for the exact destination, then look for a /24 or host route on the physical interface |
| Internal name fails, internal IP works | No NRPT rule for that namespace, or a broader rule matches first | Get-DnsClientNrptPolicy and the namespace order |
| A dual-stack site opens directly while IPv4 uses the tunnel | The profile covers only the IPv4 default route | The IPv6 route table on both interfaces |
| Routes look right but one app still goes direct | The app uses its own proxy, or the client keeps a per-app list | The app's proxy settings and the client's application list |
Проверите разрешавање имена одвојено помоћу 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 тунеловање је референца коју држим отворену док читам излаз.