Года через два наткнулся на этот забытый скрипт. Раз уж он никому не нужен, то можно попытаться довести его до ума и поделиться им. Забрал скрипт домой и стал экспериментировать на виртуалках. Пока доводил скрипт до ума, на работе снова возникла необходимость поставить на контроль один DHCP-сервер, никак не связанный с теми, для которых скрипт первоначально писался.
Принципы работы DHCP
Для начала ознакомимся немого с принципами работы DHCP.Выдача настроек по DHCP происходит в следующей последовательности:
- клиент, желающий получить настройки, посылает широковещательный запрос DHCPDISCOVERY, при помощи которого пытается обнаружить доступные DHCP-серверы,
- сервер откликается на запрос DHCPDISCOVERY и отвечает пакетом DHCPOFFER, в котором предлагает клиенту использовать определённый IP-адрес,
- клиент отправляет серверу запрос DHCPREQUEST, в котором просит закрепить за ним указанный IP-адрес,
- сервер отвечает клиенту пакетом DHCPACK, в котором подтверждает, что IP-адрес закреплён за клиентом. Если сервер по каким-то причинам не может закрепить за клиентом указанный им IP-адрес, то отвечает пакетом DHCPNAK.
Также протоколом предусмотрены пакеты DHCPDECLINE и DHCPINFO.
При помощи DHCPDECLINE клиент может сообщить серверу, что предложенный им IP-адрес уже используется.
Если клиенту не нужен IP-адрес от DHCP-сервера, то вместо запроса DHCPREQUEST клиент может отправить запрос DHCPINFORM для запроса дополнительных сетевых параметров. Так же как и в ответ на запрос DHCPREQUEST, на запрос DHCPINFORM сервер отвечает пакетом DHCPACK.
Если клиент хочет вернуть IP-адрес DHCP-серверу, он может отправить серверу запрос DHCPRELEASE. Если сервер получит такой запрос, он помечает IP-адрес как свободный. Протоколом не предусмотрен ответ на запросы DHCPRELEASE, поэтому невозможно убедиться в том, что сервер получил и обработал запрос.
Описание скрипта dhcp.py
А теперь перейдём к делу. Для контроля работоспособности DHCP-сервера был подготовлен скрипт dhcp.py, принимающий следующие аргументы:- имя сетевого интерфейса, за которым находится контролируемый DHCP-сервер,
- MAC-адрес клиента, который будет использоваться в запросах к DHCP-серверу. По умолчанию - MAC-адрес сетевого интерфейса,
- IP-адрес, который ожидается получить от DHCP-сервера. По умолчанию клиент будет принимать любой IP-адрес,
- IP-адреса DHCP-серверов, ответ от которых ожидается получить. Если на пути между клиентом и DHCP-сервером имеются DHCP-релеи, то тут нужно указывать настоящие IP-адреса серверов, а не IP-адреса релеев. Можно указать несколько IP-адресов, разделив их двоеточиями. По умолчанию принимаются ответы от любых DHCP-серверов,
- время ожидания ответа, по умолчанию составляет 2 секунды.
Алгоритм работы скрипта следующий:
- через указанный интерфейс отправляется запрос DHCPDISCOVERY с указанным MAC-адресом или MAC-адресом интерфейса,
- в течение таймаута принимаются пакеты DHCPOFFER,
- если пакетов DHCPOFFER не поступило, выполнение скрипта прерывается,
- если указан ожидаемый IP-адрес, то проверяется, что в DHCPOFFER предложен именно этот IP-адрес. Если DHCP-сервер предложил другой IP-адрес, то выполнение скрипта прерывается,
- если указан список IP-адресов DHCP-серверов, то проверяется, что в DHCPOFFER указан IP-адрес одного из ожидаемых DHCP-серверов. Если получен ответ от другого DHCP-сервера, то выполнение скрипта прерывается,
- отправляется запрос DHCPREQUEST с просьбой выдать в аренду предложенный IP-адрес,
- в течение таймаута принимаются пакеты DHCPACK,
- если пакетов DHCPACK не поступило, выполнение скрипта прерывается,
- отправляется запрос DHCPRELEASE на возврат арендованного IP-адреса.
- указанный сетевой интерфейс не существует,
- неправильный MAC-адрес,
- нет ответа DHCPOFFER,
- неправильный пакет DHCPOFFER,
- получен ответ от нежелательного DHCP-сервера,
- предложен нежелательный IP-адрес,
- нет ответа DHCPACK,
- неправильный пакет DHCPACK.
Настройка Zabbix-агента
Сначала установим пакет sudo, если он ещё не установлен:# apt-get install sudoИ выдадим пользователю zabbix, от имени которого работает Zabbix-агент, права запускать скрипт dhcp.py с правами пользователя root:
Defaults:zabbix !requiretty zabbix ALL=(ALL) NOPASSWD:/etc/zabbix/dhcp.py *Теперь положим скрипт dhcp.py в каталог /etc/zabbix и выдадим права запускать его:
# chmod +x /etc/zabbix/dhcp.pyВ конфигурации Zabbix-агента в файле /etc/zabbix/zabbix_agentd.conf добавим строчку:
UserParameter=dhcp[*],/usr/bin/sudo /etc/zabbix/dhcp.py "$1" "$2" "$3" "$4" "$5"После изменения конфигурации Zabbix-агента, его нужно перезапустить:
# systemctl restart zabbix-agent
Шаблоны для Zabbix
Для того, чтобы в последних данных можно было наглядно видеть результат последней проверки, я подготовил файл для преобразования значений Valuemap_DHCP.xml. В файле созданы следующие преобразования значений:
Также я подготовил два варианта шаблона:
- Template_App_DHCP.xml - шаблон для использования с Zabbix-агентом, работающим в обычном, пассивном режиме,
- Template_App_DHCP_Active.xml - шаблон для использования с Zabbix-агентом, работающим в активном режиме.
В шаблоне есть только один элемент данных, который использует макросы из шаблона в качестве своих аргументов по умолчанию:
К этому элементу данных присоединено 8 триггеров, два из которых имеют высокую важность, т.к. свидетельствуют о неработоспособности DHCP-сервера или о появлении чужого DHCP-сервера. Остальные триггеры имеют уровень важности "Предупреждение":
Пример использования
Для примера я настроил контроль исправности DHCP-сервера на своём домашнем компьютере. В виртуальную машину с Zabbix проброшен интерфейс ens7, смотрящий в локальную сеть с DHCP-сервером. На интерфейсе отсутствуют сетевые настройки, используется он только для контроля исправности DHCP-сервера. На уровне сетевого узла созданы макросы, переопределяющие значения по умолчанию, определённые в шаблоне:
В последних данных можно увидеть числовое значение результата проверки DHCP-сервера и короткий текст, позволяющий быстро понять, какой именно результат получен:
Сообщения
Комментариев нет:
Отправить комментарий