Always On VPN не е достъп до LAN: контролен списък за ресурси

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 или скрипт на операциите — после тествайте отново след нормално пресвързване и след рестарт, защото обичайният отказ е остарял локален маршрут или профил, приложен веднъж. Дръжте версията на профила до резултата от теста.