Это общая обзорная статья, описывающая общий алгоритм настройки модуля Inet. Рекомендуется , рекомендуется к прочтению, потом . Далее можно перейти к примеру примерам настроек VPN и IPoE. Там , в них некоторая информация дублируется, а некоторая представлена в большем объёме. Примеры более сложных схем, таких как Cisco ISG, RedBack Clips и описаны в нашей wiki, но вначале рекомендуем изучить, понять и попробовать простые схемы, а потом уже приступать к более сложным.
Итак настройка Настройка начинается с того, что заводится головное корневое устройство с отдельным типом (обычно тип и устройство называют accessAccess+accountingAccounting). Это устройство является общим, с него не собирают трафик, не дают через него доступ и т.п. Это все лишь корень дерева, который может содержать некоторые общие настройки для приложений InetAccess и InetAccounting.
И это тот корень, который должен быть прописан в rootDeviceId настроек access+accounting серверовInetAccess/InetAccounting серверов.
| Предупреждение |
|---|
Access и Accounting сервера должны быть обязательно установлены и настроены (даже если в них нет ни одного слушателя, например вы и Вы не используете RadiusRADIUS/netflowNetflow/dhcpDHCP). |
Далее заводится дочернее устройство с отдельным типом. Тут В общем случае в иерархии может быть сколько угодно устройств в общем случае . Но это минимальная конфигурация.
Далее заводится тип сервиса.
| Предупреждение |
|---|
Тут важно чтобы у сервиса был либо явно указано устройство к которому оно привязаноВажно чтобы сервис на договоре был привязан к какому-либо устройству. Для этого в типе сервиса либо указывается галочка Устройство (тогда каждый раз придётся указывать устройство при добавлении сервиса на договор), либо в конфигурации типа сервиса указана переменная const.device.id в типе сервиса (в этому случае устройство с данным типом будет привязано автоматически). В случае VPN, например, часто договора привязаны к корневому устройству Access+Accounting или к одному NAS-у, поэтому имеет смысл указывать const.device.id. Если несколько NAS-ов и сессия привязывается по факту к тому NAS-у с которого она вышла, то все NAS объединяются в устройствах в Также можно объединить 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 - тут. Новую привязку нужно указать в типе сервиса. Естественно до настройки привязки не забываем добавить сами типы трафиков.
...