Что такое RADIUS: доступ к Wi-Fi, VPN и сетевому оборудованию

Зачем компании RADIUS

RADIUS помогает централизовать проверку и назначение сетевого доступа. Вместо отдельных списков пользователей на каждой точке Wi-Fi, VPN-шлюзе и коммутаторе компания использует согласованную политику и сервер, к которому обращаются сетевые устройства.

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

RADIUS не является ни VPN-туннелем, ни каталогом пользователей, ни универсальным firewall. Он участвует в принятии решения и передаёт результат устройству, которое должно корректно применить доступ.

AAA: проверить личность, выдать права, учесть сессию

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

На практике успешная проверка пароля или сертификата может закончиться отказом политики: например, пользователь известен, но не входит в группу VPN. А выданный Access-Accept может содержать дополнительные параметры, которые сетевое устройство ещё должно понять.

Удобно записывать три результата отдельно: личность проверена, политика разрешила, NAS применил необходимые условия. Затем проверяют реальную работу пользователя.

Кто здесь клиент: ноутбук, NAS или сервер

В 802.1X различают supplicant на конечном устройстве, authenticator на сетевой границе и сервер аутентификации. При распространённой схеме точка или контроллер передаёт EAP-обмен серверу через RADIUS. Пользовательский ноутбук не нужно автоматически регистрировать как RADIUS-клиента на сервере.

NAS — Network Access Server: узел, который контролирует конкретный доступ. В серверном плане для него определяют доверенную идентификацию, транспорт, источник запросов и политику. Источником может оказаться контроллер или адрес после согласованного сетевого преобразования, а не management IP каждой точки.

Перед внедрением выясните фактическую архитектуру: автономная точка, контроллер, облачное управление и VPN-продукт могут по-разному инициировать RADIUS-обмен.

Как проходит подключение к корпоративному Wi-Fi

1. Устройство выбирает корпоративный SSID и начинает согласованный 802.1X/EAP-обмен.
2. Точка или контроллер передаёт необходимые сообщения серверу RADIUS.
3. Сервер выполняет выбранный метод и проверяет условия политики, при необходимости обращаясь к каталогу или PKI.
4. В ходе обмена возможны дополнительные раунды Access-Challenge; окончательный результат — разрешение или отказ.
5. NAS применяет разрешённый профиль, VLAN или другие поддержанные атрибуты.
6. Клиент получает адрес и доступ к нужным сервисам; отдельно проверяют DHCP, DNS и правила сети.

Надпись «подключено к Wi-Fi» не доказывает, что завершены все этапы или назначена правильная сеть. Разбирают каждый уровень: EAP, решение RADIUS, применение на NAS, адресацию и приложение.

В PSK-схеме с одним общим паролем Wi-Fi такая проверка каждого пользователя может отсутствовать. Нельзя просто назвать SSID «Enterprise» и считать, что централизованная авторизация уже работает.

EAP-TLS, парольные методы и MFA

EAP — каркас обмена, а EAP-TLS — конкретный метод с сертификатами. В правильно спроектированной EAP-TLS-схеме стороны проверяют сертификаты по заданным правилам; это уменьшает зависимость от вводимого пользователем пароля, но требует жизненного цикла PKI.

Парольные туннельные методы имеют собственные требования к внутренней проверке и защите сервера. Они не взаимозаменяемы с любым способом хранения пароля в LDAP или AD. Наличие каталога и успешный bind не доказывают, что выбранный EAP-метод с ним совместим.

MFA не возникает автоматически от подключения RADIUS. Дополнительный фактор зависит от VPN/NAS, метода, сервера или интеграции, поддержанного challenge-процесса и таймеров. Push, одноразовый код и сертификат должны вписываться в реальный сценарий клиента.

Не обещайте «одинаковую двухфакторную проверку на любом Wi-Fi и VPN». Выберите конкретный сценарий и испытайте его на используемых клиентах, включая повторное подключение и восстановление после сна.

Сертификаты: проверка сервера обязательна

