Общий алгоритм настройки

Это общая обзорная статья, описывающая общий алгоритм настройки модуля 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.avantis.abilling.modules.inet.dyn.device.radius.CoAServiceActivator (он есть среди доступных).

Пример настройки VPN доступа (PPPoE/PPTP)

Заводится тип устройства VPN. И Устройство этого типа как дочернее к Access+Accounting.

Тут желательно ещё раз перечитать главу об InetRadiusProcessor. В самом устройстве настроить

Тут в качестве идентификатора нужно указать значение из атрибута NAS-Identifier radius-запросов, в качестве Хост/порт указать значение из атрибута NAS-IP-Address radius-запросов. Должно быть обязательно заполнено одно из этих полей (при наличии соответствующего атрибута), иначе система не сможет определить к какому устройству привязать radius-пакет. Подробнее об этом описано здесь.

Далее заводится тип сервиса.

Тут тип инициации по сигналу, так как сессия стартует по radius access запросу. Тип адреса - динамический Адрес про статический описано ниже. Как настраивать привязки описано тут.

Привязку Radius нужно указывать если учёт трафика идёт по Radius протоколу. Как настроить конкретный пример для привязки Radius описано ниже. . В случае если подсчёт трафика идёт по Netflow указываете привязку Netflow и как её настроить описано тут. На первом этапе пока можете не указывать привязку и вернуться в ней позже.

Ставите галочку возле поле "Логин-Пароль". Если вы хотите при добавлении сервиса на договор каждый раз указывать устройство явно, к которому они привязано, то ставите галочку "устройство". Но в случае VPN обычно чаще бывают такие варианты

Есть всего один сервер NAS и к нему привязаны все сервисы . В этом случае проще указать const.device.id в типе сервиса и галочку устройство не указывать. Тогда все сервисы этого типа будут автоматом привязаны к этому устройству.
Если несколько NAS-ов и сессия привязывается по факту к тому NAS-у, с которого она вышла, то все NAS объединяются в устройствах в одну общую папку и в const.device.id прописывается эта папка. Вот так это выглядит в устройствах.

Так же указываем title.pattern в типе сервиса.

Далее добавляем сервис на договор.

Отображение сервиса(в данном примере показывает логин) зависит от переменной title.pattern в типе сервиса(после исправления переменной нужно пересохранить сервис).

Если нужно указать статический ip адрес на сервисе, то не забываем про IP ресурсы и переменную ip.resource.categoryId.

Далее заводим простой тариф (примеры). В тарифе должны быть цены и услуги для всех типов трафика. И добавляем тариф на договор .

Тут уже можно настроить RadiusListener-ы в Access и Accounting серверах(если еще не настроили). Перезапустить их, и попробовать авторизовать клиента.

Если нужно учитывать трафики по Radius, то вначале добавляем трафики

Потом добавляем привязку для Radius

Если нужно настроить сбор трафика по netflow, то читаем вот эту статью.

После настройки привязки, не забываем её указать в типе сервиса.

Если нужно в нужно менять какие-то скорости или другие параметры, то это делается с помощью опции Inet (не путать с тарифными опциями) в тарифе. Привязка опции к конкретным атрибутам радиуса указывается в конфигурации устройства (параметр inet.option). Для настройки корректного сброса VPN сессий (с помощью Radius Pod запросов) и для смены параметров(скорости) на лету, без установки новой сессии( Radius COA запрос) нужно в типе устройства поставить обработчик активации сервиса ru.avantis.abilling.modules.inet.dyn.device.radius.CoAServiceActivator (он есть среди доступных).

Пример настройки IPoE, управление доступом

Заводим новый тип устройства, назовём его Dlink.

Добавляем устройство этого типа как дочернее к устройству Access+Accounting.

В самом устройстве прописываем хост:порт(порт ставим 22 для ssh), и логин/пароль пользователя для управления.

Заводим тип сервиса:

Тут тип инициации сессий:

По трафику(это если вы собирайте трафик по netflow и хотите его учитывать).
По сигналу(Если вы хотите чтобы сессия стартовала по dhcp запросу ).

Так как режим какой-то должен быть выбран, то поставьте пока по трафику, даже если сессии вообще не будет(не будет не сигналов, ни трафика). Потом можно будет поменять по мере настройки.

Тип адреса - статический адрес(про динамический будет описано позже). Ставим галочку возле устройства. В title.pattern настроили так, чтобы отображался ip адрес.

Так как мы выбрали статический ip, то нам надо создать для него категорию в ресурсах ip-адресов.

И не забываем id этот категории прописать в переменную ip.resource.categoryId в конфигурации устройства:

Добавляем сервис на договор, выбираем устройство и ip.

Для управления доступом у нам используется обработчик активации сервисов, написанные на динамическом коде. Есть несколько стандартных обработчиков активации сервисов(доступные в стандартной поставке), такие как:

ru.avantis.abilling.modules.inet.dyn.device.terminal.SSHServiceActivator - универсальный обработчик активации сервисов по ssh.
ru.avantis.abilling.modules.inet.dyn.device.terminal.TelnetServiceActivator - универсальный обработчик активации сервисов по telnet.
ru.avantis.abilling.modules.inet.dyn.device.snmp.SnmpServiceActivator - универсальный обработчик активации сервисов по snmp.
ru.avantis.abilling.modules.inet.dyn.device.mikrotik.MikrotikServiceActivator - универсальный обработчик активации сервисов по для Mikrotik, работающий по протоколу Mikrotik Api.

