![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
ВНЕЗАПНО осознал, что в протоколе RADIUS идентификатор запроса/ответа - 8-битное поле. Поэтому идея транслировать DHCP-запросы в RADIUS-запросы для крупных сетей порочна изначально - более чем 256 одновременных запросов от одного DHCP-сервера к одному RADIUS-серверу независимо от мощностей оборудования делать нельзя без какого-нибудь хитрого мультиплексирования (типа тысячи IP-алиасов на DHCP-сервере), что тоже криво само по себе.
Интересно, насколько хорошо работает FreeRADIUS в роли транслятора между DHCP-протоколом и базой MS SQL. И бывают ли другие трансляторы такого сорта.
Для управления пользователями компания использует IPSoft Billing, имеющий в своём составе RADIUS-сервер, тесно интегрированный с базой. В биллинге для NAS задаётся отдельно Secret key, которым NAS должен авторизовать свои RADIUS-запросы и отдельно POD key, которым биллинг должен авторизовать свои Packet Of Disconnect, посылаемые к NAS для сброса пользователей. Например, если для пользователя предусмотрено ограничение длительности сессии, в конце этой длительности биллинг обрывает сессию посылкой POD на NAS. Или если по какой-то причине техподдержке надо сбросить сессию - например, у юзера украли пароль, он пришел с паспортом и говорит об этом и в это время кто-то держит открытой сессию с его логином. И вообще, мало ли случаев бывает.
Есть куча работающих NAS, для которых всё давно настроено и работает - и биллинг автоматически сессии срубает, и техподдержка вручную по мере надобности. Ставлю новый NAS, настраиваю, прописываю в базе все ключи. В итоге:
- NAS авторизуется на RADIUS-сервере нормально;
- "автоматические" пакеты POD от биллинга авторизацию на NAS проходят;
- а вот те POD, что генерируются по ручным командам техподдержки
на новом NAS авторизацию не проходят, при этом со старыми NAS - никаких проблем.
( Отгадка... )
