Always On VPN — гэта не доступ да лакальнай сеткі: кантрольны спіс рэсурсаў

Always On — гэта жыццёвы цыкл злучэння: профіль падключаецца падчас або да ўваходу і аднаўляе злучэнне без дзеянняў карыстальніка. Гэта не азначае, што кожны прыватны адрас, пратакол і карыстальнік дазволены. Практычнае пытанне — якія рэсурсы разгорнуты профіль сапраўды дастаўляе, і адказ патрабуе праверкі для кожнага рэсурсу, а не позірку на значок Connected.

Крок 1: Запішыце рэсурс да праверкі

Пачніце з кароткага запісу для кожнай праграмы, узятага з рэальнага асяроддзя: імя, прэфекс прызначэння, служба і порт, роля тунеля, група ідэнтычнасці і шлях рэзалвера.

Name: portal.corp.example
Destination: 10.20.5.0/24
Service: HTTPS 443
Tunnel role: user access after sign-in
Identity: assigned employee group
Resolver: corporate private DNS

Запіс прымушае задаць чатыры асобныя пытанні. Маршрут вырашае, куды ідзе адрас; палітыка DNS вырашае, як кліент даведаецца адрас; фільтр трафіку вырашае, ці можа гэты трафік выкарыстоўваць злучэнне; брандмаўэр прызначэння і дазволы праграмы вырашаюць, ці будзе запыт прыняты. Нішто з гэтага не вынікае з падключанага тунеля.

Крок 2: Вызначце, які тунель павінен несці рэсурс

У Windows Always On VPN ёсць тунель прылады і тунель карыстальніка, якія наладжваюцца як асобныя профілі з асобнымі сертыфікатамі і абсягамі. Тунель прылады звычайна нясе толькі інфраструктуру, патрэбную да ўваходу, напрыклад кіраванне і службы дамена; шырокі доступ супрацоўнікаў да праграм адносіцца да тунеля карыстальніка.

Фільтры трафіку — функцыя тунеля прылады, таму прыклад Microsoft выкарыстоўвае іх для кіравання. Калі скапіяваць гэты прыклад у агульны профіль доступу да рэсурсаў, атрымаеце тунель, які падключаецца, але нясе няправільны набор. Праверце актыўнае злучэнне праз Get-VpnConnection і тэстуйце менавіта пад ім.

Крок 3: Праверце маршрут для рэальнага адраса

Развяжыце імя адзін раз, затым праверце маршрут: Find-NetRoute -RemoteIPAddress 10.20.5.10 паказвае выбраны інтэрфейс, наступны пераход і адрас крыніцы. Калі інтэрфейс — фізічны адаптар, прэфекс адсутнічае ў наборы маршрутаў тунеля або кліент выключыў яго праз раздзелены тунель. Параўнайце з вызначэннем профілю замест дадання лакальнага маршруту.

Лакальны route add можа даць тэсту прайсці і знікнуць пры наступным абнаўленні палітыкі, таму змяненне належыць кіраванаму профілю. Праверце прэфекс у профілях карыстальніка і прылады, а таксама наладу раздзеленага тунеля: поўны тунель не патрабуе маршруту на кожны прэфекс, раздзелены патрабуе па адным для кожнага прыватнага прэфекса.

Крок 4: Праверце развязанне прыватных імён асобна

Прыватныя імёны — уласны шлях палітыкі. Профіль можа дастаўляць правілы NRPT і спіс пошуку суфіксаў DNS, якія дзейнічаюць, пакуль тунель падключаны. Прачытайце праз Get-DnsClientNrptPolicy, што кліент сапраўды атрымаў, затым праверце імя і адрас у адным сеансе. Калі імёны падаюць, а адрасы працуюць — гэта рэзалвер; калі абодва — маршрут.

Імя можа развязацца ў адрас па-за маршрутамі тунеля, што дае сумесь поспеху і тайм-аўту. Параўнайце атрыманы адрас з прэфексам у запісе; калі яны розныя, прыватная зона адказвае публічным або альтэрнатыўным адрасам, і супаўшы маршрут — не той, што спраектаваны.

Крок 5: Праверце фільтры, ідэнтычнасць і ўласныя вароты праграмы

Фільтры трафіку абмяжоўваюць, якія пратаколы і парты могуць выкарыстоўваць тунель прылады, і вузкі набор можа заблакаваць рэсурс, які маршрут мог бы несці. Профіль прызначае злучэнне групе, але рэсурс мае ўласную аўтарызацыю: карыстальнік, які можа падключыцца, не абавязкова прымаецца файлавым серверам.

Змяняйце кіраваны профіль праз яго ўладальніка — Intune, разгортванне ProfileXML або скрыпт аперацыйнай каманды — затым паўторыце тэст пасля звычайнага перападключэння і пасля перазагрузкі: тыповая адмова — састарэлы лакальны маршрут або профіль, ужыты адзін раз. Трымайце версію профілю побач з вынікам тэсту.