Windows'до VPN чындап эмнени маршруттай турганын PowerShell аркылуу кантип текшерүү керек
Туташкан VPN плиткасы камтууну далилдебейт. Сакталган профиль желегин, учурдагы маршруттар таблицасын жана NRPT эрежелерин ушул тартипте окуңуз.
Мен Windows 11 ноутбугунда VPN кардарын туташтырдым, плитка 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 эмес. Эгер талап туннель кулаганда машинеден эч нерсе чыкпашы болсо, ал бөгөттөөчү долбоордон келиши керек: туннелдин абалына байланган firewall профили, трафик чыпкалары бар дайыма күйүк профиль же жеткирүүчү кардардын өзүнүн ийгиликсиздикте жабылуу опциясы. Мажбурлап туннелдөө ошондой эле VPN серверинин өз дарегин туннелдин сыртында жеткиликтүү калтырууга тийиш, ал эми аны «баарын мажбурлоо» аты менен бөгөттөө — аткармак болгон туташуудан өзүңүздү кулпулоонун ишенимдүү жолу.
Бир нерсени өзгөртүүдөн мурун бул тизмени карап чыгыңыз. Ийгиликсиз ар бир пункт чыныгы маселе кайда экенин тарытта.
- Профилдин аты жана көлөмү ырасталды,
-AllUserConnectionмашине боюнча профилдер үчүн колдонулду. SplitTunnelingокулуп, камтуунун далили эмес, конфигурация катары каралды.- Туннель адаптеринин маршруттары IPv4 жана IPv6 үчүн өзүнчө тизмеленди.
Find-NetRouteбир ачык, бир ички жана бир өзгөчөлүк бута үчүн иштетилди.- NRPT эрежелери маршруттарды ат ийгиликсиздигинде айыптоодон мурун текшерилди.
- Бөгөттөө талабы кайра окулду: артык көрүлгөн маршруттоо аткарылган бөгөттөө менен бирдей эмес.
Толук же split туннель чечими профилдин ээсине таандык, ал эми Microsoft'тун маршруттоо эскертүүлөрү профиль аны орноткондо Windows кандай жүрүм-турумду ишке ашырарын сүрөттөйт. Microsoft: мажбурлап жана split туннелдөө — чыгышты окуганда ачык кармаган шилтеме.