Идентификация по IP-адресу (IPoE на базе Cisco ISG)

Настройка провижининга

Теги и дополнительные параметры

В разделе Справочники → Теги добавляем новый тег доступ_через_isg для маркировки пакетов услуг, оказываемых с использованием Cisco ISG.

Соответствия сервисов ISG и пакетов услуг будем хранить в виде дополнительных параметров номенклатурных позиций этих пакетов. Заполнение сервисов сделаем через выбор справочного значения, а не через ручной ввод наименований.

В разделе Справочники → Базовые добавляем новый пользовательский справочник:

• Наименование — Сервисы Cisco ISG.
• Код — REF_TYPE_Cisco-ISG-Services.

Добавляем в новый справочник записи, по одной на каждый сервис. В добавляемых записях указываем только названия сервисов. Сами сервисы либо настраиваются статически на Cisco ISG, либо динамически конфигурируются через отдельные RADIUS-запросы от ISG. Второй вариант позволяет достаточно просто вводить новые линейки тарифных планов, отличающиеся, например скоростями доступа к сети Интернет. Оператор при таком подходе просто добавляет новый сервис в справочник и сопоставляет его с нужными пакетами услуг, а ISG получив новое имя сервиса автоматически делает дополнительный RADIUS-запрос, агент HARD отдельно его обрабатывает и формирует ответ с атрибутами-параметрами сервиса. Например, в наименованиях сервисов доступа к сети Интернет можно указать величину ограничения скорости доступа (Rate и Burst):

В разделе Справочники → Номенклатура для группы, содержащей все оказываемые посредством Cisco ISG пакеты услуг, добавляем дополнительный параметр:

• В поле Наименование указываем, например Сервис Cisco ISG.
• В поле Код пишем Cisco-ISG-Service — этот код потребуется при настройке шаблона профилей абонентского оборудования.
• Выбираем Тип — Справочное значение.
• В лукапе Справочник указываем ранее созданный базовый пользовательский справочник Сервисы Cisco ISG.
• Устанавливаем флаг Множественность — это позволит для одного пакета услуг выбирать несколько сервисов.
• Устанавливаем флаг Наследуется позициями: параметр мы задаём для группы номенклатурных позиций, но значения нам нужны для конкретных пакетов услуг.

Для всех номенклатурных позиций пакетов услуг, оказываемых посредством Cisco ISG, указываем сервисы ISG в новом параметре Сервис Cisco ISG и добавляем ранее созданный тег доступ_через_isg:

Родительский шаблон профилей абонентского оборудования

В разделе Оборудование → Шаблоны профилей (необходимо право Провижининг → Редактирование шаблонов профилей) создаём новый шаблон:

1. В поле Тип оборудования выбираем номенклатурную позицию абонентского оборудования, например Оконечное оборудование.
2. В поле Теги услуг указываем тег доступ_через_isg, которым на предыдущем этапе промаркировали соответствующие пакеты услуг.
3. Заполняем Наименование: IPoE - Базовый доступ.
4. В блоке Состояние услуги отмечаем все состояния: авторизацию необходимо выполнять при любом состоянии услуги (кроме технологического Услуга заказана), но от этого состояния будет зависеть набор назначаемых сервисов.
   
   
   
   
5. Нажимаем на кнопку Добавить — форма создания шаблона сменится формой его редактирования:
   
   
   
   

Наполняем шаблон атрибутами с помощью кнопки Добавить на форме его редактирования:

Меняем состояние шаблона на Активен и нажимаем Сохранить, после чего переформировываем профили по новому шаблону.

Открываем вкладку Профили абонентского оборудования, подписанного на промаркированный тегом доступ_через_isg пакет услуг, и убеждаемся, что профили сформировались корректно. Периоды действия профилей определяются периодами действия участвующих в них привязок адресов к оборудованию, поэтому в данном случае у каждого оборудования с одним привязанным IP-адресом должно быть два профиля по этому шаблону, но только один из них активный. Также могут быть, разумеется, профили по другим шаблонам:

