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 1

Find-NetRoute — пайдалы жартысы. Ол клиент ешқашан жауап бермейтін сұраққа жауап береді: осы мақсат үшін Windows қай интерфейс пен қай бастау мекенжайын нақты пайдаланады? Оны ішкі хост, ашық хост және әдейі ерекшелік деп санайтын нәрсенің барлығы үшін іске қосыңыз. Толық туннель профилі ашық мекенжай үшін туннель интерфейсін көрсетуі керек. Split tunnel профилі әдетте онда физикалық адаптерді көрсетеді, ал ішкі префикстер әлі де VPN-ге шешіледі.

«Ол дұрыс емес бағытқа маршруттайды» деген есептердің көбін екі тұзақ түсіндіреді. Ең нақты префикс әрқашан жеңеді, сондықтан физикалық адаптердегі /24 туннель метрикасы қаншалықты төмен болса да VPN-дегі әдепкі маршруттан басым. Метрика тек бірдей префиксті маршруттар арасындағы теңдікті шешеді. Ал IPv4 пен IPv6 бөлек шешіледі: 0.0.0.0/0 қамтитын профиль IPv6-ны жергілікті байланыста қалдыруы мүмкін, бұл қос стекті сайтты жартылай туннельденген көрсетеді. Туннель дұрыс деп қорытынды жасамас бұрын Get-NetRoute -AddressFamily IPv6 тексеріңіз.

What you seeMost likely causeCheck next
Public traffic leaves the physical adapter while SplitTunneling reads FalseA more specific route on that adapter wins over the tunnel defaultFind-NetRoute for the exact destination, then look for a /24 or host route on the physical interface
Internal name fails, internal IP worksNo NRPT rule for that namespace, or a broader rule matches firstGet-DnsClientNrptPolicy and the namespace order
A dual-stack site opens directly while IPv4 uses the tunnelThe profile covers only the IPv4 default routeThe IPv6 route table on both interfaces
Routes look right but one app still goes directThe app uses its own proxy, or the client keeps a per-app listThe 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 туннельдеу — шығысты оқығанда ашық ұстайтын анықтамам.

Қатысты мақалалар