Чому відповідь RADIUS про VLAN нічого не дає користувачу VPN

Ви додаєте атрибут VLAN до політики NPS, користувач VPN підключається, але ноутбук усе одно потрапляє до типового пулу. Сервер RADIUS повертає те, що ви запитали, тому збій виглядає як проблема кешу. Зазвичай це не так. Access-Accept несе підказки авторизації, і лише сервер мережевого доступу, який їх отримав, може перетворити одну з них на мережеве призначення.

Почніть зі шлюзу, а не з політики

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

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

Що робить комутатор і чого не може VPN

Комутатор доступу 802.1X — це автентифікатор із портами, і динамічне призначення VLAN переносить один із цих портів у VLAN, який комутатор уже несе. Атрибути тунелю RADIUS описують цей намір у формі, зрозумілій комутатору. Маршрутизований VPN завершує тунелі, а не порти комутатора, і його клієнти зазвичай отримують адресу й маршрут замість членства в широкомовному домені. Переносити немає порту, тому тому самому атрибуту нема на що діяти.

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

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

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

radtest alice secret 10.0.0.10 0 testing123

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

Спершу доведіть політику сеансу, потім доступність

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

swanctl --list-sas

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