Почему ответ 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

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