Общий алгоритм настройки
Это общая обзорная статья, описывающая общий алгоритм настройки модуля Inet, рекомендуется к прочтению. Далее можно перейти к примерам настроек VPN и IPoE, в них некоторая информация дублируется, а некоторая представлена в большем объёме. Примеры более сложных схем, таких как Cisco ISG, RedBack Clips и описаны в нашей wiki, но вначале рекомендуем изучить, понять и попробовать простые схемы, а потом уже приступать к более сложным.
Настройка начинается с того, что заводится корневое устройство с отдельным типом (обычно тип и устройство называют Access+Accounting). Это устройство является общим, с него не собирают трафик, не дают через него доступ и т.п. Это все лишь корень дерева, который может содержать некоторые общие настройки для приложений InetAccess и InetAccounting.
И это тот корень, который должен быть прописан в rootDeviceId настроек InetAccess/InetAccounting серверов.
Access и Accounting сервера должны быть обязательно установлены и настроены (даже если в них нет ни одного слушателя, и Вы не используете RADIUS/Netflow/DHCP).
Далее заводится дочернее устройство с отдельным типом. В общем случае в иерархии может быть сколько угодно устройств. Но это минимальная конфигурация.
Далее заводится тип сервиса.
Важно чтобы сервис на договоре был привязан к какому-либо устройству. Для этого в типе сервиса либо указывается галочка Устройство (тогда каждый раз придётся указывать устройство при добавлении сервиса на договор), либо в конфигурации типа сервиса указана переменная const.device.id (в этому случае устройство с данным типом будет привязано автоматически). В случае VPN, например, часто договора привязаны к корневому устройству Access+Accounting или к одному NAS-у, поэтому имеет смысл указывать const.device.id. Также можно объединить NAS'ы в одну общую папку и прописать в const.device.id ID этой папки.
Далее добавляем сервис на договор.
Вид сервиса зависит от переменной title.pattern в типе сервиса(после исправления переменной нужно пересохранить сервис). В самом сервисе может быть в общем случае что угодно (логин, устройство и т.п.), зависит все это от настроек типа сервиса. Более сложные схемы позволяют заводить дочерние сервисы.
Если нужно указать статический IP-адрес на сервисе, то не забываем про IP ресурсы и переменную ip.resource.categoryId.
Для выдачи динамических IP-адресов не забываем про параметр radius.realm.<realm>.ipCategories в конфигурации устройства.
Тут мы должны создать (если нам это нужно) типы трафика. И привязку этих типов трафика. Привязка трафика может быть либо по Netflow/sFlow или RADIUS. Про настройку привязки читайте тут. Пример привязки для Radius есть тут, для netflow - тут. Новую привязку нужно указать в типе сервиса. Естественно до настройки привязки не забываем добавить сами типы трафиков.
Если вы не хотите учитывать трафик вообще(не по netflow не по radius), то можете этот момент пропустить, либо вернутся в нему позже.
Далее заводим простой тариф (пример тарифа) . В тарифе должны быть цены и услуги для всех типов трафика(в том числе и для типа трафика Время). И добавляем тариф на договор .
После изменения тарифа не забываем выбрать в контекстном меню "Оповещение об изменениях", чтобы Access и Accounting сервера об этом узнали.
В этом месте, если ещё не настроили, то можно настроить и запустить Access и Accounting сервера. Если они уже запущены, то стоит зайти в дерево устройств и нажать там кнопку "Перечитать конфигурацию на серверах" или перезапустить Acсess и Accounting чтобы они получили новые данные.
После изменений в дереве устройств, в типе устройств, в типе сервиса нужно нажимать кнопку "Перечитать конфигурацию на серверах" в дереве устройств.
При нормальной работе access сервера состояние сервиса на договоре (не путать со статусом) должно смениться с удален на подключен(если баланс больше лимита). В случае VPN можно проверить установку сессий.
В случае если нужно управлять доступом в зависимости от состояния баланса и статуса договором(что фактически отражено в состоянии сервиса), то нужно чтобы на типе сервиса стоял обработчик активации сервисов. Есть несколько стандартных обработчиков, которые есть сразу в выпадающем списке в типе сервиса, если они не подходят, то можно создать свой. Есть примеры на нашей wiki. Пример настройки подобной схеме есть в главе про IPoE.
Если нужно в нужно менять какие-то скорости или другие параметры, то это делается с помощью опции (не путать с тарифными опциями) в тарифе. Пример тарифа с опциями. Привязка опции к конкретным атрибутам радиуса указывается в конфигурации устройства (параметр radius.inetOption.x). Если опция меняет параметры доступа, то обработчик активации сервисов должен обрабатывать её смену в соответствующем методе.
В случае VPN если нужно менять опции на лету, на уже установленных соединениях с помощью Radius Coa запросов и сбрасывать сессий из биллинга с помощью Radius Pod запросов, то нужно использовать обработчик активации сервиса ru.bitel.bgbilling.modules.inet.dyn.device.radius.CoAServiceActivator(он есть среди доступных).