Дочерние шаблоны профилей абонентского оборудования

Для тех категорий сервисов, по которым будет учитываться отдельный RADIUS-аккаунтинг, создаём дочерние шаблоны профилей абонентского оборудования. Также дочерние шаблоны будут полезны для таких тарифных опций как «Турбо-кнопки» (временное ускорение доступа к сети Интернет), которым соответствуют отдельные сервисы: атрибут со списком сервисов родительского профиля может дополняться значениями одноименного атрибута дочерних профилей. В данном примере рассмотрим только две категории сервисов, аккаунтинг по которым мы хотим обрабатывать раздельно: доступ к сети Интернет и к локальным ресурсам.

Шаблон для сервисов доступа к сети Интернет

В разделе Справочники → Теги создаём тег isg-сервис_интернет и маркируем им соответствующую услугу, входящую в состав промаркированного ранее тегом доступ_через_isg пакета услуг. Например детализированную потоковую услугу Интернет-трафик вх.:

В разделе Оборудование → Шаблоны профилей создаём новый дочерний шаблон:

1. В поле Тип оборудования выбираем ту же номенклатурную позицию абонентского оборудования, что и в ранее созданном родительском шаблоне — Оконечное оборудование.
2. В поле Теги услуг указываем тег isg-сервис_интернет, которым на предыдущем этапе промаркировали услугу Интернет-трафик вх.
3. Заполняем Наименование: IPoE - Доступ к сети Интернет.
4. В блоке Состояние услуги отмечаем только Услуга оказывается: доступ к сети Интернет мы хотим предоставлять только при отсутствии на лицевом счете задолженности.
5. В поле Родительский шаблон выбираем созданный ранее шаблон IPoE - Базовый доступ.
6. Нажимаем на кнопку Добавить — форма создания шаблона сменится формой его редактирования:
   
   

С помощью кнопки Добавить на форме редактирования шаблона добавляем в него атрибут:

Шаблон для сервисов доступа к локальным ресурсам

Выполняем все те же действия, что и на предыдущем этапе для сервисов доступа к сети Интернет, только с другими услугами и наименованиями:

1. В разделе Справочники → Теги создаём тег isg-сервис_локальные_ресурсы и маркируем им соответствующую услугу, входящую в состав промаркированного ранее тегом доступ_через_isg пакета услуг. Например детализированную потоковую услугу Локальный трафик вх.
2. В разделе Оборудование → Шаблоны профилей создаём новый дочерний шаблон:
   • В поле Тип оборудования выбираем ту же номенклатурную позицию абонентского оборудования, что и в ранее созданном родительском шаблоне — Оконечное оборудование.

   • В поле Теги услуг указываем тег isg-сервис_локальные_ресурсы, которым на предыдущем этапе промаркировали услугу Локальный трафик вх.

   • Заполняем Наименование: IPoE - Доступ к локальным ресурсам.

   • В блоке Состояние услуги отмечаем только Услуга оказывается: доступ к данному сервису мы также хотим предоставлять только при отсутствии на лицевом счете задолженности.

   • В поле Родительский шаблон выбираем созданный ранее шаблон IPoE - Базовый доступ.

3. На форме редактирования нового дочернего шаблона профилей абонентского оборудования добавляем в него атрибут:

   Подстановка	Наименование	Параметры
   Состояние услуги	Local-Service-Status	Временной интервал — Прочерк. Обязательный атрибут — Да. Заменять значением атрибута дочернего профиля — Нет. Параметры для вычисления: Возвращаемое значение — Код.

Формирование дочерних профилей

Созданные на предыдущих этапах дочерние шаблоны профилей абонентского оборудования переводим в состояние Активен, после чего переформировываем по ним профили.

Открываем вкладку Профили абонентского оборудования, подписанного на промаркированный тегом доступ_через_isg пакет услуг и убеждаемся к родительскому профилю IPoE - Базовый доступ добавились дочерние профили IPoE - Доступ к сети Интернет и IPoE - Доступ к локальным ресурсам:
 

Типы сессий

В разделе Оборудование → Типы сессий (необходимо право Провижининг → Редактирование типов сессий) добавляем новый тип:

1. Указываем Наименование, например IPoE - Базовый доступ.
2. В комбобоксе Шаблон абонентского профиля выбираем добавленный на ранее родительский шаблон IPoE - Базовый доступ.
3. В полях Шаблон операторского профиля и Тип привязки оставляем прочерки: в данном случае профили операторского оборудования не используются.
4. Устанавливаем флаг Удалять подстановки без значений из команд.

5. В поле Команды → Прерывание вводим шаблон команды принудительного завершения сессии:

   /usr/local/hydra-scripts/isg_session_control.sh --action=disconnect --session-id={SESSION.VC_EXT_ID} --nas-ip={SESSION.NAS-IP-Address}

   Как правило, для отправки PoD-запроса прерывания сессии достаточно её идентификатора и IP-адреса сервера доступа. Если в вашем случае необходимы дополнительные данные, скорректируйте шаблон команды.

6. В поле Команды → Изменение вводим шаблон команды принудительного завершения сессии:

   /usr/local/hydra-scripts/isg_session_control.sh --action=change --session-id={SESSION.VC_EXT_ID} --nas-ip={SESSION.NAS-IP-Address} --prev-services={PREV.ISG-Services} --next-services={NEXT.ISG-Services} --prev-serv-status={PREV.Service-Status} --next-serv-status={NEXT.Service-Status}

   При использовании шаблона такого вида скрипт /usr/local/hydra-scripts/isg_session_control.sh будет вызываться как при изменении набора сервисов ISG (например, оператор добавил новый сервис к тарифу в номенклатуре), так и при изменении биллингом состояния пакета услуг.

   В качестве аргументов скрипту при таком шаблоне будут переданы старый и новый список сервисов, а также старое и новое состояние оказания пакета услуг. На основании этого полного набора данных о произошедших в биллинге изменениях в скрипте вы можете реализовать нужную логику управления сервисами посредством отправки CoA-запросов на Cisco ISG.

7. Нажимаем кнопку Добавить и форма создания сменяется формой редактирования:
   
   
   
   
8. Меняем Состояние на Активен и нажимаем Сохранить.

Далее аналогично добавляем ещё два типа для сервисных сессий: IPoE - Доступ к локальным ресурсам и IPoE - Доступ к сети Интернет, указывая в них одноимённые дочерние шаблоны профилей абонентского оборудования. Отдельные команды для сервисных сессий, как правило не требуются: достаточно команд по базовым сессиям — оставляем поля Прерывание и Изменение в разделе Команды пустыми.

Иерархия типов сессий определяется иерахией шаблонов профилей абонентского оборудования, поэтому созданные типы сервисных сессий должны отображаться как дочерние относительно типа базовых сессий:

Настройка брокера ActiveMQ

Установку и настройку, если этого на настраиваемом сервере ещё не сделано ранее, производим в соответствии со статьёй Настройка брокера ActiveMQ.

Настройка агента HARD

Установку агента, если этого на настраиваемом сервере ещё не сделано ранее, выполняем в соответствии со статьёй Установка агента HARD.

Общие параметры

Редактируем общий конфигурационный файл агента в соответствии с примером:

# Список активных плагинов
enabled_plugins:
  - 'base/ipoe-isg'

# Логирование
log:
  # Общий лог агента
  common:
    # Уровень логирования: debug для отладки, info для эксплуатации
    level: 'debug'

# Системные фильтры
filters:
  # Базовая HTTP-аутентификация клиента (hard.pm в FreeRADIUS)
  agent.basic_auth:
    main:
      # Логин базовой аутентификации
      login: 'freeradius'
      # Пароль базовой аутентификации
      password: 'freeradius_password'

# Серверные процессы агента
server:
  # IP-адрес сетевого интерфейса для приема запросов
  address: '127.0.0.1'
  # Номер TCP-порта для приема запросов
  port: 11080
  # Количество дочерних процессов агента - обработчиков запросов
  workers: 4

# Подключения к базам данных
connection_pools:
  # Подключение к БД кэша (MongoDB)
  mongo:
    main:
      # IP-адрес mongod
      host: '127.0.0.1'
      # Номер TCP-порта mongod
      port: 27027
      # Наименование базы данных
      name: 'hard_cache'
      # Имя пользователя базы данных
      user: 'hard'
      # Пароль пользователя базы данных
      password: 'mongo_user_password'

  # Подключение к БД провижининга (Oracle)
  database:
    main:
      # Наименование (net service name) базы данных
      name: 'hydra'
      # Имя пользователя базы данных
      user: 'AIS_RADIUS'
      # Пароль пользователя базы данных
      password: 'oracle_user_password'

      # Служебный абонент Гидры
      hydra:
        # Логин пользователя Гидры для доступа к приложению RADIUS-сервер
        user: 'hard'
        # Пароль пользователя Гидры для доступа к приложению RADIUS-сервер
        password: 'hydra_user_password'

# Синхронизация кэша с провижинингом
syncer:
  stomp:
    # IP-адрес сервера ActiveMQ
    host: '127.0.0.1'
    # Номер TCP-порта STOMP-коннектора ActiveMQ
    port: 61613
    # Логин пользователя ActiveMQ
    login: 'hydra'
    # Пароль пользователя ActiveMQ
    password: 'activemq_user_password'

  queues:
    # Наименование ActiveMQ-очереди с сообщениями об изменении профилей оборудования
    profiles: 'hydra_profiles_1'
    # Наименование ActiveMQ-очереди с сообщениями об изменении привязок оборудования
    binds: 'hydra_equipment_binds_1'

В данной конфигурации меняем значения параметров с паролями:

• Пароль базовой аутентификации модулей hard.pm и hard-dhcp.pm сервера FreeRADIUS: ключ filters → agent.basic_auth → main → password.
• Пароль пользователя базы данных кэша: ключ connection_pools → mongo → main → password.
• Пароль пользователя базы данных провижининга: ключ connection_pools → database → main → password.
• Пароль пользователя Гидры для доступа к приложению RADIUS-сервер: ключ connection_pools → database → main → hydra → password.
• Пароль пользователя ActiveMQ: ключ syncer → stomp → password.

В MongoDB, если этого на настраиваемом сервере ещё не сделано ранее, добавляем БД hard_cache и пользователя hard для неё в соответствии с описанным в статье Настройка агента HARD примером.

Экземпляр плагина base

Добавляем конфигурационный файл экземпляра ipoe-isg плагина base агента HARD в соответствии с примером:

plugins:
  # Фильтры обработки запросов
  filters:
    set_tag_before:
      # Маркировка запросов авторизации динамически конфигурируемых ISG-сервисов
      auth-internet-access-isg-service:
        condition: '   not $context.has_tag?("accounting")
                   and $request.RAD_REQUEST.User-Name.like?("^IPOE-SC-INET")'
        value: auth-internet-access-isg-service

      # Маркировка запросов аккаунтинга по базовой сессии
      base-session-accounting:
        condition: '   $context.has_tag?("accounting")
                   and not $request.RAD_REQUEST.Cisco-AVPair.join().like?("parent-session-id=")'
        value: base-session-accounting

    match_before:
      # Выделение из имени ISG-сервиса параметров ограничения скорости доступа
      get_speed_limit_values_for_internet-access-isg-service:
        condition: $context.has_tag?("auth-internet-access-isg-service")
        value_expression: $request.RAD_REQUEST.User-Name
        destination: $var.Service-Auth-Speed-Limits
        matcher: '^.+-(?P<Rate>\d+)-(?P<Burst>\d+)$'

    format_after:
      # Формирование значения атрибута с параметрами конфигурируемого сервиса
      set_cisco-service-info_attr_for_internet-access-isg-service:
        condition: $context.has_tag?("auth-internet-access-isg-service")
        values:
          Rate: $var.Service-Auth-Speed-Limits.Rate
          Burst: $var.Service-Auth-Speed-Limits.Burst
        destination: $response.RAD_REPLY.Cisco-Service-Info
        template: QU;#{$Rate};#{$Burst};#{$Burst};D;#{$Rate};#{$Burst};#{$Burst}

    map_after:
      # Добавление префикса A к наименованиям всех назначаемых сервисов
      add_prefix_a_to_assigned_isg-services:
        condition: $response.try("RAD_REPLY").try("Cisco-Account-Info").present?()
        destination: $response.RAD_REPLY.Cisco-Account-Info
        value_expression: $response.RAD_REPLY.Cisco-Account-Info
        filter_expression: $value.present?()
        transform_expression: '"A" + $value'

  base:
    ipoe-isg:
      call_stack:
        # Стандартные фильтры
        - reject_on_error/main
        - set_tag_before/request_type

        # Аккаунтинг по базовой сессии
        - set_tag_before/base-session-accounting

        # Авторизация ISG-сервисов IPOE-SC-INET-<Rate>-<Burst>
        - set_tag_before/auth-internet-access-isg-service
        - match_before/get_speed_limit_values_for_internet-access-isg-service
        - format_after/set_cisco-service-info_attr_for_internet-access-isg-service

        # Добавление префикса A к наименованиям всех назначаемых сервисов
        - map_after/add_prefix_a_to_assigned_isg-services

      actions:
        authorize:
          customer_profile: &customer_profile
            # Профиль абонентского оборудования подбираем в БД кэша
            set_by: search_cache
            query:
              # Критерий выбора профиля - IP-адрес из User-Name в атрибуте ISG-IP-Address
              ISG-IP-Address: $request.RAD_REQUEST.User-Name

          # Операторское оборудование в данной схеме не используется - не подбираем профиль
          provider_profile: {}

          # Объявляем YAML-якорь auth_reply, чтобы в действии authenticate не дублировать данный раздел
          reply: &auth_reply
            # Авторизация ISG-сервисов с наименованием вида IPOE-SC-INET-<Rate>-<Burst>
            - condition: '   $context.has_tag?("auth-internet-access-isg-service")
                         and $request.RAD_REQUEST.User-Name.like?("^IPOE-SC-INET(-\d+){2}$")'
              template:
                RAD_CHECK: &default_rad_check
                  # В качестве правильного пароля для FreeRADIUS подставляем тот, что пришёл в запросе
                  Cleartext-Password: $request.RAD_REQUEST.User-Password

                RAD_REPLY:
                  # Атрибуты, которые будут отправлены в ответ на запрос авторизации сервиса
                  # По ним Cisco ISG сформирует конфигурацию сервиса, после чего сможет активировать его для сессий
                  Cisco-AVPair:
                    - '"subscriber:accounting-list=HYDRA-IPOE"'
                    - '"ip:traffic-class=in access-group name IPOE-ACL-ALL-TRAFF priority 1000"'
                    - '"ip:traffic-class=out access-group name IPOE-ACL-ALL-TRAFF priority 1000"'
                  Acct-Interim-Interval: '"300"'

                result: $rlm.OK

            # Профиль абонентского оборудования не подобрался - отвечаем отказом
            - condition: $customer_profile.null?()
              template:
                RAD_CHECK:
                  Auth-Type: '"Reject"'
                RAD_REPLY:
                  Reply-Message: '"Incorrect IP address"'
                result: $rlm.NOTFOUND

            # Профиль абонентского оборудования подобрался и есть доступ к сети Интернет
            - condition: $customer_profile.attributes.try("Internet-Service-Status") == "SERV_STATE_Provision"
              template:
                RAD_CHECK:
                  <<: *default_rad_check
                RAD_REPLY: &ok_rad_reply
                  Cisco-AVPair: '"subscriber:accounting-list=HYDRA-IPOE"'
                  Acct-Interim-Interval: '"300"'
                  Idle-Timeout: '"86400"'
                  # Атрибут профиля с сервисами ISG преобразуем в список, разбивая наименования сервисов по запятой
                  Cisco-Account-Info: $customer_profile.attributes.ISG-Services.split(",")
                result: $rlm.OK

            # В остальных случаях профиль абонентского оборудования подобрался,
            # но у абонента имеется задолженность - выдаём сервисы для ограничения доступа
            - template:
                RAD_CHECK:
                  <<: *default_rad_check
                RAD_REPLY:
                  <<: *ok_rad_reply
                  Session-Timeout: '"3600"'
                  Cisco-Account-Info:
                    - '"IPOE-SC-REDIRECT"'
                    - '"IPOE-SC-OPENGARDEN"'
                result: $rlm.OK

        # Действие authenticate в данном случае ничем не отличается от authorize
        # Поэтому используем YAML-ссылки, чтобы не дублировать настройки
        authenticate:
          customer_profile:
            <<: *customer_profile
          provider_profile: {}
          reply: *auth_reply

        accounting:
          # Подбор профиля абонентского оборудования выполняем также, как и в authorize - указываем YAML-ссылку
          customer_profile:
            <<: *customer_profile

          # Операторское оборудование в данной схеме не используется - не подбираем профиль
          provider_profile: {}

          session:
            # Шаблоны сессий, формируемых в результате обработки пакетов аккаунтинга
            templates:
              # Гостевые сессии, для которых нет подходящего профиля абонентского оборудования
              - condition: $customer_profile.null?() and $session.customer_profile_id.empty?()
                # Фиксируем только основные атрибуты сессии
                attributes: &basic_session_attributes
                  User-Name: $request.RAD_REQUEST.User-Name
                  NAS-IP-Address: $request.RAD_REQUEST.NAS-IP-Address
                  NAS-Port-Id: $request.RAD_REQUEST.NAS-Port-Id

                # Такие сессии загружать в провижининг не нужно - оставляем в кэше
                load_to_hydra: false

              # Базовая сессия зарегистрированного абонента
              - condition: $context.has_tag?("base-session-accounting")
                attributes: &session_attributes
                  <<: *basic_session_attributes
                  # Помимо основных атрибутов сохраняем сведения о сервисах
                  Cisco-AVPair: $request.RAD_REQUEST.Cisco-AVPair
                  Cisco-Service-Info: $request.RAD_REQUEST.try("Cisco-Service-Info")

              # Сервисная сессия доступа к сети Интернет
              - condition: $request.RAD_REQUEST.Cisco-Service-Info.like?("^NIPOE-SC-(INET|NIGHT)-.+$")
                attributes:
                  # Атрибуты сохраняем те же, что и для базовой сессии
                  <<: *session_attributes
 
                # По такой сессии необходимо учитывать потреблённый абонентом трафик
                services:
                  # Услуга «Интернет-трафик исх.» с идентификатором 40213501
                  - service_id: 40213501
                    value: '      $request.RAD_REQUEST.try("Acct-Input-Octets", "0").to_i()
                            + 4 * $request.RAD_REQUEST.try("Acct-Input-Gigawords", "0").to_i().gigabytes()'
                    unit: bytes
                  # Услуга «Интернет-трафик вх.» с идентификатором 40213701
                  - service_id: 40213701
                    value: '      $request.RAD_REQUEST.try("Acct-Output-Octets", "0").to_i()
                            + 4 * $request.RAD_REQUEST.try("Acct-Output-Gigawords", "0").to_i().gigabytes()'
                    unit: bytes

                # Поскольку это сервисная сессия, дополнительно указываем идентификатор
                # соответствующего ей дочернего шаблона профилей абонентского оборудования
                service_profile:
                  # Шаблон профилей «IPoE - Доступ к сети Интернет»
                  template_id: 540101

              # Все остальные сервисные сессии, по которым приходит аккаунтинг,
              # считаем доступом к локальным ресурсам - трафик не учитываем, но атрибуты сохраняем
              - attributes:
                  # Атрибуты сохраняем те же, что и для базовой сессии
                  <<: *session_attributes

                # Поскольку это сервисная сессия, дополнительно указываем идентификатор
                # соответствующего ей дочернего шаблона профилей абонентского оборудования
                service_profile:
                  # Шаблон профилей «IPoE - Доступ к локальным ресурсам»
                  template_id: 540301

Загрузчик данных аккаунтинга

В конфигурацию планировщика CRON добавляем настройки для регулярного запуска агента в режиме загрузки данных аккаунтинга в БД провижининга:

# HARD RADIUS accounting loader
*/3 *   * * *   hard    /opt/hydra/hard/init/hard.sh -f /etc/hydra/hard batch &>/dev/null

Настройка сервера FreeRADIUS

Установку и настройку сервера FreeRADIUS выполняем в соответствии со статьёй Установка и настройка сервера FreeRADIUS. Если FreeRADIUS уже установлен, настраиваем отдельный экземпляр, руководствуясь статьёй Создание дополнительного экземпляра сервера FreeRADIUS. В модуле hard.pm (файл /etc/freeradius/hard.pm) указываем следующие параметры взаимодействия с агентом HARD:

# Параметры для связи с HARD
my @HARD_API_URLS = (                                     # Пул API URL для запросов
  "http://127.0.0.1:11080/base/ipoe-isg"
);

use constant HARD_AUTH_USER     => "freeradius";          # Логин
use constant HARD_AUTH_PASSWORD => "freeradius_password"; # Пароль

Пароль в константе HARD_AUTH_PASSWORD укажите тот же, что задан в ключе filters → agent.basic_auth → main → password конфигурации агента HARD.

