Як праверыць, што насамрэч маршрутызуе VPN у Windows праз PowerShell
Падключаная плітка VPN не даказвае пакрыццё. Чытайце захаваны сцяг профілю, жывую табліцу маршрутаў і правілы NRPT у гэтым парадку.
Я падключыў кліент VPN на ноўтбуку з Windows 11, плітка перайшла ў стан «Падключана», унутраная сумесная папка адкрылася, а публічны сайт усё яшчэ загружаўся напрамкі з офіснага 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 для кожнага. Пасля любой змены палітыкі перападключыцеся і паўтарыце тыя ж чатыры праверкі; табліца маршрутаў пасля перападключэння — адзіны доказ, што новы профіль уступіў у сілу.
Затым аддзяліце маршрутызацыю ад прымусу. Прымусовае тунеляванне аддае перавагу тунелю для пакрытага трафіку, пакуль ён падняты. Яно не з'яўляецца выключальнікам бяспекі. Калі патрабаванне ў тым, каб нішто не пакідала машыну пры падзенні тунелю, гэта мусіць ісці з блакуючага дызайну: профіль міжсеткавага экрана, прывязаны да стану тунелю, профіль пастаяннага падключэння з фільтрамі трафіку або ўласная опцыя закрыцця пры збоі ў кліенце пастаўшчыка. Прымусовае тунеляванне таксама павінна пакідаць уласны адрас сервера VPN дасяжным па-за тунелем, і блакаванне яго дзеля «прымусу ўсяго» — надзейны спосаб замкнуць сябе ад злучэння, якое вы спрабуеце ўмацаваць.
Перш чым нешта змяніць, прайдзіцеся па гэтым спісе. Кожны правальны пункт звужвае, дзе сапраўдная праблема.
- Імя профілю і ахоп пацверджаны, для машынных профіляў выкарыстаны
-AllUserConnection. SplitTunnelingпрачытаны і ўспрыняты як канфігурацыя, а не доказ пакрыцця.- Маршруты адаптара тунелю пералічаны асобна для IPv4 і IPv6.
Find-NetRouteзапушчаны для аднаго публічнага, аднаго ўнутранага і аднаго выключнага пункта прызначэння.- Правілы NRPT правераны да таго, як вінаваціць маршруты ў збоі імя.
- Патрабаванне блакавання перачытана: пераважная маршрутызацыя — не тое самае, што прымусовае блакаванне.
Рашэнне пра поўны ці split тунель належыць таму, хто валодае профілем, а нататкі Microsoft пра маршрутызацыю апісваюць паводзіны, якія Windows рэалізуе, калі профіль іх задае. Microsoft: прымусовае і split тунеляванне — гэта даведка, якую я трымаю адкрытай, чытаючы вывад.