Это общая обзорная статья, описывающая общий алгоритм настройки модуля Inet. Рекомендуется , рекомендуется к прочтению, потом . Далее можно перейти к примеру примерам настроек VPN и IPoE. Там , в них некоторая информация дублируется, а некоторая представлена в большем объёме. Примеры более сложных схем, таких как Cisco ISG, RedBack Clips и описаны в нашей wiki, но вначале рекомендуем изучить, понять и попробовать простые схемы, а потом уже приступать к более сложным.
Итак настройка Настройка начинается с того, что заводится головное корневое устройство с отдельным типом (обычно тип и устройство называют accessAccess+accountingAccounting). Это устройство является общим, с него не собирают трафик, не дают через него доступ и т.п. Это все лишь корень дерева, который может содержать некоторые общие настройки для приложений InetAccess и InetAccounting.
И это тот корень, который должен быть прописан в rootDeviceId настроек access+accounting серверов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 ресурсы и переменную ip.resource.categoryId.
Для выдачи динамических ip IP-адресов не забываем про параметр в radius.realm.<realm>.ipCategories в конфигурации устройства.
Тут мы должны создать (если нам это нужно) типы трафика. И привязку этих типов трафика. Привязка трафика может быть либо по netflow Netflow/sFlow или radiusRADIUS. Про настройку привязки читайте тут. Пример привязки для Radius есть тут, для netflow - тут. Новую привязку нужно указать в типе сервиса. Естественно до настройки привязки не забываем добавить сами типы трафиков.
...
Далее заводим простой тариф (пример тарифа) . В тарифе должны быть цены и услуги для всех типов трафика(в том числе и для типа трафика Время). И добавляем тариф на договор .
| Предупреждение |
|---|
После изменения тарифа не забываем выбрать в контекстном меню "Оповещение об изменениях", чтобы 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(он есть среди доступных).