Интеграция с FreeRADIUS (AAA)

FreeRADIUS — это сердце сетевого доступа. В нашей архитектуре он выступает как "Policy Enforcement Point" (Точка применения политик).

Микросервис Provisioning не управляет оборудованием (BRAS/BNG) напрямую в момент подключения абонента. Вместо этого он подготавливает "профиль" в базе данных FreeRADIUS. Когда абонент пытается подключиться, BRAS спрашивает FreeRADIUS, и тот отвечает подготовленными атрибутами.

Роль RADIUS в Order-to-Cash: RADIUS — критическое звено, связывающее коммерческую модель (BSS: тариф, баланс, dunning) с сетевым доступом (OSS: скорость, IP, VLAN). Каждая смена тарифа, каждая блокировка за неуплату, каждая "турбо-кнопка" в личном кабинете — всё реализуется через RADIUS-профили и CoA. Время применения CoA < 30 секунд — это SLO, видимое абоненту.

Схема взаимодействия

Важно: Provisioning не пишет в SQL напрямую. Он вызывает AAA Service через ConnectRPC, который управляет radcheck/radreply таблицами и отправляет CoA-пакеты на NAS. Это разделение ответственности: Provisioning знает «что нужно сделать», AAA знает «как это сделать через RADIUS».

Структура базы данных (SQL Schema)

Мы используем стандартную схему FreeRADIUS с небольшими модификациями.

1. radcheck (Аутентификация)

Таблица проверяет, "кто ты".

Почему Cleartext-Password? Для протоколов CHAP и MS-CHAPv2 серверу RADIUS необходим доступ к открытому паролю (или его NT-Hash), чтобы вычислить ответ на Challenge.

2. radreply (Авторизация / Атрибуты)

Таблица говорит, "что тебе можно". Здесь хранятся технические параметры услуги.

3. radacct (Учет / Accounting)

Сюда FreeRADIUS пишет логи сессий. Provisioning и Mediation читают эту таблицу.

Управление скоростью и сервисами (CoA)

Для изменения параметров активной сессии (без разрыва) используется CoA (Change of Authorization).

Сценарий: "Турбо-кнопка" (Смена скорости на лету)

1. Клиент нажимает "Купить турбо" в ЛК.
2. Billing списывает деньги → шлёт событие speed.change через RabbitMQ.
3. Provisioning Service получает команду, создаёт ProvisioningTask (FSM: Received→Executing→Verifying→Completed):
   • Вызывает AAA Service → UpdateProfile(replyAttrs: [Mikrotik-Rate-Limit=100M/100M], sendCoA: true)
   • AAA обновляет radreply в PostgreSQL.
   • AAA отправляет CoA-пакет на NAS через UDP:3799 (layeh.com/radius/vendors/mikrotik).
   • NAS применяет новую скорость без разрыва сессии (CoA-ACK).

Пример CoA пакета (bash/radclient):

echo "User-Name='user-001',Mikrotik-Rate-Limit='100M/100M'" | radclient -x 192.168.1.1:3799 coa mysecret

Go-код (AAA Service, setRadiusAttribute):

// MikroTik VSA — properly encoded via layeh.com/radius/vendors/mikrotik
mikrotik.MikrotikRateLimit_SetString(packet, "100M/100M")

// Huawei VSA — raw encoding, vendor ID 2011
addHuaweiVSA(packet, 2, []byte("102400")) // Huawei-Input-Average-Rate (kbps)

Сценарий: Блокировка (Redirect)

При отрицательном балансе мы не удаляем пользователя, а меняем ему профиль.

Изменения в radreply:

• Mikrotik-Rate-Limit = 64k/64k (шейпинг)
• Mikrotik-Address-List = blocked_users (NAS завернет их на Captive Portal)
• ИЛИ выдаем Framed-Pool = blocked_pool.

Справочник атрибутов (Dictionary)

Разные вендоры (NAS) понимают разные атрибуты.

Mikrotik RouterOS

• Mikrotik-Rate-Limit: Ограничение скорости (rx/tx).
• Mikrotik-Address-List: Добавить IP клиента в Address List (удобно для Firewall).

Cisco (ISG / ASR)

• Cisco-AVPair: ip:sub-qos-policy-in=100M_Input

Huawei ME60

• Huawei-Input-Average-Rate: Ограничение входящей скорости (bps).
• Huawei-Output-Average-Rate: Ограничение исходящей скорости (bps).
• Huawei-Qos-Profile-Name: Применить именованный QoS-профиль.

Eltex

• Eltex-Rate-Limit-Input / Eltex-Rate-Limit-Output: Ограничение скорости.

IPoE (DHCP + Option 82)

Для абонентов без логина/пароля (IPoE) аутентификация выполняется по привязке порт + VLAN через DHCP Option 82.

Схема взаимодействия (IPoE)

Ключевые атрибуты Option 82

Привязка в Inventory: Связка Agent-Circuit-Id → конкретный абонент хранится в Network Inventory. Provisioning при активации создаёт эту привязку.

Отказоустойчивость (HA)

RADIUS — критический компонент. Если он не отвечает, абоненты не могут подключиться.

Конфигурация HA

Рекомендации:

• Два инстанса FreeRADIUS в разных ДЦ/стойках. NAS настроен на оба (primary/secondary).
• PostgreSQL replication: Streaming replication с автоматическим failover (Patroni).
• Health checks: NAS проверяет доступность RADIUS через Status-Server запросы.
• Время переключения: NAS автоматически переключается на secondary при 3 неудачных запросах (настройка на NAS).
• Мониторинг: freeradius-exporter для Prometheus — auth rate, reject rate, response time. Подробнее — Observability.
• Shared secrets: Уникальные для каждого NAS. Подробнее — Безопасность.

Ссылки по теме

• Провижининг: Как создаются профили RADIUS — OSS Layer.
• AAA Service: Подробное описание сервиса — AAA Service.
• Бизнес-сценарии: CoA при блокировке/разблокировке — Workflows.
• API: RabbitMQ-команды для провижининга — API-контракты.
• Мониторинг: Метрики RADIUS и алерты — Observability.
• Безопасность: Shared secrets, сегментация — Безопасность.
• Оборудование: Модели BRAS/OLT — Технологический стек.
• Термины: AAA, CoA, NAS, IPoE, PPPoE — Глоссарий.