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 туннель нь гаралтыг уншиж байхдаа нээлттэй байлгадаг лавлагаа юм.