Сценарии использования DHCP-сервера LBinet

Введение

LANBilling, содержит в своем составе модуль LBinet, выполняющий функции DHCP-сервера. Модуль позволяет производить идентификацию абонента либо с использованием DHCP option82, либо с помощью MAC-адреса клиентского устройства и осуществлять выдачу IP-адреса (динамического или зафиксированного за абонентом) из пула IP-адресов. В документации достаточно подробно освещены эти и другие возможности агента. Однако в документации не затрагиваются аспекты совместной работы агента с другими компонентами LANBilling такими, как RADIUS-агент или кабельный агент. Возникает множество вопросов, ведь операторам связи зачастую требуется не только функционал выдачи IP-адресов, но и функционал подсчета потребленного трафика, функционал авторизации.

В данной статье попытаемся устранить обозначенный выше пробел и показать сценарии использования агента LBinet в совокупности с другими компонентами LANBilling на примере реальных сервисных моделей предоставления абонентам доступа в сеть Интернет.

С целью унификации, во всех сценариях абоненты будут идентифицироваться агентом LBinet с использованием DHCP option82. Имплементацию option82 в DHCP-запрос будет выполнять Ethernet-коммутатор доступа, в порт которого подключен абонент.

Базовая настройка LANBilling

Предполагается, что была выполнена установка и базовая настройка LANBilling. В противном случае необходимо обратиться к нашей документации, подробно описывающей данные процессы, а так же общую архитектуру системы: Документация.

Базовая настройка агента LBinet

В дополнение к документации, в виде тезисов опишем основные шаги по настройке агента, являющиеся общими для всех рассматриваемых в данной статье сценариев (все действия выполняются в административном WEB-интерфейсе LANBilling):

1. Создать фиктивный агент с типом RADIUS и задать в файле конфигурации агента LBinet (/etc/billing.conf.LBinet) значение параметра "agent_id" как ID созданного агента.

2. Задать рабочие параметры DHCP сервера в форме настройки агента с типом RADIUS (Рис. 1) в секции "DHCP-сервер". Остальные параметры — по умолчанию. Сохранить.

3. Запустить агент LBinet.

4. В разделе "Объекты" - "Inventory" - "Операторское оборудование" - "Редактирование" создать группу устройств. Группа устройств как правило соответствует одному L3-сегменту сети.

5. В экранной форме настройки агента с типом RADIUS в разделе "Управление сетями" создать IP-сеть (флаг "Гость" не установлен, NAS — Все) и привязать её к группе устройств, созданной в пункте 4. Связка IP-сети и группы устройств служит для описания в LANBilling L3-сегмента сети. В дальнейшем оборудование (коммутатор) доступа может быть сопоставлено нужному L3-сегменту путем его добавления в заранее определенную группу устройств.

6. В разделе "Объекты" - "Inventory" - "Операторское оборудование" - "Редактирование" добавить устройство, соответствующее коммутатору доступа.

7. В форме редактирования параметров устройства задать значение опции "Agent-Remote-Id" для устройства, создать необходимое количество портов, включить устройство в нужную группу.

Рисунок 1

Сценарий 1: В сети оператора требуется только выдача IP-адресов средствами протокола DHCP без авторизации, подсчета трафика и управления оборудованием.

На практике — самый редко встречаемый сценарий. На стороне LANBilling функционирует только агент LBinet (DHCP). Схема взаимодействия отражена на Рисунке 2.

Рисунок 2

После выполнения всех шагов, описанных в разделе по базовой настройке агента LBinet, агент готов к работе. В качестве финальных шагов необходимо:

1. Создать абонента и учетную запись на агенте с типом RADIUS.

2. В форме редактирования параметров учетной записи привязать учетную запись к порту оборудования (коммутатора) доступа.

В данном сценарии по команде от агента LBinet возможно создание записи в таблице активных сессий после успешного завершения транзакции выдачи IP-адреса. Информация об активной сессии отображается в форме "Отчеты" - "Активные сессии" (Рис. 3).

Рисунок 3

По событию устаревания dhcp-лизы запись из таблицы активных сессий будет автоматически удалена. Обязательным условием для работы данной логики является отсутствие записей в разделе "Серверы доступа" формы редактирования агента с типом RADIUS.

Сценарий 2: В сети оператора требуется выдача IP-адресов средствами протокола DHCP, подсчет трафика средствами протокола Netflow и включение/отключение абонентов на оборудовании. Авторизация абонентов не требуется.

Данный сценарий является более распространенным, чем сценарий 1. Как правило подходит организациям, предоставляющим доступ в сеть Интернет своим сотрудникам и операторам связи, в сервисных моделях которых отсутствует авторизация по протоколу RADIUS.

На стороне LANBilling функционируют агент LBinet (DHCP), осуществляющий выдачу IP-адресов и кабельный агент (Netflow/Sflow), осуществляющий сбор статистики о потребленном трафике. На стороне транспортной сети обычно имеется оборудование, контролирующее доступ абонентов в сеть Интернет и выполняющее функции экспорта статистики о потребленном трафике. В рассматриваемом нами примере оборудование представлено в виде Linux-маршрутизатора, контроль доступа осуществляется средствами брандмауэра IPtables, экспорт трафика осуществляется средствами протокола Netflow. Кабельный агент в данной схеме выполняет функции Netflow-коллектора, а так же по событиям блокировки/разблокировки учетной записи осуществляет запуск внешних скриптов для передачи соответствующих команд на оборудование. Схема взаимодействия отражена на Рис. 4.

Рисунок 4

После выполнения всех шагов, описанных в разделе по базовой настройке агента LBinet, необходимо:

1. Создать агент с типом Netflow и произвести его настройку согласно документации к LANBilling и запустить агент.

2. Изменить в форме настройки агента с типом RADIUS параметр «Управлять клиентами агента» путем выбора из выпадающего списка агента с типом Netflow (Рис. 5). Сохранить.

Рисунок 5

3. В конфигурационный файл агента LBucd (/etc/billing.conf.LBucd) добавить параметр: handler = /usr/local/billing/handler_ucd, содержащий путь к скрипту управления оборудованием. Как был