Dhcp linux два сервера

Два DHCP сервера на Centos7 с failover, dhcp-relay и динамическим обновлением зон

Приветствую всех хабраюзеров. Мой первый опыт написания статей на Хабре, так что любая конструктивная критика приветствуется. Написать решил только лишь потому, что недавно столкнулся с задачей, решения которой «в лоб» не нашел.

Суть задачи в том, что в большой организации нужен был отказоустойчивый DHCP-сервер, с dhcp-relay и возможностью быстро синхронизировать конфигурацию. Основной момент, что в большинстве найденных мной руководствах рассматривается либо вариант failover, либо dhcp-relay и нигде оба варианта не рассматривались вместе да ещё и с удобным методом синхронизации конфигурации. Вдруг кому моя статья немного поможет?

Суть задачи в следующем: есть большое предприятие, сеть на >1000 компов, единственный vlan, 2 контроллера домена, в сети dhcp отсутствует(!). Предыдущие админы умели только так, но это отдельный рассказ и не для Хабра.

Понятно, что первой же задачей стала модернизация сети, а именно сегментация на vlan и внедрение dhcp. При анализе задачи были выработаны следующие требования:

  • Отказоустойчивость — независимость от какого-либо железа
  • Учитывая планы по сегментации сети — необходимо, чтоб сервер знал, в какой vlan какую адресацию отдавать
  • «Репликация» — учитывая, что планируется широко использовать dhcp «привязки» по MAC, нужно чтоб эти «привязки» работали всегда (например, сетевые принтеры)
  • Автоматическое ведение обратных DNS зон
  • Две виртуальные машины на двух разных гипервизорах
  • На машинах стоит centos7 и isc-dhcpd
  • На dhcp настроены failover, динамическое обновление зон и распознавание option 82
  • Option 82 меткой того VLAN, из которого пришел запрос, серверу отдают центральные коммутаторы L3+, на которых все VLAN и разруливаются
  • Так как большинство админов плохо ориентируются в linux и vim, нужна автоматизация процесса добавления статических привязок и механизм репликации конфига

image

  • DC0 и DC1 с настроенными DNS серверами, 10.1.2.2 и 10.1.2.3
  • DHCP0 и DHCP1, 10.1.2.4 и 10.1.2.14
  • VLAN’ы пользователей: 10, 11, 20, 21
  • Домен corp.example.ru
  • Дополнительную DNS зону (для linux серверов) — example.lan
  • Маршрутизаторы на базе L3 коммутаторов с поддержкой dhcp option 82. Во всех VLAN’ах они имеют 1-й IP адрес, связаны через OSPF

    Для начала в Windows DNS создаем все обратные зоны для всех VLAN’ов, разрешаем зонам небезопасные обновления.

# DHCP Server Configuration file. # see /usr/share/doc/dhcp*/dhcpd.conf.example # see dhcpd.conf(5) man page # # ddns-update-style interim; # Тип обновлений ddns-domainname "corp.example.ru"; # Имя нашего домена update-static-leases on; # На всякий случай local-address 10.1.2.4; # Адрес сервера # Логгинг информации, если запрос пришел от DHCP-relay if exists agent.circuit-id < log ( info, concat( " Accepted DHCP RELAY request for ", binary-to-ascii (10, 8, ".", leased-address), " Network segment: ", option agent.circuit-id, " DHCP Agent: ", option agent.remote-id)); ># this DHCP server to be declared valid authoritative; # Настройка безотказности failover peer "dhcp-failover" < primary; # Этот сервер главный address 10.1.2.4; # Его адрес port 519; # Его порт peer address 10.1.2.14; # Адрес второго DHCP peer port 520; # Порт второго DHCP # Дополнительные параметры настройки max-response-delay 30; max-unacked-updates 10; load balance max seconds 3; mclt 1800; split 128; # эта опция позволяет оставшемуся в работе DHCP серверу # использовать ту половину пула адресов, # которая осталась от "упавшего" сервера через Х секунд. auto-partner-down 86400; #за эту опцию спасибо @baf28 ># Сообщаем этот суффикс всем клиентам option domain-name "corp.example.ru"; # DNS-сервера option domain-name-servers 10.1.2.2, 10.1.2.3; # Дополнительные DNS-суффиксы. Не работает для Windows-клиентов option domain-search "example.lan corp.example.ru"; # Настройка времени аренды default-lease-time 604800; # 7 days max-lease-time 2419200; # 4 weeks # default netmask /24 option subnet-mask 255.255.255.0; # Servers vlan - без DHCP subnet 10.1.2.0 netmask 255.255.255.0 < ># Дополнительные файлы конфигурации для VLAN'ов include "/etc/dhcp/dhcpd.d/vlan10.conf"; include "/etc/dhcp/dhcpd.d/vlan11.conf"; include "/etc/dhcp/dhcpd.d/vlan20.conf"; include "/etc/dhcp/dhcpd.d/vlan21.conf";
# Объявление зон для безболезненного динамического обновления zone 10.1.10.in-addr.arpa. < primary 10.1.2.2; secondary 10.1.2.3; ># Описываем класс для фильтрации запросов от DHCP-relay class "VLAN10" < match if option agent.circuit-id = "VLAN10"; ># Объявляем саму нашу сеть subnet 10.1.10.0 netmask 255.255.255.0 < option routers 10.1.10.1; pool < failover peer "dhcp-failover"; # Указание на то, какой failover использовать range 10.1.10.51 10.2.56.254; # Диапазон allow members of "VLAN10"; # Привязка к классу ># === Static hosts # Admin host admin < hardware ethernet 01:23:45:67:89:ab; fixed-address 10.1.10.20; ># Admin's printer host admin < hardware ethernet cd:ef:01:23:45:67; fixed-address 10.1.10.21; ># Строчка ниже используется самописным скриптом как маркер того, # что ниже нужно вставить текст для статической привязки очередного устройства # Insert automatic text above this > 
failover peer "dhcp-failover"

