В данном примере MikroTik выступает в роли DHCP-сервера, шейпера и файерволла. Поддержка IPoE-сессий у RouterOS отсутствует, поэтому пакетов RADIUS-аккаунтинга сервер доступа не отправляет, только запросы авторизации. Сбор данных о потреблённом абонентом трафике при такой схеме доступа можно выполнять, например, через агрегацию NetFlow. |
В разделе Справочники → Теги добавляем новые записи:
В разделе Справочники → Номенклатура, в группе Все → ТМЦ → Активное оборудование → Коммутатор добавляем позицию для коммутатора доступа:
Заполняем раздел Спецификация:
С помощью кнопки Добавить в разделе Оборудование → Активное оборудование создаём коммутатор доступа, к портам которого будет привязываться абонентское оборудование. На форме создания активного оборудования:
В разделе Оборудование → Шаблоны профилей (необходимо право Провижининг → Редактирование шаблонов профилей) переходим на вкладку Операторское оборудование и создаём новый шаблон:
Наполняем шаблон атрибутами с помощью кнопки Добавить на форме его редактирования:
Подстановка | Наименование | Параметры |
---|---|---|
Оборудование | Switch-Port-Number |
|
Адрес основного оборудования | Switch-IP-Address |
|
|
Меняем состояние шаблона на Активен и нажимаем Сохранить, после чего переформировываем профили по новому шаблону.
Открываем вкладку Профили операторского оборудования и убеждаемся, что профили сформировались корректно. Периоды действия профилей определяются периодами действия участвующих в них привязок адресов к оборудованию, поэтому в данном случае у каждого компонента должно быть два профиля:
Маркируем в разделе Справочники → Номенклатура тегом интернет-тариф все пакеты услуг, оказываемые с использованием MikroTik IPoE:
В разделе Оборудование → Шаблоны профилей (необходимо право Провижининг → Редактирование шаблонов профилей) создаём новый шаблон:
Наполняем шаблон атрибутами с помощью кнопки Добавить на форме его редактирования:
Подстановка | Наименование | Параметры |
---|---|---|
Адрес компонента оборудования | IP-Address |
|
Состояние услуги | Service-Status |
|
Дочерняя строка приказа по ценам | Speed-Download-kbps |
|
Дочерняя строка приказа по ценам | Speed-Upload-kbps |
|
|
Абонентское оборудование (Оконечное оборудование) должно быть привязано к операторскому (порт коммутатора). При обработке DHCP-запроса будет подбираться профиль операторского оборудования по данным опции 82, а из него будет извлекаться привязанный профиль абонентского оборудования. |
Меняем состояние шаблона на Активен и нажимаем Сохранить, после чего переформировываем профили по новому шаблону.
Открываем вкладку Профили абонентского оборудования, подписанного на промаркированный тегом интернет-тариф пакет услуг, и убеждаемся, что профили сформировались корректно. Периоды действия профилей определяются периодами действия участвующих в них привязок адресов к оборудованию, поэтому в данном случае у каждого оборудования с одним привязанным IP-адресом должно быть два профиля:
В разделе Оборудование → Шаблоны конфигураций создаём новый шаблон:
В разделе Команды вводим шаблоны команд для управления доступом абонента к сети Интернет через MikroTik:
/usr/local/hydra-scripts/mikrotik_control.py --action=activate --ip-address={NEXT.IP-Address} --next-down-speed-kbps={NEXT.Speed-Download-kbps} --next-up-speed-kbps={NEXT.Speed-Upload-kbps} --next-serv-status={NEXT.Service-Status} |
/usr/local/hydra-scripts/mikrotik_control.py --action=drop --ip-address={PREV.IP-Address} --prev-down-speed-kbps={PREV.Speed-Download-kbps} --prev-up-speed-kbps={PREV.Speed-Upload-kbps} --prev-serv-status={PREV.Service-Status} |
/usr/local/hydra-scripts/mikrotik_control.py --action=change --ip-address={NEXT.IP-Address} --prev-down-speed-kbps={PREV.Speed-Download-kbps} --next-down-speed-kbps={NEXT.Speed-Download-kbps} --prev-up-speed-kbps={PREV.Speed-Upload-kbps} --next-up-speed-kbps={NEXT.Speed-Upload-kbps} --prev-serv-status={PREV.Service-Status} --next-serv-status={NEXT.Service-Status} |
Если необходимо в отдельных случаях дополнительно управлять коммутатором доступа, например включать и отключать абонентский порт, в данные шаблоны команд можно добавить подстановки с атрибутами |
На вкладке Привязки формы редактирования абонентского оборудования добавляем прямую привязку к нужному порту коммутатора:
В результате создания привязки при наличии активных профилей абонентского и операторского оборудования автоматически создаётся конфигурация по настроенному ранее шаблону. Проверяем её на вкладке Конфигурации формы редактирования оборудования:
Установку и настройку производим в соответствии со статьёй Настройка брокера ActiveMQ.
Установку агента выполняем в соответствии со статьёй Установка агента HARD.
Редактируем общий конфигурационный файл агента в соответствии с примером:
# Список активных плагинов enabled_plugins: - 'base/mikrotik-ipoe-option82' # Логирование log: # Общий лог агента common: # Уровень логирования: debug для отладки, info для эксплуатации level: 'debug' # Системные фильтры filters: # Базовая HTTP-аутентификация клиента (hard.pm / hard-dhcp.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
.connection_pools
→ database
→ main
→ hydra
→ password
.syncer
→ stomp
→ password
.В MongoDB добавляем базу данных hard_cache
и пользователя hard
для неё в соответствии с описанным в статье Настройка агента HARD примером.
base
Добавляем конфигурационный файл экземпляра mikrotik-ipoe-option82
плагина base
агента HARD в соответствии с примером:
plugins: base: mikrotik-ipoe-option82: actions: authorize: # Для идентификации абонентского оборудования сначала подбираем профиль операторского оборудования provider_profile: &get_provider_profile # Профиль операторского оборудования нужно искать в БД кэша set_by: search_cache query: # В подопции Remote Id запроса приходит IP-адрес коммутатора, в формате ASCII-HEX. # Пример преобразования: 0x495031302e31382e33322e31 → IP10.18.32.1 → 10.18.32.1 Switch-IP-Address: $request.RAD_REQUEST.DHCP-Relay-Remote-Id.unhex().substring(2) # В подопции Circuit Id, в последних двух байтах, запроса приходит номер порта # Примеры преобразований: 0x000402d7010c → 0c → 12; 0x000402d70105 → 05 → 5 Switch-Port-Number: $request.RAD_REQUEST.DHCP-Relay-Circuit-Id.substring(-2).to_i(16) # Для авторизации получаем профиль абонентского оборудования customer_profile: &get_customer_profile # Профиль абонентского оборудования привязан к профилю операторского set_by: set_first_from_provider_profile # В данном примере активный профиль абонентского оборудования может быть только один, # поэтому дополнительной фильтрации не требуется filter: {} reply: &auth_reply # Профиль абонентского оборудования подобрался и услуга оказывается - condition: ' $customer_profile.present?() and $customer_profile.attributes.Service-Status == "SERV_STATE_Provision"' template: RAD_CHECK: &auth_rad_check # Сохраняем для FreeRADIUS все исходные атрибуты RAD_CHECK '*': $request.RAD_CHECK # В качестве правильного пароля для FreeRADIUS подставляем тот, что пришёл в запросе Cleartext-Password: $request.RAD_REQUEST.User-Password RAD_REPLY: ®istered_customer_auth_reply # IP-адрес, который MiktoTik должен выдать устройству Framed-IP-Address: $customer_profile.attributes.Framed-IP-Address # Наименование списка адресов, в который MiktoTik должен поместить выдаваемый IP-адрес # Списки адресов настроены на MiktoTik и используются для ограничения скорости доступа: # Например список alist_active_speed_limit_5120k_down_5120k_up - симметричное ограничение 5 Мбит/с Mikrotik-Address-List: ' "alist_active_speed_limit_" + $customer_profile.attributes.Speed-Download-kbps + "k_down" + $customer_profile.attributes.Speed-Upload-kbps + "k_up"' # Время, по истечении которого MiktoTik повторно запросит авторизацию для абонентского устройства Session-Timeout: '"86400"' result: $rlm.OK # Профиль абонентского оборудования подобрался, но услуга не оказывается - condition: $customer_profile.present?() template: # RAD_CHECK формируем так же, как и для полноценного доступа RAD_CHECK: *auth_rad_check RAD_REPLY: << : *registered_customer_auth_reply # Для заблокированных абонентов отдаём особый Address-List и короткое время аренды Mikrotik-Address-List: '"alist_blocked"' Session-Timeout: '"600"' result: $rlm.OK # Профиль абонентского оборудования не подобрался - отказ - template: RAD_CHECK: # Сохраняем для FreeRADIUS все исходные атрибуты RAD_CHECK '*': $request.RAD_CHECK RAD_REPLY: {} result: $rlm.NOTFOUND # Подбор профилей оборудования и формирование ответа выполняется так же, как и в действии authorize authenticate: provider_profile: *get_provider_profile customer_profile: *get_customer_profile reply: *auth_reply # Действие accounting не используется: MikroTik не поддерживает IPoE-сессии и не присылает RADIUS-аккаунтинг accounting: {} |
Установку и настройку сервера FreeRADIUS выполняем в соответствии со статьёй Установка и настройка сервера FreeRADIUS. В модуле hard.pm
(файл /etc/freeradius/hard.pm
) указываем следующие параметры взаимодействия с агентом HARD:
# Параметры для связи с HARD my @HARD_API_URLS = ( # Пул API URL для запросов "http://127.0.0.1:11080/base/mikrotik-ipoe-option82" ); use constant HARD_AUTH_USER => "freeradius"; # Логин use constant HARD_AUTH_PASSWORD => "freeradius_password"; # Пароль |
Пароль в константе HARD_AUTH_PASSWORD
укажите тот же, что задан в ключе filters
→ agent.basic_auth
→ main
→ password
конфигурации агента HARD.
Установку агента выполняем в соответствии со статьёй Настройка агента 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/mikrotik_control.py
для управления сервером MikroTik. Данный скрипт может быть написан на любом языке (расширение .py
указано здесь только для примера) — важно только, чтобы он мог выполняться агентом HEX локально на сервере. Агент HEX работает под пользователем hex
(hex-testing
для тестового экземпляра) — данному пользователю выдаём права на исполнение добавленного скрипта.
Сервером MikroTik скрипт может управлять через API RouterOS или же через консоль, подключаясь к серверу по SSH с аутентификацией по DSA или RSA ключу. Во втором случае ключ должен быть настроен для пользователя В данной схеме изменения скорости доступа абонента к сети Интернет, а также блокировки и разблокировки, могут быть выполнены путём помещения IP-адресов абонентского оборудования в соответствующие адресные списки, использующиеся в конфигурации файерволла MikroTik. |
Данные DHCP-опции 82 формируются коммутаторами доступа, которые передают DHCP-запросы абонентских устройств на MikroTik, выступающий в роли DHCP-сервера. MikroTik при получении DHCP-запроса, если подходящая запись об аренде IP-адреса в его кэше отсутствует или просрочена, выполняет RADIUS-запрос к серверу Гидры. В качестве RADIUS-сервера используется FreeRADIUS с Perl-модулем hard.pm
, который передаёт полученный запрос на обработку агенту HARD. Агент выполняет идентификацию абонентского оборудования по полученной DHCP-опции 82 и авторизует его в соответствии с состоянием оказания услуг на данном оборудовании.
В ответе для активного абонента серверу MikroTik отправляется статический IP-адрес, максимальный срок DHCP-аренды и наименование адресного списка, в который сервер должен включить выдаваемый IP. Наименование назначаемого адресного списка для активных абонентов формируется агентом динамически в соответствии с указанными в приказах по ценам Гидры значениями скорости трафика. Адресные списки определяются заранее в конфигурации сервера MikroTik и используются им для ограничения скорости доступа абонента к сети Интернет.
Если услуга абоненту не оказывается в связи с временной блокировкой или из-за нехватки средств, то в ответе серверу MikroTik отправляется IP-адрес и специальный адресный список alist_blocked
, для которого в MikroTik настроена переадресация HTTP-запросов абонента на страницу с информацией о блокировке.
При регистрации нового абонента, изменении состояния оказания услуги или ограничений скорости доступа (например, при превышении порога трафика для «турбобезлимитного» тарифа), а также при прекращении действия подписки на услугу по конфигурации провижинингом формируются команды для изменения параметров доступа абонентского IP-адреса: удаления записи о DHCP-аренде, перемещении IP-адреса в другой адресный список и т. д.