Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

Начиная с версии 4.0.1419 в комплекте поставки ПО биллинга NETAMS идет встроенный сервер DHCP. Он позволяет динамически назначать IP-адреса абонентам системы биллнга, пользуясь единой базой зарегистрированных учетных объектов, а также осуществлять контроль и привязку к MAC-адресам сетевых карт абонентов. Такой подход позволяет избежать двойной настройки параметров абонентов из-за необходимости прописывания чего-либо в файле конфигурации стороннего DHCP-сервера.

В настоящий момент сервер выпущен в режиме бета-версии. Абсолютно стабильная его работа не гарантируется; за поддержкой просьба обращаться на форум.

Сервер реализован в виде компонента процесса биллинга (т.е. это не отдельно запускаемое приложение, как RADIUS-сервер). Что такое DHCP-сервер, его принципы работы, описано тут. Если вы не знаете, зачем нужен этот сервер, скорее всего настраивать его вам не нужно. Все параметры сервера DHCP сосредоточены в меню "Система-Сервер DHCP":



 
Настройки разделены на общие, и параметры индивидуального пула адресов.
 
В общих параметрах настраиваются:

  • Активность сервера - работает ли вся служба выдачи адресов, или нет.
  • Поддержка DHCP опции 82 (пока не реализована в полной мере; если вы знаете, что это такое, и реально хотите использовать - обращайтесь на форум - добавим бесплатно).
  • Адрес сервера - вы должны указать IP-адрес вашего сервера, который будет проставляться в пакетах-ответах DHCP-клиенту и использоваться им в дальшейшем для перевыдачи (renew) адресов.
  • Длительность назначения (в секундах). По умолчанию - 7 суток, или 604800 секунд.
  • Разрешенные релеи - перечисление IP-адресов или подсетей, в которых находятся DHCP-релеи (DHCP relay agent). Может быть "все адреса" 0.0.0.0/0, или вообще не указано.

Также отображается статистика по количеству запросов, и выданных адресов.
Изменив настройки, необходимо сохранить их, нажав кнопку "Принять". Перезапуска сервера, или системы биллинга, не требуется.
 
Индивидуальные пулы адресов отвечают за конкретные параметы подсети и информацию, выдаваемую DHCP-клиенту. Наш DHCP-сервер способен поддерживать от одного до нескольких (сотни) отдельных пулов (диапазонов с индивидуальными настройками) адресов; таким образом вы сможете выдавать IP-адреса клиентам вашей сети, даже если она разделена на сегменты (VLAN). Добавить новый пул адресов можно, нажав на кнопку "Добавить" вверху окна. Редактировать пул впоследствии - просто нажав мышью на строку в таблице.

Возможные параметры пула адресов перечислены в таблице:

Параметр

Значение

ID

Автоматически присваиваемый идентификатор объекта

Активен

Активен или нет данный пул адресов в настоящий момент

Наименование

Имя пула - для вашего удобства, например "подсеть 6го этажа".

Адрес начала диапазона

IP-адрес начала диапазона выдаваемых адресов

Адрес конца диапазона

IP-адрес конца диапазона выдаваемых адресов

Исключенные адреса

Исключенные из диапазона адреса, например адрес самого сервера, шлюза по умолчанию, или адрес иных устройств в сети, которые попадают в диапазон, но присвоены статически

Политика назначения

Политика назначения и привязки адресов - None, MAC, MAC_IP, Option82 - смотри далее

Группа контрактов

Группа контрактов для политик MAC, MAC_IP, Option82 - смотри далее

Использовать для RADIUS

Использовать данный пул адресов для назначения динамических адресов при RADIUS-авторизации (встроенным сервером) - пока не используется

Разрешенные релеи

Список IP-адресов разрешенных DHCP relay agents, которые могут передавать запросы клиентов на сервер для использования данного пула - смотри далее

Шлюз по умолчанию

IP-адрес шлюза по умолчанию для клиентов

Маска сети

Сетевая маска для клиентов

Сервера DNS (3 штуки)

IP-адреса серверов DNS. Можно указать от одного до трех адресов (как минимум один адрес должен быть указан)

Имя домена

Имя домена, передаваемое клиенту

Сервера WINS (2 штуки)

IP-адреса серверов WINS. Можно указать ноль, один или два адреса


Вам также необходимо настроить релей-агента. Это посредник между DHCP-сервером, и локальной Ethernet-подсетью, в которой находятся клиенты DHCP, рассылающие широковещательные DHCP-запросы. Такой метод позволяет иметь один настроенный DHCP-сервер с назначенными пулами адресов, по одному на каждую подсеть/VLAN, и любое количество подсетей с релей-агентами в каждой, передающие запросы клиентов на сервер. Такие подсети с клиентами могут находиться где угодно в вашей сети, хоть в другом городе.

Для примера, на маршрутизаторе или коммутаторе Cisco необходимо прописать:

Code Block
int Gi0/0
ip address 172.16.10.1 255.255.255.0
ip helper-address  172.16.100.5