Все они есть в стандартной поставке и описаны в wiki. Есть так же другие .

Пусть для примера мы решили использовать ssh. Тогда мы выбираем ru.avantis.abilling.modules.inet.dyn.device.terminal.SSHServiceActivator в типе устройства.

И конфигурации его указываем команды на подключение и отключение.

#Команды включения сервиса на устройстве
sa.command.serv.enable=permit ip host $ip any
#Команды выключения сервиса на устройстве
sa.command.serv.create=permit ip host $ip any
#Команды создания сервиса на устройстве.
sa.command.serv.disable=deny ip host $ip any
#Команды удаления сервиса с устройства.
sa.command.serv.cancel=deny ip host $ip any

Это команды указаны просто как пример. В данном случае при отправке команд переменная ip будет заменена на тот Ip адрес, который мы поставили в сервисе. Как задавать команды описано в описании ru.avantis.abilling.modules.inet.dyn.device.terminal.SSHServiceActivator.

С этого момента можно попробовать проверить открытие/закрытие доступа на устройстве. Если вы не хотите собирать netlow и обсчитывать трафик, а просто хотите открывать/закрывать доступ на устройстве по ip или интерфейсу, то этого будет достаточно . Можно проверять доступ, меняя баланс на договоре(например расходами и платежами) так чтобы состояние сервиса изменилось (когда баланс больше лимита, то подключено, когда меньше - отключено) и смотреть на устройстве правильно ли отработали команды. В этом режиме не создаются никакие сессии, а только управляется доступ в зависимости от баланса. Этот режим можно использовать, например, для безлимитчиков, для которых не нужно собирать трафик. Так же состояние сервиса можно менять вручную из меню вызываемого по правой кнопкой мыши, это бывает полезно для отладки обработчика активации сервиса.

В случае управления по интерфейсу(открывать/закрывать доступ на интерфейсе) нужно будет выбрать его в типе сервиса и поменять команды на типе устройства (макрос $iface). Все макросы ru.avantis.abilling.modules.inet.dyn.device.terminal.SSHServiceActivator активатора описаны в wiki. Если вы хотите использовать например не ssh, а telnet,то все настраивается аналогично, только указывает другой порт в устроите (23 вместо 22 ) и другой обработчик активации сервиса - ru.avantis.abilling.modules.inet.dyn.device.terminal.TelnetServiceActivator. Для mikrotik есть отдельный обработчик ru.avantis.abilling.modules.inet.dyn.device.mikrotik.MikrotikServiceActivator, работающий по mikrotik api(порт 8728). Для протокола snmp есть ru.avantis.abilling.modules.inet.dyn.device.snmp.SnmpServiceActivator.

Если кроме управления, вы хотите ещё собирать статистику по netflow, то нужно указать ip-адрес в типе сервиса, указать тип инициации по трафику (чтобы сессия создавались по трафику) и в типе сервиса. И настроить netflow согласно этой статье. Также в этом случае понадобится настроит тариф(java.lang.IllegalArgumentException: Title must not be null or empty.), в тарифе должны быть цены и услуги для всех типов трафика, и добавить тариф на договор . Если все будет нормально работать, то у вас должны появляться сессии с трафиком netflow.

Если вы хотите выдавать динамический ip с помощью dhcp option 82, то нужно настроить InetDhcpListener в Access-сервере. Настроить на устройстве переменные java.lang.IllegalArgumentException: Title must not be null or empty.. Тип инициации сессии тогда в типе сервиса нужно установить "по сигналу" (она будет создаваться по dhcp запросу).

Сбор NetFlow/sFlow

В этой главе описана настройка сбора netflow для любой схемы.

Для начала нужно завести типы трафика:

и создать привязку netflow:

На изображении пример простой привязки, когда абсолютно весь трафик делится на входящий и исходящий.

На этом месте лучше прочитать статью про InetFlowListener и исходя из этого построить иерархию устройств и прописать привязку flow-агента flow.agent.link. Если у вас устройство, инициирующее сессии, само является источником flow-потока, то можно создать простую иерархию:

В этом случае в самом устройстве flow.agent.link можно не прописывать вообще. Если нужно указать конкретный интерфейс (например 10), то нужно прописать на устройстве свой id и конкретный интерфейс:

flow.agent.link=2:10

Если netflow собирается с какого-то другого IP (т.е. flow-агент это другая машина), то нужно добавить в иерархию выше ещё одно устройство - источник. В данном случае для этого устройства лучше сделать отдельный тип устройства Netflow source и добавить устройство этого типа в иерархию:

Также вполне возможен случай, когда flow-агент один для нескольких устройств, тогда он является промежуточным предком для нескольких устройств:

В случае отдельного flow-агента нужно либо непосредственно в конфигурации устройства flow-агента:

flow.agent.link={@deviceId}:-1

либо указать привязку flow-агента во всех дочерних устройствах:

flow.agent.link=8:-1

Netflow описывается одинаково для PPPoe и IPoE схем.

Для сбора netflow на Accounting-сервера нужно не забыть прописать InetFlowListener.