Для репликации серверов достаточно написать скрипт, который синхронизирует файлы в каталоге «/etc/dhcp/dhcpd.d/» и перезапускает dhcp-демон после этого. Сам скрипт приводить не буду из-за очень «костыльного» кода, который писался на коленке и на очень скорую руку. Возможно синхронизировать конфиги с помощью утилиты типа csync2 или rsync.

Читайте также:  Login linux as root users

Для добавления статических привязок также был написан отдельный скрипт, который мне стыдно приводить тут по тем же причинам. Каждый может порезвиться с этим сам либо добавлять статические привязки «ручками».

Единственное «но» — при добавлении нового VLAN основной файл конфигурации «/etc/dhcp/dhcpd.conf» придется править ручками, так как у меня не получилось сделать include на весь каталог, только на конкретные файлы.

Возможно это можно обойти двойным include: сначала в основном файле на вспомогательный, а во вспомогательном уже на конкретные файлы VLAN, а затем синхронизировать и вспомогательный, но я заморачиваться не стал.

Повторюсь ещё раз — большинство информации, описанной мной, в интернете навалом, но нигде я не нашел как совместить failover, dhcp-relay и сделать это удобным для синхронизации. Жду ваших замечаний и предложений

Источник

два DHCP сервера в одной сети на разных ОС

Возникла необходимость внедрения второго dhcp сервера в сеть. Основной сервер собран на windows 2003. Дополнительный планирую делать на ubuntu-serve 10.04. Отсюда вопрос — делается ли это взаимным исключением диапазона IP адресов как указано в http://technet.microsoft.com/ru-ru/library/cc739076(WS.10).aspx либо все намного сложнее и поднятие двух dhcp серверов на разных ОС не практикуется?

Все это конечно можно проверить эмпирическим методом, но уж больно пообщаться хочется =)

если у тебя dhcp-сервера будут выдавать адреса только известным клиентам, то почему бы и нет? Сам протокол DHCP вполне жизнеспособен при наличии более чем одного сервера.

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

Читайте также:  Изменить название группы linux

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

можно на один повесить всех известных клиентов(винда), а неизвестные путь убунта отдает. как-то так, но это что-то совсем страшное по-моему

нормально и без костылей это будет работать только с fallback на 2-х ISC dhcp серверах.

