Это общая обзорная статья описывающая общий алгоритм настройки модуля Inet. Рекомендуется к прочтению, потом можно перейти к примеру настроек VPN и IPoE. Там некоторая информация дублируется,а некоторая представлена в большем объёме. Примеры более сложных схем, таких как Cisco ISG, RedBack Clips и описаны в нашей wiki, но вначале рекомендуем изучить, понять и попробовать простые схемы, а потом уже приступать к более сложным.
Итак настройка начинается с того, что заводится головное устройство с отдельным типом ( обычно тип и устройство называют access+accounting). Это устройство является общим, с него не собирают трафик, не дают через него доступ и т.п. Это все лишь корень дерева, который может содержать некоторые общие настройки.
И это тот корень, который должен быть прописан в rootDeviceId настроек access+accounting серверов.
Внимание
Access и Accounting сервера должны быть обязательно и настроены (даже если в них ни одного слушателя, например вы не используете Radius/netflow/dhcp) .
Далее заводится дочернее устройство с отдельным типом. Тут в иерархии может быть сколько угодно устройств в общем случае . Но это минимальная конфигурация.
Далее заводится тип сервиса.
Внимание
Тут важно чтобы у сервиса был либо явно указано устройство к которому оно привязано(тогда каждый раз придётся указывать устройство при добавлении сервиса на договор), либо указана переменная const.device.id в типе сервиса. В случае VPN, например, часто договора привязаны к одному NAS-у, поэтому имеет смысл указывать const.device.id . Если несколько NAS-ов и сессия привязывается по факту к тому NAS-у с которого она вышла, то все NAS объединяются в устройствах в одну общую папку и в const.device.id прописывается эта папка.
Далее добавляем сервис на договор .
Внимание
Вид сервиса зависит от переменной title.pattern в типе сервиса(после исправления переменной нужно пересохранить сервис). В самом сервисе может быть в общем случае что угодно (логин, устройство и т.п ), зависит все это от настроек типа сервиса. Более сложные схемы позволяют заводить дочерние сервисы.
Если нужно указать статический ip адрес на сервисе, то не забываем про IP ресурсы и переменную ip.resource.categoryId.
Для выдачи динамических ip адресов не забываем про параметр radius.realm.<realm>.ipCategories в конфигурации устройства.
Тут мы должны создать (если нам это нужно) типы трафика. И привязку этих типов трафика. Привязка может быть либо по netflow или radius. Про настройку привязки читайте тут. Пример привязки для Radius есть тут, для netflow - тут. Новую привязку нужно указать в типе сервиса. Естественно до настройки привязки не забываем добавить сами типы трафиков.
Если вы не хотите учитывать трафик вообще(не по netflow не по radius), то можете этот момент пропустить, либо вернутся в нему позже.
Далее заводим простой тариф(пример минимального тарифа) . В тарифе должны быть цены и услуги для всех типов трафика(в том числе и для типа трафика Время). И добавляем тариф на договор .
Внимание
После изменения тарифа не забываем выбрать в контекстном меню чтобы Access и Accounting сервера об этом узнали.
В этом месте, если ещё не настроили, то можно настроить и запустить Access и Accounting сервера. Если они уже запущены, то стоит зайти в дерево устройств и нажать там кнопку или перезапустить Acсess и Accounting чтобы они получили новые данные.
Внимание
После изменений в дереве устройств, в типе устройств, в типе сервиса нужно нажимать кнопку в дереве устройств.
При нормальной работе access сервера состояние сервиса на договоре (не путать со статусом) должно смениться с на (если баланс больше лимита). В случае VPN можно проверить установку сессий.
В случае если нужно управлять доступом в зависимости от состояния баланса и статуса договором(что фактически отражено в состоянии сервиса), то нужно чтобы на типе сервиса стоял обработчик активации сервисов. Есть несколько стандартных обработчиков, которые есть сразу в выпадающем списке в типе сервиса, если они не подходят, то можно создать свой. Есть примеры на нашей wiki. Пример настройки подобной схеме есть в главе про IPoE.
Если нужно в нужно менять какие-то скорости или другие параметры, то это делается с помощью опции (не путать с тарифными опциями) в тарифе. Пример тарифа с опциями. Привязка опции к конкретным атрибутам радиуса указывается в конфигурации устройства(Параметр inet.option). Если опция меняет параметры доступа, то обработчик активации сервисов должен обрабатывать её смену в соответствующем методе.
В случае VPN если нужно менять опции на лету, на уже установленных соединениях с помощью Radius Coa запросов и сбрасывать сессий из биллинга с помощью Radius Pod запросов, то нужно использовать обработчик активации сервиса (он есть среди доступных).