• Доверие: клиент знает нужные CA и ожидаемые имена серверов.
• Назначение: сертификат подходит для роли и метода; проверяются необходимые EKU и другие условия.
• Время: сроки действия и часы устройств согласованы.
• Закрытый ключ: доступен только назначенному владельцу и защищён при хранении.
• Продление и отзыв: заранее определены выпуск, доставка, обновление и действия при компрометации.

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

Для EAP-TLS важна корректная привязка сертификата к учётной записи или устройству. Само наличие выданного сертификата не всегда означает, что владелец продолжает иметь право доступа. Политика учитывает состояние и назначение личности.

Доставка списков отзыва и другие PKI-зависимости должны работать в нужной фазе подключения. Два RADIUS-сервера с одновременно истёкшим сертификатом не дают полезного резерва.

AD, LDAP и RADIUS выполняют разные роли

Каталог хранит учётные записи, группы и другие данные. RADIUS принимает сетевой запрос и применяет политику. NAS разрешает или ограничивает конкретное подключение. Эти функции могут находиться в разных системах, но их роли не исчезают.

Microsoft NPS — RADIUS-сервер и proxy в инфраструктуре Windows Server. FreeRADIUS позволяет строить гибкие схемы на Linux и других поддерживаемых платформах. Есть также специализированные NAC-решения. Выбирают по методам EAP, каталогу, поддержке оборудования, управлению сертификатами, журналам и сопровождению.

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

Разделение ролей помогает расследованию: «каталог видит пользователя», «EAP завершился», «политика сработала» и «точка применила VLAN» — разные наблюдения.

Access-Accept, Access-Reject и назначение VLAN

Для стандартного динамического назначения VLAN в 802.1X используется набор атрибутов наподобие:

Tunnel-Type = VLAN
Tunnel-Medium-Type = IEEE-802
Tunnel-Private-Group-Id = "10"

Это именованные значения атрибутов ответа, а не готовые команды настройки NPS или FreeRADIUS. На точке и uplink должна существовать VLAN 10, а на шлюзе — адресация и правила. Access-Accept без реального применения атрибутов не подтверждает правильный доступ.

Другие платформы используют ACL, роли и vendor-specific attributes. Название группы в каталоге не становится ролью коммутатора автоматически. Проверяют словари, порядок политик и поведение NAS при неизвестном или неподдержанном атрибуте.

В архиве есть офлайн-модель: известный NAS, активный staff и заранее заданные положительные результаты проверки дают VLAN 10. Модель не проверяет пароль или X.509 — входные флаги заданы вручную и показывают только политику решения.

RADIUS для VPN и подрядчиков

VPN-шлюз может передавать проверку доступа RADIUS-серверу и применять поддерживаемые ограничения. Сам туннель, шифрование, маршруты и сетевые ACL реализуются VPN-системой и окружающей инфраструктурой.

• Выделить группу и срок допуска подрядчика, а не использовать общую учётную запись.
• Разрешить нужные ресурсы и протоколы, не весь офис по умолчанию.
• Проверить поддержку MFA, challenge, длительности сеанса и повторной проверки.
• Учитывать доступность сервера из management-сети шлюза и фактический IP-источник запроса.
• Согласовать отключение активной сессии при отзыве доступа.

Тест «правильный пароль принят» недостаточен. Нужны отрицательные случаи: чужая группа, отключённый пользователь, ошибка второго фактора, отказ основного RADIUS и попытка доступа к запрещённому серверу.

Вход администраторов на сетевое оборудование

Централизованный вход на коммутатор или маршрутизатор уменьшает количество локальных учётных записей, но назначение административной роли зависит от платформы. Поддержка RADIUS не гарантирует одинаковые read-only/admin-права или контроль каждой CLI-команды.

Для детального административного command authorization/accounting часто рассматривают TACACS+ и конкретную реализацию. Это другая задача, чем допуск ноутбука к Wi-Fi. Не обещайте универсальный аудит всех команд только из факта наличия RADIUS.