При этом для подсети с клиентами, подключенной к данному интерфейсу (или VLAN) все DHCP-запросы будут передаваться на сервер биллинга, который работает на IP-адресе 172.16.100.5. В качестве адреса релея (relay agent) для данного пула адресов подсети 172.16.10.0/24 необходимо будет указать 172.16.10.1.
Для маршрутизаторов и коммутаторов других производителей существуют аналогичные команды. Для операционных систем Linux, FreeBSD вам придется скачать и установить небольшую утилиту dhcrelay (документация).

Вы можете иметь релей-агента и сервер биллинга-DHCP в одной подсети - в таком случае DHCP-сервер проигнорирует широковещательный запрос от клиента, и ответит на переданный релей-агентом (в той же сети) запрос.

Вопрос: зачем мне нужны какие-то релеи? Я хочу просто использовать ваш DHCP-сервер в биллинге на своем Линукс-сервере, в локалке.
Ответ: работа DHCP-сервера для обслуживания клиентов локальной сети связана с передачей "сырых" сформированных Ethernet-пакетов клиенту, с указанным MAC-адресом клиента, и IP-адресом, выставленным в 255.255.255.255. Поскольку наш сервер написан на Java, такой функционал реализовать штатными средствами просто невозможно. Для работы DHCP-сервера необходимо либо работать с сетевым интерфейсом напрямую (через libpcap, что возможно будет нами когда-то реализовано), либо обслуживать клиентов через relay agent, обмен с которым идет через Unicast-пакеты - как реализовано у нас сейчас.

Если  клиент запрашивает ранее выданный ему же арес (проверка идет по его IP- и МАС-адресу, тот же самый адрес переназначается клиенту автоматически без дополнительных проверок).

Политика назначения IP-адресов устроена следующим способом. 

В простейшем случае (None) назначение адресов производится по принципу "кто первый встал, того и тапки". При поступлении запроса от DHCP-клиента проверяется соответствие IP-адреса релей-агента разрешенному адресу из списка глобальных адресов релея, а так же релея данного пула адресов. Перебираются все доступные активные пулы адресов по порядку до тех пор, пока адрес релея не совпадет с разрешенным в настройках пула (напомним, там можно укзать несколько адресов или подсетей (/маска) с разделителем "пробел").

Если пул найден и активен, выдается первый неиспользованный и неисключенный адрес из пула. Сервер DHCP ведет протокол выданных адресов (в XML-файле jserver/db/dhcp@ROOT.xml). Если свободных адресов нет, клиент получает отказ. Никакого контроля абонента в данном случае не производится - любой клиент получает адрес.

При использовании политики MAC производится проверка наличия МАС-адреса абонента в списке учетных объектов системы биллинга. Для этого в качестве возможного параметра учетного объекта, наряду с IP-адресом, добавлен МАС-адрес (в формате хх:хх:хх:хх:хх:хх). При поступлении запроса от клиента проверяется наличие пула, правильность релея, наличие MAC-адреса в конфигурации биллинга. Если ни одного учетного объекта с указанным MAC-адресом не найдено, клиент получает отказ. Если учетный объект найден, то при включеном и выбраном параметре "группа контрактов" производится дополнительная проверка соответствия учетного объекта-контракта-группы, и отказ при несоответствии. Дальнейшие действия службы DHCP зависят от настроек парамера "разрешить динамический IP" и указанного текущего IP-адреса "совпавшего" учетного объекта. Если динамический IP-адрес разрешен, происходит попытка выдачи первого свободного IP-адреса из пула адресов. Отказ может возникнуть, если свободных адресов нет. При положительной выдаче адреса он также прописывается в настройках учетного обекта (для целей учёта). Если флаг разрешения динамического адреса не указан, то: если IP-адрес установлен в 0.0.0.0, происходит отказ, а если в какое-то другое значение, что этот адрес проверяется на доступность и свободность в пуле. Только если он свободен и не выдан никому, указанный фиксированный адрес предлагается данному клиенту. Таким образом, при использовании политики МАС можно организовать выдачу динамических (разных) адресов клиентам, заранее зарегистрированным в биллинге.

При использовании политики IP_MAC происходит жесткая привязка IP и MAC адресов согласно настройкам учетных объектов. В целом логика работы такая же, как в случае политики MAC, только независимо от параметра разрешения динамического адреса адреса будет выдан (если свободен) тот адрес, который указан в свойствах учетного объекта, или произойдет отказ, если адрес там не указан (т.е. равен 0.0.0.0). При использовании данной политики можно организовать выдачу статических адресов по заранее заданной связке IP-MAC без необходимости настраивать внешний DHCP-сервер с привязкой адресов.

Политика Option82 потенциально позволяет использовать для контроля валидности абонентов другие параметры, такие как индекс порта коммутатора, его имя и прочее. Если вы понимаете, о чем речь, и вам это действительно нужно, обращайтесь на форум или support@netams.com

Используя кнопку "Назначения" в строке с описанием пула адресов можно просмотреть список назначенных адресов в данном пуле, а также вручную удалить ранее назначенный адрес (у клиента он, естественно, сохранится до очередной проверки), а также очистить весь пул адресов: