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

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

Сетевая политика, совпавшая с группой, — свидетельство о допуске. Это не свидетельство о пакетах, и разрыв между этими двумя утверждениями — то место, где происходит большая часть этой работы.

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

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

Прочитайте список по порядку и определите то, что совпало, затем отметьте, какие параметры оно вернуло. Имя группы в редакторе — не результат; результат — авторизация, которую получил сервер. Держите авторизацию пользователя и авторизацию устройства раздельно там, где развёртывание использует обе, потому что учётная запись, которой можно открыть туннель, не обязательно является учётной записью, которая должна попадать в каждую внутреннюю службу.

Ответ RADIUS — это инструкция, а не фильтр

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

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

Разместите применение там, где проходит трафик

Шлюз, обрабатывающий пакеты пользователя, может применить фильтр для каждого сеанса, сопоставить группу с политикой шлюза или выдать сеансу адрес из изолированного пула, который межсетевой экран обрабатывает иначе. Любой из этих вариантов может работать, и они отказывают по-разному. Определите, какой механизм поддерживает ваш шлюз, прежде чем писать политику, которая его называет. Затем запишите, что происходит с сеансом, когда этого механизма нет, потому что молчание — это состояние по умолчанию.

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

Учтите и трансляцию адресов. Если межсетевой экран ниже видит один транслированный адрес источника для каждого пользователя туннеля, он не может различить людей только по этому адресу, а правило, написанное так, будто может, будет либо бесполезным, либо слишком широким.

Клиентские профили живут на недоверенной стороне

Управляемый профиль VPN может продвигать маршруты, правила разделённого туннеля или фильтры приложений, и они формируют поведение воспитанного устройства. Они не являются защитой для службы, потому что клиент — это сторона, которую вы пытаетесь ограничить. Удаление маршрута в профиле тоже не авторизация, поскольку у клиента может быть другой путь к тому же назначению.

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

Примите с двумя учётными записями, затем проследите по порядку

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

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