Предусмотрите защищённый аварийный доступ, учёт его использования и проверенный способ восстановления. Но не превращайте любой отказ RADIUS в автоматический вход с полными правами. Отдельно испытывают тайм-аут сервера, явный Access-Reject и поведение локального fallback.

Порты, транспорт и защита передачи

Для классической RADIUS-схемы по UDP обычно используют 1812 для проверки доступа и 1813 для accounting. Исторические 1645/1646 встречаются в старых установках, поэтому фактические номера сверяют на обоих концах.

Shared secret связывает NAS с сервером в соответствующей схеме и участвует в защите обмена, но не означает полное шифрование всего RADIUS-пакета. Защищённый EAP-туннель, шифрование Wi-Fi/VPN и защита NAS↔RADIUS — разные участки.

RadSec использует RADIUS поверх TLS; требуется поддержка соответствующего транспорта и проверка сертификатов у всех участников. Нельзя считать, что любой NPS, коммутатор и VPN-шлюз поддержат одинаковый RadSec-профиль. Для недоверенных сетей выбирают совместимый защищённый транспорт или отдельную защищённую связность.

Тест TCP на 1812 не проверяет обычный UDP RADIUS. Разрешать порт на firewall нужно для реального источника, транспорта и назначения, а не по одной цифре из памятки.

Обновления, Message-Authenticator и доверенные NAS

• Держать сервер в контролируемом сегменте и ограничить доступ ожидаемыми NAS.
• Генерировать отдельные согласованные секреты, защищать хранение и планировать ротацию.
• Обновлять и сервер, и NAS; учитывать security advisory и исправления пакета дистрибутива.
• Проверять настройки Message-Authenticator и связанные требования защиты по актуальной документации реализации.
• Не включать неиспользуемые методы и модули без задачи.

openssl rand -hex 32

Команда генерирует 32 случайных байта в виде 64 шестнадцатеричных символов. Это пример генерации секрета; допустимую длину и формат согласуют с обоими продуктами. Результат не размещают в статье, общедоступной заявке или незашифрованном архиве. Секрет NAS не является паролем пользователя.

BlastRADIUS показал, почему одной старой схемы shared secret недостаточно. Параметры вроде require_message_authenticator и limit_proxy_state применяют по версии и совместимости; не отключают проверку целостности ради прохождения теста.

Проверено по уведомлениям FreeRADIUS 14 ноября 2026 года: в 2026 году также опубликованы отдельные исправления для ветвей 3.0/3.2. Обновление только до старого исправления 2024 года не подтверждает закрытие более новых проблем. Сверяйте установленный пакет и backport-исправления с текущими уведомлениями, а не выбирайте версию из случайного старого руководства.

Два сервера — ещё не вся отказоустойчивость

NAS должен знать резервные серверы и корректно переключаться. Согласуйте тайм-аут, число повторов, dead-time и влияние на длительный EAP/MFA-обмен. Слишком короткие интервалы могут обрывать допустимую проверку и увеличивать нагрузку повторными запросами.

Политики, атрибуты и доверие сертификатам должны совпадать по смыслу. Два сервера с разными списками NAS или группами дадут плавающий доступ, а два узла с единственным недоступным каталогом не устранят общий отказ.

Не смешивайте отсутствие ответа с явным отказом политики. Второй сервер не должен становиться способом обойти Access-Reject. Поведение уже работающих сессий и новых подключений также может различаться.

Accounting: история сессий для расследования

Если accounting включён, NAS может отправлять Start, Stop и промежуточные обновления. Для связи событий важны идентификатор сессии, NAS, время, пользовательская или машинная личность и доступные параметры подключения.

Так можно сопоставить, кто подключился к VPN вечером, через какой шлюз, сколько длилась сессия и совпало ли событие с изменением нагрузки. Для Wi-Fi полезны точка, SSID, назначенный адрес и VLAN — если реализация их действительно передаёт и журнал сохраняет.

