Настраиваем отказоустойчивый DHCP-сервер на базе ISC DHCP

  • Автор:

isc-dhcp-failover-000.png

DHCP-сервер является одним из ключевых элементов сетевой инфраструктуры любого размера и его нормальное функционирование является залогом стабильной работы сети. Одним из способов это обеспечить является создание отказоустойчивой структуры из двух серверов, которые в нормальном режиме балансируют нагрузку, а в случае недоступности одного из серверов обслуживание всех его клиентов переходит к партнеру. В данной статье мы расскажем, как настроить такой сервер на базе ISC DHCP на платформе Linux.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

ISC DHCP - один из самых популярных пакетов DHCP-сервера для Linux и Unix-like систем, при этом он прост в настройке и нетребователен к ресурсам. В данной статье мы будем выполнять все действия в среде Debian, и инструкция подойдет для любой современной системы основанной на Debian или Ubuntu, а с поправкой на работу пакетного менеджера - для любых иных Linux дистрибутивов.

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

isc-dhcp-failover-001.pngЕсли не указано иного, все команды выполняются от имени суперпользователя или через sudo.

Получение OMAPI-ключа

Для взаимодействия серверов между собой в составе отказоустойчивой структуры используется специальный интерфейс Object Management API (OMAPI), который позволяет получать доступ к объектам, расположенным в базе DHCP-сервера (данные об аренде, узлах, группах). в целях безопасности сервера производят взаимную аутентификацию и для этого нам понадобится специальный ключ.

Генерация ключа производится при помощи утилиты tsig-keygen, которая входит в состав DNS-сервера bind, но не будем же мы его ставить ради единственной, по сути, одноразовой операции. Кстати, если у вас есть установленный bind, то вы можете выполнить генерацию ключа на нем. Но мы пойдем другим путем. Создадим в домашней директории суперпользователя временную папку и перейдем в нее:

mkdir /root/tmp
cd /root/tmp

Теперь скачаем и распакуем содержимое пакета bind9, чтобы не вводить полное имя пакета во второй команде воспользуйтесь автоматической подстановкой по клавише Tab:

apt download bind9
dpkg-deb -xv bind9_1%3a9.16.27-1~deb11u1_amd64.deb /root/tmp

Перейдем в каталог с нужными бинарниками:

cd usr/sbin

И выполним генерацию ключа:

./tsig-keygen DHCP.OMAPI > /root/dchp_omapi.key

После чего временную папку со всем содержимым можно удалить, она нам больше не понадобится:

rm -rf /root/tmp

Посмотреть содержимое ключа можно командой:

cat /root/dchp_omapi.key

В выводе вы должны увидеть следующее:

key "DHCP_OMAPI" {
algorithm hmac-sha256;
secret "3Vx8hd3OWNWudoJlq3bvvnnwv0H8n44ZdwCoTkFVPHo=";
};

Здесь нас интересуют две вещи: алгоритм хеширования - HMAC-SHA256 и собственно ключ, который находится в кавычках в строке secret. Следует отметить, что многие инструкции в сети интернет предлагают использовать для получения ключа утилиту dnssec-keygen и алгоритм HMAC-MD5, не будем говорить за все дистрибутивы, но в последних версиях Debian / Ubuntu данная утилита не поддерживает хеш-алгоритмы. Про HMAC-MD5 мы даже говорить не будем, по сегодняшним меркам это слабый криптоалгоритм, поэтому мы будем делать все правильно.

Настройка первичного DHCP-сервера

Отказоустойчивый DHCP-сервер строится по схеме первичного и вторичного узлов, которые могут работать как в режиме балансировки нагрузки (рекомендуется), так и в режиме горячего резерва. Отвечающие за это настройки мы рассмотрим ниже, а пока установим сам пакет ISC DHCP:

apt install isc-dhcp-server

После чего перейдем к редактированию конфигурационного файла, он в основном содержит некоторые общие параметры и закомментированные примеры, поэтому мы оставим в нем только общие настройки, а все остальные вынесем во внешние файлы. Откроем /etc/dhcp/dhcpd.conf, найдем и раскомментируем в нем следующую опцию:

authoritative;

Она включает "авторитетность" сервера, в этом случае получив запрос на адрес, не принадлежащий текущей сети, сервер ответит сообщением DHCPNAK, которое предлагает клиенту отказаться от адреса и запросить новый. Это позволяет быстрее получать адреса мобильным клиентам, которые до этого были подключены к другой сети.

Затем в самый конец файла добавляем:

omapi-port 7911;
omapi-key omapi_key;
key omapi_key {
algorithm hmac-sha256;
secret 3Vx8hd3OWNWudoJlq3bvvnnwv0H8n44ZdwCoTkFVPHo=;
}

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

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

include "/etc/dhcp/dhcpd.d/failover.conf";
include "/etc/dhcp/dhcpd.d/subnet.conf";
include "/etc/dhcp/dhcpd.d/static.conf";

Сохраняем файл и перейдем к созданию внешних файлов и директорий:

mkdir /etc/dhcp/dhcpd.d
cd /etc/dhcp/dhcpd.d
touch failover.conf subnet.conf static.conf

Начнем с /etc/dhcp/dhcpd.d/failover.conf, в котором мы будем хранить конфигурацию отказоустойчивой группы, внесем в него следующий текст:

