Плагин proxy
Замена фильтру conditional_plugin_selector
из второй версии агента.
Структура конфигурации
plugins: proxy: dhcp: routes: base/dhcp-o82: $request.RAD_REQUEST.try("DHCP-Relay-Circuit-Id").present?() base/dhcp-ip-private: $request.RAD_REQUEST.DHCP-Client-IP-Address.private_ip4?() default: "base/dhcp-ip-public"
Запрос будет передан первому плагину, для которого выполнится условие. Если ни одно условие не выполнилось, запрос уйдёт плагину, указанному в ключе default
Плагин base
Данный плагин предназначен для непосредственной обработки запросов, поступающих от сервера FreeRADIUS.
Стэк обработки запроса
plugins
→ base
→ <name>
→ call_stack
Определяет порядок вызова рабочим процессом фильтров для обработки поступившего запроса:
- Вызываются фильтры в прямом (сверху вниз) порядке, при этом пропускаются
after
-фильтры. - Запрос обрабатывается ядром плагина: выполняется действие, соответствующее типу запроса и формируется ответ.
- Вызываются фильтры в обратном (снизу вверх) порядке, при этом пропускаются
before
-фильтры.
Действия ядра плагина
plugins
→ base
→ <name>
→ actions
В данной ветви конфигурации содержатся отдельные блоки, определяющие действия ядра плагина для каждого поддерживаемого типа запроса. На текущий момент поддерживаются 4 типа запросов сервера FreeRADIUS:
- Авторизация.
- Аутентификация.
- Пост-аутентификация.
- Аккаунтинг.
Общее описание того, что происходит на этих стадиях в самом сервере FreeRADIUS доступно в вики проекта: http://wiki.freeradius.org/guide/Concepts.
Авторизация — действие authorize
На данном этапе обработки запроса RADIUS-сервером от агента HARD требуется:
- Определить, известно ли ему абонентское оборудование, запросившее доступ.
- Предоставить RADIUS-серверу корректный пароль для выполнения аутентификации.
Для этого в действии выполняются:
- Подбор профилей оборудования.
- Формирование ответа.
Подбор профилей оборудования
Параметры подбора профилей оборудования определяются в блоках plugins
→ base
→ <name>
→ actions
→ authorize
→ customer_profile
и plugins
→ base
→ <name>
→ actions
→ authorize
→ provider_profile
для профилей абонентского и операторского оборудования соответственно. Подобранные профили записываются в системные переменные $customer_profile
и $provider_profile
, а идентификатор привязки абонентского профиля к операторскому — в переменную $bind_id
.
Данные блоки имеют одинаковую структуру:
Ключ | Допустимые значения | Описание |
---|---|---|
|
| Поиск профиля в кэше (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 . В качестве критерия фильтра можно указывать тип привязки абонентского оборудования к операторскому, значения атрибутов подбираемого профиля и т. д. |
Формирование ответа
После подбора профилей, можно формировать ответ. На этом этапе в распоряжении ядра плагина имеются следующие данные:
- Обрабатываемый запрос в
$request
. - Профиль абонентского оборудования в
$customer_profile
. - Профиль операторского оборудования в
$provider_profile
. - Идентификатор привязки абонентского оборудования к операторскому в
$bind_id
. - Установленные
before
-фильтрами пользовательские переменные в словаре$var
и теги в$context
.
Все эти сведения об авторизуемом оборудовании могут использоваться в вычисляемых выражениях как для выбора шаблона ответа, так и для заполнения атрибутов выбранного шаблона конкретными значениями.
Шаблоны ответов определяются как последовательность и размещаются в ключе plugins
→ base
→ <name>
→ actions
→ authorize
→ reply
конфигурации плагина. Элементы данной последовательности имеют следующую структуру:
Ключ | Допустимые значения | Описание |
---|---|---|
condition | Логическое вычисляемое выражение | Условие применения шаблона: шаблон выбирается, если вычисляемое выражение из данного ключа вернуло истину, либо не задано. |
template | Пары key:value | Шаблон ответа, где key — наименование RADIUS-атрибута ответа, а value — вычисляемое выражение, результат которого станет значением этого атрибута. В качестве value могут использоваться как единичные выражения, так и последовательности таких выражений. Последовательности выражений применяются для атрибутов, допускающих множественные значения, таких как, например, Cisco-AVPair . |
Ядро плагина по очереди (сверху вниз) проверяет каждый шаблон ответа на возможность его применения: если условие применения выполняется, для формирования ответа используется этот шаблон, если нет — ядро переходит к проверке условия для следующего.
Формирование ответа, включая выбор шаблона, может выполняться не самим ядром плагина, а специальным фильтром render_reply_after
. При наличии такого фильтра в стэке обработки запроса, ядро плагина не формирует ответ, а только подбирает профили оборудования. Это позволяет провести дополнительные вычисления и проверки с помощью after
-фильтров и уже на основании их результатов формировать ответ.
Аутентификация — действие authenticate
На данном этапе RADIUS-сервер от агента HARD требуется подготовить атрибуты ответа, которые сервер отправит в случае успешной аутентификации модулем pap, eap, mschap и т.п. Для этого в действии выполняются:
- Подбор профилей оборудования.
- Проверка ограничения количества одновременных сессий.
- Формирование ответа.
Подбор профилей и шаблоны ответов настраиваются аналогично действию authorize
. Как правило, критерии подбора профилей и шаблоны ответов используются те же, что и в authorize
— чтобы их не повторять в конфигурации, рекомендуется применять такие элементы YAML-формата как якори и ссылки.
Ограничение количества одновременных сессий
Проверка количества сессий выполняется в разрезе профилей оборудования следующим образом:
- Разрешённое количество сессий определяется как наибольшее значение атрибута
Simultaneous-Use
среди подобранных абонентского и операторского профилей. - К базе данных кэша делается запрос для подсчёта текущего количества активных сессий. Учитываются только сессии, привязанные к подобранным ранее профилям оборудования, и находящиеся в состоянии Начата или Обновлена.
- Если текущее количество сессий больше или равно разрешённому, запрос маркируется тегом
simultaneous-limit-exceeded
.
Проверка наличия данного может быть использована как для выбора шаблона ответа, так и в after
-фильтрах. Это позволяет, например, не отказывать в авторизации «лишним» сессиям, а отправлять для них особый набор атрибутов.
Пост-аутентификация — действие post_auth
Данный тип запросов, как правило, используется сервером FreeRADIUS только при работе в режиме DHCP-cервера. Также может применяться для выполнения дополнительных обработок ответа перед отправкой его сервером FreeRADIUS.
Примером такой обработки является вызов хука для отправки в очередь сообщения, содержащего динамический IP-адрес, выдаваемый сервером FreeRADIUS. Если пул динамических IP-адресов реализован на стороне RADIUS-сервера, то выдача адреса из такого пула выполняется сервером в начале этапа пост-аутентификации. В этот момент серверу уже известно, нужно ли выдавать динамический IP-адрес, и если нужно, то из какого пула.
Операции выполняются те же, что и в действии authorize
:
- Подбор профилей оборудования.
- Формирование ответа.
Критерии подбора и шаблоны профилей настраиваются аналогично действию authorize
.
Аккаунтинг — действие accounting
Выделение первого пакета аккаунтинга по сессии