Accounting не является записью содержимого трафика или всех действий пользователя. UDP-сообщения могут теряться, Stop может не прийти после аварии, часы могут расходиться. Нужны interim-обновления, контроль пробелов и сопоставление с журналами NAS, приложений и мониторинга.

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

Увольнение, отзыв сертификата и активная сессия

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

CoA и Disconnect в поддерживаемой архитектуре позволяют менять условия или завершать сеанс. Это отдельный обмен с требованиями к защите и разрешённым источникам, а не магический результат удаления пользователя из группы.

В регламенте увольнения указывают ожидаемое время прекращения доступа, активные VPN/Wi-Fi-сессии, сертификаты, личные устройства и аварийные исключения. Затем проверяют конкретное подключение и реальную возможность обратиться к ресурсу.

Как диагностировать отказ без ослабления защиты

Get-Service -Name IAS
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=6272,6273} -MaxEvents 10

На Windows Server с NPS первая команда читает состояние службы. Вторая выбирает ограниченный набор событий разрешения/отказа NPS в Security при настроенном соответствующем аудите. Нужны права на журнал; отсутствие событий может означать настройки аудита, другой узел или отсутствие запросов, а не исправную систему.

freeradius -v
sudo ss -lunp 'sport = :1812'
journalctl -u freeradius --since '-15 min' --no-pager

Пример для Linux-пакета с именем freeradius: версия, UDP-listener и журнал службы за 15 минут. В другом пакете бинарный файл или unit может называться radiusd; сверяйте установленную систему. Эти команды не проверяют EAP, пароль или доступ пользователя. Для TLS-транспорта сокеты проверяют как TCP по его реальному порту.

• Запроса на сервере нет: NAS, IP-источник, транспорт, маршрут и firewall.
• Неизвестный NAS или ошибка целостности: доверенная запись клиента, секреты, поддержка защит и версии.
• EAP не завершается: метод, сертификаты, имена, время, фрагментация и состояние клиента.
• Явный Reject: причина в политике, методе или зависимости; не обходить её широким разрешением.
• Accept без связи: применение роли/VLAN, trunk, DHCP/DNS и правила сети.

Лабораторная проверка простого пароля через radtest не заменяет реальное EAP-TLS-подключение. Отладку запускают в согласованном контуре, защищают вывод и не останавливают рабочий сервер ради теста из инструкции.

План внедрения и проверка отрицательных случаев

1. Определить Wi-Fi/VPN/admin-сценарий, личности, методы, каталог и поддержку NAS.
2. Составить план доверенных клиентов, транспорта, секретов и сертификатов.
3. Настроить узкие политики и ожидаемые атрибуты; согласовать VLAN/ACL на NAS.
4. Провести пилот на отдельной группе и реальном типовом клиенте.
5. Испытать корректный доступ и отказы: отключённый пользователь, неверная группа, недоверенный сертификат и неизвестный NAS.
6. Проверить резервирование, accounting и отзыв активной сессии.
7. Зафиксировать рабочую операцию, мониторинг, инструкции, владельца и возврат.

# Офлайн-модель из ZIP, Windows
py -3 radius-policy-model.py
# Linux: соответствующая команда вместо Windows-варианта
python3 radius-policy-model.py

Программа выполняет 11 проверок учебной политики. Она не посылает пакеты и не проверяет сертификаты: identity_verified и client_cert_valid являются заданными входами. PASS_OFFLINE_POLICY_MODEL означает только согласованность этой модели, не работающий RADIUS.

Первичные источники: RADIUS, accounting, 802.1X и VLAN, Microsoft NPS, уведомления FreeRADIUS. Диагностические примеры относятся к NPS и ветке FreeRADIUS 3.2; реальный сервер, 802.1X, VPN и сертификаты при подготовке не испытывались.

Скачать план и карточку приёмки

В архиве нет рабочих паролей и сертификатов. Это проектирование и модель решения, а не готовая конфигурация сервера или NAS.

Поможем организовать и сопровождать доступ

Вопросы и ответы