Настройка агента HEX

Установку агента выполняем в соответствии со статьёй Настройка агента HEX. Конфигурационный файл приводим в соответствие с примером:

log:
  default:
    # Уровень логирования
    level: 'debug'
 
activemq:
  # Хост и порт для подключения к ActiveMQ по протоколу OpenWire
  url: 'tcp://127.0.0.1:61616'
 
hydra:
  # Карта соответствия очередей команд и результатов их выполнения
  command_queues:
    # <Очередь для приёма команд>: <Очередь для отправки результата>
    - 'hydra_commands_1': 'hydra_command_results_1'

Добавляем на сервер указанный ранее в шаблонах команд скрипт /usr/local/hydra-scripts/isg_session_control.sh для принудительного завершения базовой сессии и управления активированными в рамках неё сервисами.

Агент HEX работает под пользователем hex (hex-testing для тестового экземпляра) — данному пользователю выдаём права на исполнение добавленного скрипта.

Результат

Настроенная схема обеспечивает идентификацию абонентского устройства по IP-адресу, который привязан в Гидре к соответствующему Оконечному оборудованию (к компоненту). Если идентификация прошла успешно (профиль абонентского оборудования подобран), то выполняется авторизация: в зависимости от состояния услуг либо выдаются соответствующие тарифному плану сервисы, либо сервисы блокировки и переадресации на страницу оплаты услуг. Соответствие тарифных планов и сервисов ISG хранится в Гидре. Для сервисов доступа к сети Интернет агент HARD обеспечивает динамическое конфигурирование.

Команды формируются провижинингом по каждой базовой сессии отдельно:

• При изменении набора доступных в рамках тарифного плана сервисов или состояния оказания услуг формируется команда на изменение по базовой сессии.
• При изменении привязанного к абонентскому оборудованию IP-адреса или прекращении оказания услуг — команда на прерывание базовой сессии.