Вы говорите про failover? Пишут, что dhcpd от MS этого не поддерживает =(

это вообще даже не стандарт(не RFC) и поддерживается ТОЛЬКО на ISC DHCP(мелкомягкие и dnsmasq в пролете однозначно)

Подскажите, ребята, как так получается? На первом DHCP (192.168.8.1) динамически раздаются адреса с 192.168.10.0 до 192.168.10.255, на втором (192.168.8.4) статическое присвоение IP. В результате получаеться, что моя сетевуха не получает IP 192.168.15.1 , а с радостью принимает IP 10.56

DHCPDISCOVER — броадкаст запрос с целью найти DHCP серваки.

DHCPOFFER — ответ от сервера с «предложением» принять его настройки

DCHPREQUEST — ответ клиент серверу о принятии настроек

DHCPNAK — сообщение отмены, сервер не может выделить IP

Тогда как понять вот это: интерфейс eth0 находиться на втором сервере (192.168.8.4)

DHCPDISCOVER from 00:25:2d:8c:70:00 via eth0

DHCPOFFER on 192.168.15.1 to 00:25:2d:8c:70:00 via eth0 DCHPREQUEST for 192.168.10.56 (192.168.8.1) from 00:25:2d:8c:70:00 via eth0: lease 192.168.10.56 unavailable.

DHCPNAK on 192.168.10.56 to 00:25:2d:8c:70:00 via eth0

Почему моя сетевуха игнорирует предложение второго сервера принять статический IP, который явно указан для этого МАС, но с радостью принимает предложение первого сервера о присвоении динамики?

Приоритетность динамического и статического присвоения как то вообще обозначается?

Приоритетности нет. Ибо нет понятия «динамический» и «статический» у протокола — клиент телепатией однако не обладает, силой мысли конфиг сервера не читает, чтобы узнать, откуда его ип взят — из пула или из статический записи.

К слову: DHCPNAK on 192.168.10.56 to 00:25:2d:8c:70:00 via eth0 может вызвать геморрой у многих виндоклиентов, в виде невозможности принять ip. Если есть 2 сервера — оба должны работать как non-authoritative чтобы подобного безобразия не было.

Вся соль заключается в том что один сервер на 2003, другой на ubuntu. Как указать что сервак на виндовс не авторитетный я не знаю. Не совсем понял почему DHCPNAK on 192.168.10.56 to 00:25:2d:8c:70:00 via eth0

А я пытаюсь разобраться почему она подхватывает ip именно с этого сервера, а не с того, где явно присвоен ip для этого МАСа. Выше писали, что присваевается IP от сервера который первее ответил. Получается что присвоение win2003 шустрее и парится по этому поводу не стоит?

Читайте также:  Flash player google chrome linux

>Не совсем понял почему DHCPNAK on 192.168.10.56 to 00:25:2d:8c:70:00 via eth0 это безобразие.

Потому что клиент может воспринять этот DHCPNAK после получения адреса как отказ в присвоении, и соответственно пытаться снова получить адрес либо радостно закричать «подключение ограничено». То же если NAK придет первым.

По поводу виндового сервака — разбирайтесь с ним, как его сделать неавторитетным.

К слову, запретить 2-му серверу отвечать на запросы клиентов и сзвестным маком можно, заюзав классы клиентов (man 5 dhcpd.conf)

Источник

два dhcp в одной сети для pxe

Добрый день. Ситуация следующая. Есть роутер на нем dhcp сервер. Есть PXE сервер. Задача: Сделать так чтобы PXE сервер получал адрес автоматически. После чего мог раздавать PXE клиентам адреса и путь к файлу загрузки(TFTP на нем же). Можно даже и без автоматического получения адреса PXE сервером. Может кто что подсказать. Задача решаемая, но настолько давно что уже и не упомню как

на первом сервере dhcp единственного клиента (второго dhcp) прописать по mac адресу. других как-то игнорировать или они автоматом будут игнорироваться. в общем развести их по mac-адресам клиентов

спасибо за ответ. Смысл двух dhcp в том, что первый раздает адреса всем(Кроме pxe — клиентов) и всегда. Второй все в одном Tftp сервер и dhcp сервер, и реагировать он должен только в том случае когда ip адрес просит pxe клиент что бы выдать ему (клиенту) еще и путь до файла загрузки. Как это выглядит в живую. Нам нужно загрузится по сети(memtest например). Включаем сервер(Который стоит на ноутбуке). Выбираем на клиенте загрузку по сети, грузимся. Почему не таскать просто флешку? У меня их гроздь, надоело таскать. ищу альтернативу.

2 ответа 2

Можно ли сажать более одного DHCP на один широковещательный сегмент?

Да, но с оговоркой — диапазоны раздачи у серверов не должны пересекаться.

Зачем это делать?

Для резервирования — если один из DHCP упал, второй, третий и т. д. поработают за него.

Как это будет работать?

DHCP работает по принципу общежития — кто первый встал, того и тапки, чашка, санузел, котэ — кто первый ответил, у того адрес и возьмут. Чтобы это происходило более определенным образом, надо настраивать оба сервера.

Нужно ли автору делать то, что он собрался делать?

Маловероятно. Автор хочет сделать странное, разделив роли серверов не горизонтально (Серверы DHCP | Серверы TFTP | Серверы удаленных ФС), а сделав DHCP со неясной ролью (раздавать адреса всем, но не раздавать PXEхнутым?) и пристроив к нему сбоку PXE с отдельной ролью (раздавать адреса на загрузку?). Цели не ясны, задачи не ясны, перспектив стабильной работы не видно.

Что делать?

Если требуется обеспечить отказоустойчивость:

Сделать N серверов DHCP+TFTP, разрезав пространство адресов между ними. Каждый сервер в качестве TFTP бдует отдавать себя.

Плюсы — вылет любого сервера не скажется на работоспособности загрузки Минусы — потребуется некоторое время на шлифовку конфигурации.

Источник

Оцените статью
Adblock
detector