failover peer "failover-dhcp" {
primary;
address 192.168.72.11;
port 647;
peer address 192.168.72.12;
peer port 647;
max-response-delay 60;
max-unacked-updates 10;
mclt 3600;
split 128;
load balance max seconds 3;
}

Самой первой строкой мы указываем тип сервера - primary - первичный. Затем следует адрес и порт сервера, адрес и порт партнера. Для работы используется порт 647, который специально используется для DHCP-FAILOVER. опция max-response-delay указывает на максимально допустимое расхождение времени между двумя узлами.

Два следующих параметра должны быть указаны только на первичном сервере.

  • mclt (максимальное время обслуживания клиента) - он показывает в течении какого времени сервер, находящийся в состоянии обработки отказа, будет ждать восстановления связи с партнером, по его истечении контроль за распределением IP-адресов полностью переходит под управление оставшегося сервера.
  • split - задает параметры разделения пула адресов между серверами. Может иметь значения от 0 до 256, при значении в 128 пул будет разделен 50/50, и нагрузка будет равномерно балансироваться между серверами. Если указать 256, то весь пул будет управляться первичным сервером, а вторичный сервер перейдет в режим горячей замены.

Следующий конфигурационный файл /etc/dhcp/dhcpd.d/subnet.conf хранит в себе параметры области:

subnet 192.168.72.0 netmask 255.255.255.0 {
option subnet-mask 255.255.255.0;
option routers 192.168.72.1;
option domain-name-servers 192.168.72.1;
default-lease-time 28800;
max-lease-time 86400;
pool {
failover peer "failover-dhcp";
range 192.168.72.100 192.168.72.199;
}
}

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

Отдельно обратим внимание на опции default-lease-time - время аренды, выдаваемое по умолчанию и max-lease-time - максимальное время аренды, которое может быть выдано по запросу клиента. Если клиент не запрашивает конкретное время аренды ему будет выдан адрес на время, указанное в параметре по умолчанию, иначе - желаемое время, но не превышающее максимальное. В нашем случае это 8 часов и сутки.

В секции pool указываем диапазон адресов к выдаче и ссылку на отказоустойчивую группу. Если пулов несколько - то указываем отказоустойчивые группы для каждого из них, при этом разные пулы могут обслуживать разные пары серверов.

И, наконец, последний файл /etc/dhcp/dhcpd.d/static.conf, здесь мы будем хранить резервирование IP-адресов, по мере надобности добавляем в него секции:

host myhost {
hardware ethernet 08:45:32:00:00:23;
fixed-address 192.168.72.121;
}

В данном случае мы зарезервировали за устройством с MAC-адресом 08:45:32:00:00:23 IP-адрес 192.168.72.121.

Проверим правильность конфигурации:

dhcpd -t -cf /etc/dhcp/dhcpd.conf

И при отсутствии ошибок обязательно перезагрузим сервер.

Для управления службой используйте

systemctl start|stop|restart|status isc-dhcp-server

isc-dhcp-failover-002.pngУбедившись, что служба запущена и работает без ошибок, перейдем к настройке второго сервера.

Настройка вторичного DHCP-сервера

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

Внести изменения нам потребуется только в файл /etc/dhcp/dhcpd.d/failover.conf, он должен иметь следующее содержимое:

failover peer "failover-dhcp" {
secondary;
address 192.168.72.12;
port 647;
peer address 192.168.72.11;
peer port 647;
max-response-delay 60;
max-unacked-updates 10;
load balance max seconds 3;
}

Первая строка указывает что это вторичный сервер - secondary, затем следуют адрес и порт сервера и его партнера, за ними остальные опции, которые остаются без изменений.

Сохраняем настройки, проверяем их и перезагружаем сервер. Теперь нашу область будут обслуживать сразу оба сервера, балансируя нагрузку между собой. Для проверки по очереди выключаем сервера и убеждаемся, что оставшийся сервер берет на себя обслуживание клиентов.

Настройка брандмауэра

Если на ваших узлах включен брандмауэр iptables, то вам потребуется добавить в него два разрешающих правила:

iptables -A INPUT -p udp -m state --state NEW -m udp --dport 67 -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 647 -j ACCEPT

Второе правило можно немного изменить, разрешив серверам принимать соединения только друг от друга:

iptables -A INPUT -s 192.168.72.12 -p tcp -m state --state NEW -m tcp --dport 647 -j ACCEPT

Где -s 192.168.72.12 - адрес сервера-партнера. Данные правила должны располагаться выше правила, запрещающего все входящие соединения.

Дополнительно

В завершение заглянем в /etc/default/isc-dhcp-server, здесь нас будут интересовать две последние опции в файле:

INTERFACESv4="eth0"
#INTERFACESv6=""

В первой из них желательно задать интерфейс (можно несколько) на которых ваш DHCP-сервер будет принимать запросы, это важно, если интерфейсов более одного. Вторая опция отвечает за работу c IPv6, если вы не работаете с этим протоколом и не настраивали обработку IPv6 запросов, то просто отключите шестую версию закомментировав эту строку.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Поддержи проект!

Или подпишись на наш Телеграм-канал: Подпишись на наш Telegram-канал



Loading Comments