...
Данные блоки имеют одинаковую структуру:
| Ключ | Допустимые значения | Описание |
|---|---|---|
|
| Поиск профиля в кэше (MongoDB). Поиск выполняется в соответствии с критериями, указанными в ключе Если оба профиля подбираются с использованием этого метода, системная переменная |
set_first_from_customer_profile | Профиль операторского оборудования извлекается из ранее подобранного профиля абонентского оборудования. В ключе filter определяются критерии отбора операторских профилей, а из удовлетворяющих фильтру профилей выбирается первый. | |
set_first_from_provider_profile | Профиль абонентского оборудования извлекается из ранее подобранного профиля операторского оборудования. В ключе filter определяются критерии отбора абонентских профилей, а из удовлетворяющих фильтру профилей выбирается первый. Данный метод, обычно используется для схемы доступа, в которой абонентское оборудование идентифицируется по данным операторского оборудования, к которому оно подключено: DHCP Option 82, Q-in-Q VLAN и т. д. При этом дополнительная фильтрация может использваться для проверки MAC-адреса абонентского оборудования, или ограничения профилей соответствующим нужной схеме доступа шаблоном, если одновременно используется несколько схем. | |
query | Одна или несколько пар key:value | Запрос для поиска профиля в кэше. Используется только с Несмотря на то, что эти пары задаются не последовательностью, их порядок имеет значение. При запуске, агент формирует в БД кэша недостающие индексы для оптимизации работы с ней. Индексы для подбора профилей формируются с учётом порядка ключей в данном блоке. В связи с этим для оптимальной работы рекомендуется располагать ключи В качестве |
filter | Одна или несколько пар key:value | Фильтр для отбора вложенных профилей. Используется только с set_first_from_customer_profile или set_first_from_provider_profile в качестве значения set_by. В качестве критерия фильтра можно указывать тип привязки абонентского оборудования к операторскому, значения атрибутов подбираемого профиля и т. д. |
| Code Block | ||||
|---|---|---|---|---|
| ||||
plugins:
base:
jmx5-qinq:
actions:
authorize:
customer_profile: &customer_profile
set_by: search_cache
query:
MAC-Address: $request.RAD_REQUEST.User-Name.normalize_mac()
provider_profile: &provider_profile
set_by: search_cache
query:
Switch-VLAN: $var.Remote-Circuit-Ids.Remote_Id
Switch-Port-Code: $var.Remote-Circuit-Ids.Circuit_Id
default_bind_type: network_connection |
...
Шаблоны ответов определяются как последовательность и размещаются в ключе plugins → base → <plugin_instance_name> → actions → authorize → reply конфигурации плагина. Элементы данной последовательности имеют следующую структуру:
| Ключ | Допустимые значения | Описание |
|---|---|---|
condition | Логическое вычисляемое выражение | Условие применения шаблона: шаблон выбирается, если вычисляемое выражение из данного ключа вернуло истину, либо не задано. |
| Пары | Шаблон блока
|
| Пары | Шаблон блока RAD_REPLY ответа на запрос, где key — наименование RADIUS-атрибута ответа, а value — вычисляемое выражение, результат которого станет значением этого атрибута. В качестве value могут использоваться как единичные выражения, так и последовательности таких выражений. Последовательности выражений применяются для атрибутов, допускающих множественные значения, таких как, например, Cisco-AVPair. |
| Значение из словаря $rlm | Числовой код результата обработки запроса. Набор кодов и их предназначение описаны в вики проекта FreeRADIUS. Как правило используются два основных кода:
|
Ядро плагина по очереди (сверху вниз) проверяет каждый шаблон ответа на возможность его применения: если условие применения выполняется, для формирования ответа используется этот шаблон, если нет — ядро переходит к проверке условия для следующего.
...
| Anchor | ||||
|---|---|---|---|---|
|
Проверка количества сессий выполняется в разрезе профилей оборудования следующим образом:
- Разрешённое количество сессий определяется как наибольшее значение атрибута
Simultaneous-Useсреди подобранных абонентского и операторского профилей. Если такой атрибут в обоих профилях отсутствует или пуст, проверка не выполняется. - К базе данных кэша делается запрос для подсчёта текущего количества активных сессий. Учитываются только сессии, привязанные к подобранным ранее профилям оборудования, и находящиеся в активном состоянии: Начата или Обновлена.
- Если текущее количество сессий больше или равно разрешённому, запрос маркируется тегом
simultaneous-limit-exceeded.
Проверка наличия данного может быть использована как для выбора шаблона ответа, так и в after-фильтрах. Это позволяет, например, не отказывать в авторизации «лишним» сессиям, а отправлять для них особый набор атрибутов.
| Code Block | ||||
|---|---|---|---|---|
| ||||
plugins:
base:
l2tp-by-login:
actions:
authorize:
...
authenticate:
customer_profile:
# Критерии подбора абонентского профиля идентичны таковым в authorize
<<: *customer_profile
provider_profile: {}
reply:
# Достигнуто ограничение на количество одновременных сессий
- condition: $context.has_tag?('simultaneous-limit-exceeded')
template:
RAD_REPLY:
Reply-Message: '"You are already logged in"'
result: $rlm.REJECT
# Фиксированный внешний IP-адрес
- condition: ' $customer_profile.attributes.try("Internet-Access-Service-Status") == "SERV_STATE_Provision"
and $customer_profile.attributes.Real-IP-Address.ip4?()'
template:
RAD_REPLY:
Acct-Interim-Interval: '"300"'
Cisco-AVPair:
- '"ip:vrf-id=REAL"'
- '"ip:ip-unnumbered=loopback221"'
Class: $customer_profile.attributes.L2TP-Class.coalesce("7")
Framed-IP-Address: $customer_profile.attributes.Real-IP-Address
Idle-Timeout: '"86400"'
result: $rlm.OK
# Динамический внутренний IP-адрес
- condition: $customer_profile.attributes.try("Internet-Access-Service-Status") == "SERV_STATE_Provision"
template:
RAD_REPLY:
Acct-Interim-Interval: '"300"'
Cisco-AVPair:
- '"ip:vrf-id=NAT"'
- '"ip:ip-unnumbered=loopback220"'
Class: $customer_profile.attributes.L2TP-Class.coalesce("5")
Framed-Pool: '"NAT-1"'
Idle-Timeout: '"86400"'
result: $rlm.OK
# Доступ заблокирован (недостаточно средств)
- template:
RAD_REPLY:
Acct-Interim-Interval: '"600"'
Cisco-AVPair:
- '"ip:vrf-id=NOPAY"'
- '"ip:ip-unnumbered=loopback222"'
Cisco-Service-Info: '"QU;256000;9600;9600;D;256000;9600;9600"'
Framed-Pool: '"FREE-DNAT"'
Idle-Timeout: '"86400"'
mpd-limit:
- '"out#100=all shape 256000 pass"'
- '"in#100=all shape 256000 pass"'
Session-Timeout: '"86400"'
result: $rlm.OK |
Пост-аутентификация — действие post_auth
...
Обновление и запись новых сведений о сессии выполняется в соответствии с настраиваемым шаблоном. Шаблоны сессий определяются как последовательность и размещаются в ключе plugins → base → <plugin_instance_name> → actions → accounting → session → templates конфигурации плагина. Элементы данной последовательности имеют следующую структуру:
| Ключ | Допустимые значения | Описание |
|---|---|---|
condition | Логическое вычисляемое выражение | Условие применения шаблона: шаблон выбирается, если вычисляемое выражение из данного ключа вернуло истину, либо не задано. |
attributes | Пары key:value | Перечень атрибутов сессии, которые необходимо сохранить в записи о ней. Здесь Атрибуты сессии вычисляются и сохраняются только при обработке первого пакета аккаунтинга по данной сессии. Помимо этих атрибутов, при обработке Stop-пакета в отдельный параметр сессии записывается значение атрибута |
| Пары key:value. | Шаблон ответа, где key — наименование RADIUS-атрибута ответа, а value — вычисляемое выражение, результат которого станет значением этого атрибута. В качестве value могут использоваться как единичные выражения, так и последовательности таких выражений. Последовательности выражений применяются для атрибутов, допускающих множественные значения, таких как, например, Cisco-AVPair. |
services | Последовательность структур из трёх полей:
| Перечень услуг, которые необходимо тарифицировать в рамках данной сессии:
Как правило, в рамках одной сессии тарифицируется две детализированных потоковых услуги: для входящего направления трафика и для исходящего. Для вычисления количества по счётчикам
|
| Целое число | Данный параметр применяется только при использовании на сервором доступа сервисной модели, при которой аккаунтинг приходит отдельно для базовой сесии абонента и для предоставляемых в рамках неё сервисов. Для шаблонов сервисных сессий в нём необходимо указать идентфикатор дочернего шабона абонентских профилей, который соответствует данному сервису. Тип такой сервисной сессии будет выбран на основании указанного сервисного шаблона. |
load_to_hydra | true, false | Флаг, отражающий необходимость загрузки записи о данной сессии в основную БД Гидры. По умолчанию загружаются все сессии — данный флаг имеет смысл явно указывать только для «гостевых» сессий, для которых в Гидре нет подходящих профилей оборудования. |
Ядро плагина по очереди (сверху вниз) проверяет каждый шаблон ответа на возможность его применения: если условие применения выполняется, для формирования ответа используется этот шаблон, если нет — ядро переходит к проверке условия для следующего.
...