Сценарии использования 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, содержащий путь к скрипту управления оборудованием. Как было упомянуто выше, в данном сценарии управление доступом будет осуществляться путем добавления/удаления правил брандмауэра IPtables. Простейший пример скрипта можно посмотреть по ссылке. Загруженный скрипт необходимо скопировать в директорию /usr/local/billing на сервер с агентом LBucd и не забыть сделать скрипт исполняемым (chmod +x /usr/local/billing/handler_ucd). Предполагается, что LANBilling работает на отдельном сервере, поэтому перед выполнением команды внутри скрипта осуществляется SSH-соединение к маршрутизатору (для работы данного функционала необходимо предварительно настроить авторизацию по ключам).

4. Перезапустить агент LBucd.

5. Перезапустить агент LBinet.

6. Повторить шаг 5 из раздела по базовой настройке агента LBinet для созданного агента с типом Netflow. В дальнейшем новые IP-сети достаточно создавать только для агента с типом Netflow, изменения будут автоматически реплицироваться в соответствующий ему агент с типом RADIUS.

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

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

9. ОБЯЗАТЕЛЬНОЕ УСЛОВИЕ для данного сценария! В форме редактирования параметров учетной записи на вкладке «Настройка сети» необходимо осуществить привязку статического IP-адреса к учетной записи. В противном случае функционал учета потребленного трафика работать не будет (весь трафик будет не идентифицированным).

Аналогично предыдущему сценарию информацию об активной сессии можно посмотреть в форме "Отчеты" - "Активные сессии". Информация о потребленном трафике отображается в форме "Отчеты" - "Статистика".

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

Данный сценарий, как показала практика, является наиболее популярным среди операторов связи. Реализация достаточно подробно описана в статье "LANBilling и Dynamic CLIPS". Ознакомиться можно по ссылке.

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

Данный сценарий является наиболее сложным с точки зрения LANBilling и, по сути, является сложением сценариев 2 и 3. Как правило подходит операторам связи для реализации достаточно специфических сервисных моделей.

На стороне LANBilling функционируют агент LBinet (DHCP), осуществляющий выдачу IP-адресов, агент LBarcd(RADIUS), выполняющий функции авторизации, и кабельный агент (Netflow/Sflow), осуществляющий сбор статистики о потребленном трафике. На стороне транспортной сети обычно имеется достаточно продвинутый маршрутизатор (BNG), имеющий возможность инициировать запросы авторизации к RADIUS на событийной основе. Помимо авторизации маршрутизатор так же выполняет функции экспорта (в нашем примере - средствами Netflow) статистики о потребленном трафике. Запуск скриптов управления оборудованием осуществляет агент LBarcd (RADIUS). Схема взаимодействия отражена на Рис. 6.

Рисунок 6

Краткое описание рабочего процесса:

•  абонентское оборудование получает IP-адрес от DHCP-сервера с использованием DHCP option82;
•  по событию получения первого IP-пакета от абонентского оборудования маршрутизатор инициирует запрос авторизации к RADIUS, включая в него ранее выданный абоненту IP-адрес (атрибут Framed-IP-Address или Assigned-IP-Address);
•  если RADIUS находит учетную запись, которой привязан пришедший в запросе авторизации IP-адрес, маршрутизатору возвращается одобрение авторизации в виде Access-Accept;
•  по событию получения Access-Accept маршрутизатор разрешает форвардинг трафика между абонентом и сетью Интернет;
•  информация о потребленном трафике доставляется кабельному агенту LANBilling, выполняющему функции Netflow-коллектора.

Для реализации данного сценария требуется:

1. Выполнить все шаги, описанные в разделе по базовой настройке агента LBinet.

2. Выполнить шаги 1-2, 4-9, описанные в сценарии 2.

3. В таблицу agent_options необходимо добавить следующие опции:

- для ранних версий системы, начиная с 2.0-017 и выше достаточно в форме редактирования агента с типом RADIUS изменить значение параметра "Включить DHCP-сервер", выбрав из списка "LBinet" и добавить опцию:

insert into agent_options set id='ID агента с типом RADIUS', name='radius_auth_method', value='ip';

- для более ранних версий системы необходимо добавить три опции:

insert into agent_options set id='ID агента с типом RADIUS', name='radius-uses-lbinet', value=1;
insert into agent_options set id='ID агента с типом RADIUS', name='enable-dhcp-request', value=0;
insert into agent_options set id='ID агента с типом RADIUS', name='radius_auth_method', value='ip';
	

4. Произвести установку и настройку агента LBarcd согласно документации: пункт "Агент RADIUS (LBarcd)". Не забыть в файле конфигурации агента LBarcd (/etc/billing.conf.LBarcd) задать значение параметра «sysid» как ID ранее созданного (в разделе по базовой настройке LBinet) агента с типом RADIUS.

5. В конфигурационный файл агента LBarcd (/etc/billing.conf.LBarcd) добавить параметр: handler = /usr/local/billing/handler_arcd , содержащий путь к скрипту управления оборудованием. Пример скрипта для маршрутизатора Ericsson SE можно посмотреть по ссылке. Загруженный скрипт необходимо скопировать в директорию /usr/local/billing на сервер с агентом LBarcd и не забыть сделать скрипт исполняемым (chmod +x /usr/local/billing/handler_arcd).

6. Создать серверы доступа в разделе «Серверы доступа» экранной формы настройки агента с типом RADIUS.

7. Запустить/перезапустить агент LBarcd.

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

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

10. ОБЯЗАТЕЛЬНОЕ УСЛОВИЕ для данного сценария! В форме редактирования параметров учетной записи на вкладке «Настройка сети» необходимо осуществить привязку статического IP-адреса к учетной записи. В противном случае не будет работать функционал учета потребленного трафика (весь трафик будет не идентифицированным) и функционал авторизации.

С уважением,
Руководитель Департамента внедрений ООО "Сетевые Решения",
Разживин Виталий