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 або скрипт експлуатації — потім повторіть тест після звичайного перепідключення і після перезавантаження: типова причина — застарілий локальний маршрут або профіль, застосований один раз. Тримайте версію профілю поруч із результатом тесту.