Групова політика NPS не є застосуванням ресурсів VPN

Дві групи, два профілі доступу, один VPN-шлюз, і обидві групи зрештою потрапляють на ті самі сервери. Звичайна причина не в зламаній політиці, а у відсутній другій половині задуму: NPS вирішує, хто може встановити сеанс, а щось інше має вирішувати, до чого цей сеанс має доступ. Коли існує лише перша половина, авторизація успішна для кожного, хто проходить автентифікацію. Політика робить свою роботу, а задум усе ще неповний.

Мережева політика, що збіглася за групою, є свідченням про допуск. Вона не є свідченням про пакети, і саме в проміжку між цими двома твердженнями відбувається більшість цієї роботи.

Знайдіть політику, яка справді допустила сеанс

NPS оцінює впорядковані мережеві політики, і перемагає перше ввімкнене правило, умови якого збігаються. Умови можуть включати членство в групі користувачів або комп'ютерів, тип підключення, час і стан пристрою. Тому широка політика, розміщена раніше в списку, допускає підключення ще до того, як вужче правило нижче взагалі буде розглянуто. Порядок не є деталлю інтерфейсу; це і є політика.

Прочитайте список по порядку й визначте те, що збіглося, а потім занотуйте, які параметри воно повернуло. Назва групи в редакторі не є результатом; результат це авторизація, яку отримав сервер. Тримайте авторизацію користувача й авторизацію пристрою окремо там, де розгортання використовує обидві, бо обліковий запис, який може відкрити тунель, не є автоматично обліковим записом, який має мати доступ до кожного внутрішнього сервісу.

Відповідь RADIUS це інструкція, а не фільтр

Атрибут Filter-Id містить назву списку фільтрів. Він не передає переносний набір правил фільтрації пакетів, який розуміє кожен одержувач, а надсилання назви, яку шлюз ніколи не визначав, не застосовує нічого взагалі. Те саме застереження стосується атрибутів VLAN: призначення сеансу тунелю VLAN саме по собі не є маршрутизованим правилом доступу для цього користувача.

Саме тут задум, що виглядає завершеним з боку NPS, тихо не робить нічого. Підтвердьте за документацією постачальника шлюзу, які атрибути авторизації підтримуються і що одержувач робить з кожним із них, замість того щоб припускати, що стандартна назва атрибута означає стандартну поведінку.

Розмістіть застосування там, де проходить трафік

Шлюз, який обробляє пакети користувача, може застосувати фільтр на сеанс, зіставити групу з політикою шлюзу або видати сеансу адресу з відокремленого пулу, з яким міжмережевий екран поводиться інакше. Будь-який із цих варіантів може працювати, і вони відмовляють по-різному. Визначте, який механізм підтримує ваш шлюз, перш ніж писати політику, що його називає. Потім запишіть, що станеться з сеансом, коли цього механізму немає, бо тиша є типовим результатом.

Опишіть передбачуваний дозвіл у чотирьох частинах: ідентичність джерела або група, призначення, протокол і порт. Додайте залежності, які користувач справді потребує, наприклад DNS або службу автентифікації, інакше обмеження зламає процеси входу, які ніхто не здогадався перевірити. Пишіть правило для інтерфейсу, який справді фільтрує, а не для того, який випадково відкритий у редакторі.

Врахуйте також трансляцію. Якщо нижчий міжмережевий екран бачить одну трансльовану адресу джерела для кожного користувача тунелю, він не може розрізнити окремих осіб лише за цією адресою, і правило, написане так, ніби це можливо, буде або марним, або надто широким.

Клієнтські профілі живуть на недовіреному боці

Керований профіль VPN може передавати маршрути, правила роздільного тунелювання або фільтри застосунків, і саме вони формують поведінку слухняного пристрою. Вони не є захистом для сервісу, бо клієнт це сторона, яку ви намагаєтеся обмежити. Видалення маршруту в профілі також не є авторизацією, оскільки клієнт може мати інший шлях до того самого призначення.

Сприймайте клієнтські налаштування як зручність, а налаштування шлюзу як контроль. Коли вони розходяться, правий шлюз, бо саме він бачить пакети.

Прийміть два облікові записи, потім простежте по порядку

Створіть два звичайні тестові облікові записи з різними передбачуваними дозволами, встановіть нові сеанси й перевірте чинну політику шлюзу для кожного. Потім перевірте одну нешкідливу дозволену операцію та один ресурс, який спеціально заборонено. Невдалий ping сам по собі доводить дуже мало, оскільки ICMP може бути відфільтровано, а служба TCP за ним спокійно відповідатиме.

Коли обидва облікові записи все ще мають широкий доступ, простежте у фіксованому порядку: яка політика збіглася, яку авторизацію ніс відповідь і що шлюз із нею зробив. Додавання нових атрибутів NPS до підтвердження того, що одержувач їх реалізує, це шлях, яким маленька проблема авторизації перетворюється на вікно змін без результату.