Dhcp не раздает dns

Обновлено: 07.07.2024

Чтобы взаимодействовать с другими, каждому устройству в сети необходимо иметь четыре основные настройки на сетевом адаптере — IP-адрес, маску, шлюз по умолчанию и адреса DNS-серверов (хотя последнее на самом деле опционально). Есть два основных способа назначения сетевых настроек — статически (вручную) и динамически (автоматически по протоколу DHCP от DHCP-сервера).

Симптомы

Обычно всё начинается с жалоб на неработающий интернет или отсутствие доступа к локальным сетевым ресурсам. Иногда достаточно провести диагностику только на стороне клиента, но может понадобиться полная диагностика и со стороны сервера в том числе. Начнём с первой опции.

Диагностика на стороне клиента

Чтобы понять, что происходит, первым делом, конечно, следует проверить, подключён ли клиент физически к проводной или беспроводной сети. Если да, то самое время приступать к проверке сетевых настроек на устройстве клиента с помощью утилит ipconfig /all (в командной строке Windows), ifconfig или ip addr (в терминале Linux).

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

Вариант 1. Текущий IP-адрес имеет вид 169.254.Х.Х

Скорее всего, на клиентской машине при этом установлена ОС Windows. Это значит, что клиенту действительно не удалось получить сетевые настройки, потому что DHCP-сервер не отвечал, и адрес был сгенерирован службой APIPA (Automatic Private IP Addressing) из диапазона 169.254.0.0 – 169.254.255.255. Если клиент — Linux-машина, адрес может принимать вид 0.0.0.0, либо отсутствовать в принципе.

Пожалуй, самое очевидное действие в такой ситуации — попытаться снова получить IP-адрес, отправив повторно DHCP-запрос, а заодно убедиться, что на устройстве запущен DHCP-клиент. Это можно сделать несколькими способами:

отключиться от сети на 10–30 секунд и подключиться снова;
перезагрузить устройство;
выполнить последовательно команды. В командной строке Windows: ipconfig /release, затем ipconfig /renew. В терминале Linux: dhclient -v -r, потом dhclient или dhcpcd -k, затем dhcpcd ().

При выводе каких-либо ошибок и/или предупреждений нужно в первую очередь их устранить — например если DHCP-клиент не запущен, сперва его необходимо включить. После этого нужно снова проверить настройки. Если результат остался прежним, проверьте работоспособность сетевого драйвера и стека протоколов TCP/IP в целом. Проще всего это сделать с помощью команды ping 127.0.0.1 (так называемая проверка внутренней обратной петли). Если в результате выполнения команды ответ от собственного сетевого адаптера получен, можно считать диагностику на стороне клиента завершённой и переходить к диагностике со стороны DHCP-сервера.

Вариант 2. Текущий IP-адрес не из диапазона 169.254.0.0 – 169.254.255.255, но и не из того диапазона адресов, которые должен выдавать DHCP-сервер

Как известно, чудес не бывает. Если настройки, которые получает клиент, не от доверенного DHCP-сервера в сети, значит, их раздаёт кто-то другой. Тот, кто случайно или специально подключил к сети DHCP-сервер со своей конфигурацией. Возможно, это обычный Wi-Fi-роутер, к которому кабель по ошибке подключили через один из LAN-портов. Тогда ваша задача — найти недоверенный DHCP-сервер и предотвратить такие попытки в будущем.

Здесь нужно вспомнить, как работает DHCP-протокол. Клиент отправляет широковещательный запрос (DHCPDISCOVER), который получат все DHCP-серверы в сети и отправят в ответ свои предложения IP-адреса (DHCPOFFER). При этом клиент примет первое полученное предложение (DHCPOFFER), скорее всего, от ближайшего DHCP-сервера, а остальные отклонит.

Очевидно, что предложение от доверенного DHCP-сервера приходит позже, скорее всего, потому, что он дальше от клиента. Для последующей диагностики на устройстве клиента нужно установить анализатор сетевого трафика (Wireshark или tcpdump), запустить его, отфильтровав трафик по типу протокола DHCP или портам 67–68, и посмотреть в DHCP-ответах IP и MAC адрес DHCP-сервера, который их отправляет:

Вариант 3. Текущий IP-адрес корректный, но доступа к интернету и другим сетевым ресурсам по-прежнему нет

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

Следует помнить, что DHCP-сервер может раздавать настройки выборочно, а сам клиент может выборочно их применять. Например, только IP-адрес, маску и шлюз. Это скорее исключение, но в таком случае адреса DNS придётся прописать руками. Гораздо хуже, если настройки адресов DNS-серверов от DHCP-сервера игнорируются просто потому, что их переопределяет стороннее ПО или неверные статические настройки. Такое тоже бывает.

Диагностика на стороне сервера

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

Запущен ли DHCP как сервис?

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

Приходят ли запросы от клиентов на DHCP-сервер?

Чтобы определить это, нужно снова запустить анализатор сетевого трафика. На этот раз на сервере. После запуска на сервере tcpdump, dhcpdump или Wireshark клиенту, у которого проблемы с получением адреса, необходимо попытаться получить его снова любым способом, описанным в начале статьи. Если DHCP-сервер работает в штатном режиме, то должны быть и запросы, и ответы. Но всё может быть иначе.

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

Запрос(ы) есть, ответа(ов) нет?

Самая простая и очевидная причина в этом случае — закончился пул свободных адресов. Это легко проверить на самом DHCP-сервере по списку выделенных IP-адресов (leases). Если причина действительно в этом — задумайтесь: возможно, пришло время для увеличения пула пригодных для использования IP-адресов на сервере. Чтобы решить проблему прямо сейчас, можно почистить список существующих адресов, выданных в аренду клиентам, уменьшить время аренды и перезапустить сервис DHCP. Но быстрые решения помогают не всегда, а причин может быть гораздо больше. В таком случае придётся детально просматривать логи, а также последние изменения в конфигурации на сервере.

В этой статье рассматривается устранение неполадок, возникающих в DHCP-сервер.

Контрольный список по устранению неполадок

Проверьте следующие настройки.

Служба DHCP-сервера запущена и запущена. Чтобы проверить этот параметр, выполните команду net start и найдите DHCP-сервер.

Убедитесь, что аренда IP-адресов доступна в области DHCP-сервера для подсети, в которой находится клиент DHCP. Для этого см. статистику для соответствующей области в консоли управления DHCP-сервером.

Проверьте, можно ли найти в аренде адресов все списки BAD_ADDRESS.

Проверьте, имеют ли устройства в сети статические IP-адреса, которые не были исключены из области DHCP.

Убедитесь, что IP-адрес, с которым связан DHCP-сервер, находится в подсети областей, из которых должны быть арендованы IP-адреса. Это происходит, если агент ретрансляции недоступен. Для этого выполните командлет Get-DhcpServerv4Binding или Get-DhcpServerv6Binding .

Убедитесь, что только DHCP-сервер прослушивает порт UDP 67 и 68. Никакие другие процессы и другие службы (такие как WDS или PXE) не должны занимать эти порты. Для этого выполните netstat -anb команду.

Убедитесь, что исключение IPsec-сервера Добавлено при работе с средой, развернутой по протоколу IPsec.

Убедитесь, что IP-адрес агента ретранслятора можно проверить с DHCP-сервера.

Перечисление и Проверка настроенных политик и фильтров DHCP.

Журналы событий

проверьте журналы событий службы системы и DHCP-сервера (журналы приложений и служб > Microsoft > Windows > DHCP-Server) о проблемах, связанных с наблюдаемой проблемой. В зависимости от типа проблемы событие регистрируется в одном из следующих каналов событий: DHCP-сервер — рабочиесобытия DHCP-сервер события DHCP-серверасистемные событияоповещениеDHCP-сервера событияаудита DHCP-сервера

сбор данных

Журнал DHCP-сервера

Журналы отладки службы DHCP-сервера содержат дополнительные сведения о назначении аренды IP-адресов и динамические обновления DNS, которые выполняются DHCP-сервером. Эти журналы по умолчанию находятся в папке%windir%\System32\Dhcp. Дополнительные сведения см. в разделе Анализ файлов журнала DHCP-сервера.

Трассировка сети

Корреляция трассировки сети может означать, что DHCP-сервер выполнялся в момент записи события в журнал. Чтобы создать такую трассировку, выполните следующие действия.

перейдите в GitHubи скачайте файл tss_tools.zip .

Скопируйте файл Tss_tools.zip и разверните его в расположении на локальном диске, например в папке C:\Tools.

Выполните следующую команду из C:\Tools в окне командной строки с повышенными привилегиями:

Если при регистрации в Сообществе Вы укажете адрес электронный почты, который используете на данном форуме, то Ваши данные будут перенесены на форум Сообщества автоматически.
Также, если на форуме Сообщества Ваш никнейм будет занят, то Вам предложат сменить его или оставить, но с приставкой "_RU".

Убедительная просьба не дублировать темы на старом/новом форуме.

Не корректно выдача DNS DHCP сервером

Правила форума
Правила форума TP-LINK lll ЧАВО lll Первичная настройка WAN роутера lll Настройка под провайдеров lll Официальные прошивки и драйверы lll

Не корректно выдача DNS DHCP сервером

Пользователи локальной сети в домене с поднятым DNS-сервером должны обращаться только к этому DNS-серверу, а все дальнейшие DNS-запросы к другим DNS-зонам должен запрашивать и разрешать сам DNS-сервер на контроллере домена. Лучше всего для раздачи сетевых настроек в локальной сети с доменной структурой поднять DHCP-сервер на контроллере домена, а если этого не делать по каким-либо причинам, тогда в настройках "DHCP Settings" для LAN на роутере в качестве Secondary DNS нужно обязательно указать 2-й адрес, который будет отличаться от 1-го и от 0.0.0.0, иначе в 1-м случае такой адрес вообще не применится, а во 2-м он автоматически заменится при выдаче клиентам на адрес роутера.

В том случае, если у вас в локальной сети установлен всего один контроллер домена с поднятым DNS-сервером, тогда нужно в свойствах сетевого подключения этого сервера добавить еще один локальный IP-адрес, а потом именно его указать в качестве 2-го адреса в настройках роутера для Secondary DNS. После этого еще раз проверить настройки сетевого подключения на контроллере домена через его свойства. Во первых, сетевые параметры должны быть настроены в ручном режиме, во вторых, в качестве 1-го DNS-сервера необходимо указать: 127.0.0.1, а в качестве 2-го DNS-сервера: 192.168.1.1 (1-й адрес DNS-сервера).

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

Обратные зоны настроены? У нас как-то трабла была из-за этого, ЕМНИП

забыл добавить!

в обратную зону как раз то и добавляет (PTR) а в прямую отказывается(А)

DHCP на Windows 2003 что-ли?

1) сервер DHCP входит в группу DnsUpdateProxy?
2) в свойствах сервера DHCP в Credentials есть учетная запись, от имени которого производится регистрация записей в DNS

ну скорей всего 3-й вариант
3) Служба DHCP Client на сервере должна работать, иначе не будет работать Dynamic DNS Updates

DHCP да на Windows 2003

1) сервер dhcp он же и контролер домена, думаю разрешения в нутри себя должны быть полными
2)в свойствах сервера DHCP в Credentials есть учетная запись с админскими правами
3) на сервере DHCP Client работает

Ну тогда возникают несколько вопросов.

Вот это в корне меняет дело.

Цитата:
в обратную зону как раз то и добавляет (PTR) а в прямую отказывается(А)

1. Появляются ли записи в прямой зоне просмотра, если на стороне клиента запустить команду ipconfig /registerdns ?
2. На сервере сколько сетевых интерфейсов: 1 или более?
3. Руками в DNS добавляются записи?
4. Возможно у Вас 2 контроллера домена, соответствуют ли в 2-х DNS вложенность в зоне _msdcs ?
5. Запустите dcdiags, есть ли какие-то ошибки, связанные с регистрацией в DNS?

Попробуем докопаться до истины, но боюсь, что легче будет переустановить DHCP сервер. Наверное это не поможет, и, в конце концов, переустановить и DNS-сервер. На боевом контроллере это делать не рекомендуется, т.к. создаются зоны и записи при отработке dcpromo, но в принципе можно создать _msdcs руками и сделать netdiag /fix

результата пока не добился

1. У клиента запусаю команду ipconfig /registerdns результат 0
2. На сервере сколько сетевых интерфейсов: 1
3. В DNS добавляются записи руками
4. Да у нас Вас 2 контроллера домена, вложенность в зоне _msdcs соответствуют в обоих DNS
5. Запустил dcdiags, не чего не сказал все пункты "passed"

DHCP переустановил результат не дало! ДНС пока боюсь трогать, так как не сам подымал и много чего накопилось в них.

Всё-таки похоже на то, что проблема в DNS

Цитата:
У клиента запусаю команду ipconfig /registerdns результат 0

Что при этом происходит:
1) Если клиент получает адрес от DHCP, то после выполнения команды он обновляет аренду DHCP, получает адрес, а также другие данные, в том числе о DNS (если указано в настройках DHCP) и регистрирует все соответствующие имена DNS
2) Если у клиента сетевые настройки прописаны вручную, то после выполнения такой команды, начинает динамическую регистрацию в DNS того, что прописано руками
Т.о, для нас значит, нужно проверить, регистрируются ли имена клиентов с прописанными руками сетевыми настройками

На всякий случай пару вопросов, чтобы сразу их исключить:
1) в DNS-сервере в зоне разрешены безопасные обновления
2) у клиентов, независимо от способа получения адреса, включены службы DNS-клиент и DHCP-клиент, и в сетевом интерфейсе 2 DNS соответствуют тому что есть на самом деле, т.е. именно Ваши КД, а не какой-нибудь адрес DNS-сервера провайдера.
3) надеюсь клиенты - это не какая-нибудь кривая сборка по типу DVD Zver
?

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

P.S. DNS пока не трогайте.

1. Да в DNS зоне разрешены как безопасные так и не безопасные обновления
2. На клиентской машине включены службы DNS и DHCP клиент, сетевой интерфейсе получает настройки автоматически и полученные настройки соответствуют параметрам DHCP сервера, т.е. внутрений DNS, шлюз и.п.
3. ОС клиента Windows 7 Pro (лицензионная), к тому же захожу черед учетную запись администратора.
4. После Идентификации клиентской машины на сервере в AD имя компьютера добавляется.

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

Цитата:
После Идентификации клиентской машины на сервере в AD имя компьютера добавляется Уточнение:
1) "имя компьютера добавляется" - это в DNS или в AD?
2) если добавляется в DNS, то происходит это после ввода компьютера в домен из рабочей группы?
3) или появляются только в AD, а до этого компа там не было?

1. Имя компьютера добавляется в AD!
2. запись от клентского компьютера добавляет в обратную зону DNS добавляет как только получает настройки от DHCP без входа в домен находясь просто в рабочей группе.
3. Когда ввожу его в домен то контролер домена нормально добавляет его в AD. Соответственно в AD имя клиента есть, а в DNS он виден только в обратной зоне.
4. Имя домена неоднокомпонентное! пример: dcyktnef.local

Я так понимаю из прочитанной кучи литературы про авторегистрацию в DNS что:
1. Клиент при первом подключении пускает широковещательный запрос для перво попавшего DHCP сервера "кто я"
2. DHCP рамках пула выделяет ip и остальные настройки DNS-a и Шлюза
3. Клиент получив настройки IP, DNS и шлюза, сразу направляет в полученный IP адрес DNS-сервера запрос на регистрацию в нем своего имени и IP в прямой и обратной зоне.
4. В DNS-сервере если разрешены небезопасные записи, то прописывает эти настройки у себя в прямую и обратную зону.

Контролер домена подымал не я, и склоняюсь к тому что при установке роли DNS в визарде оставили галочку на запрет авто обновлений записей, может Вы знаете как добраться до этого пункта или всё же придётся сносить DNS?

Совсем не давно столкнулся с такой проблемой по непонятным причинам DHCP перестал раздавать IP адреса клиентам. Проверив работоспособность сервера выявилась следующая ошибка в журнале. Служба DHCP не обслуживает клиентов DHCPv4, поскольку ни один активный сетевой интерфейс не имеет статически настроенного IPv4-адреса либо активных интерфейсов нет. Как любой айтишник обратился к гуглу) но более менее внятного ответа на свой вопрос я не нашел. По этому решил написать не большую статью на эту тему для будущих поколений.

DHCP сервер Windows 2016 не раздает адреса

И так ваш DHCP сервер поднятый на Windows Server 2016 или любой другой версии перестал раздавать IP адреса и в журнале вы видите следующею ошибку.

Решить эту проблему очень просто. Для этого запускаем оснастку DHCP.

Далее раскрываем дерево DHCP и кликаем правой кнопкой на IPv4 выбираем Свойства.

В открывшемся окне переходим на вкладку Дополнительно, тут кликаем на пункт Привязки.

В открывшемся окне ставим галочку напротив нужного сетевого интерфейса.

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

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

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

Немного теории и решения интересных и не очень практических задач — под катом.

В современной локальной сети выдачей адресов обычно занимаются специализированные сервисы с поддержкой протоколов. Самым популярным из них является DHCP (Dynamic Host Configuration Protocol).

В принципе, специально для функционирования небольших сетей был создан стек технологий под названием Zeroconf. Он позволяет обойтись без каких-либо централизованных сервисов и серверов, включая, но не ограничиваясь выдачей IP-адресов. Им закрываются (ну, или почти закрываются) следующие вопросы:

Получение IP-адреса (Automatic Private IP Addressing или APIPA). Система сама назначает себе IP из сети 169.254.0.0/16 (кроме сеток /24 в начале и конце диапазона), основываясь на MAC-адресе и генераторе псевдослучайных чисел. Такая система позволяет избежать конфликтов, а адрес из этой сети называют link-local — в том числе и потому, что эти адреса не маршрутизируются.

Поиск по имени. Система анонсирует свое сетевое имя, и каждый компьютер работает с ним как с DNS, храня записи у себя в кэше. Apple использует технологию mDNS (Multicast DNS), а Microsoft — LLMNR (Link-local Multicast Name Resolution), упомянутую в статье «Домены, адреса и Windows: смешивать, но не взбалтывать».

При всех плюсах Zeroconf — без каких-либо сакральных знаний можно собрать рабочую сеть, просто соединив компьютеры на физическом уровне, — IT-специалистам он может даже мешать.

Немного раздражает, не так ли?

В системах Windows для отключения автонастройки на всех сетевых адаптерах необходимо создать параметр DWORD с именем IPAutoconfigurationEnabled в разделе HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters и поставить ему значение 0.

Разумеется, Zeroconf подходит разве что для небольших изолированных сетей (например, встретились с приятелем с ноутбуками, соединили их по Wi-Fi и давай играть Diablo II, не тратя время на какие-то сервера), да и выводить локальную сеть в интернет тоже хочется. Чтоб не мучаться со статическими настройками каждого компьютера, были созданы специальные протоколы, включая героя дня — DHCP.

Одна из первых реализаций протокола для выдачи IP-адресов появилась более 30 лет назад и называлась RARP (Reverse Address Resolution Protocol). Если немного упростить принцип его работы, то выглядело это так: клиент делал запрос на широковещательный адрес сети, сервер его принимал, находил в своей базе данных привязку MAC-адреса клиента и IP — и отправлял в ответ IP.

Схема работы RARP протокола.

И все вроде работало. Но у протокола были минусы: нужно было настраивать сервер в каждом сегменте локальной сети, регистрировать MAC-адреса на этом сервере, а передавать дополнительную информацию клиенту вообще не было возможности. Поэтому на смену ему был создан протокол BOOTP (Bootstrap Protocol).

Изначально он использовался для бездисковых рабочих станций, которым нужно было не только выдать IP-адрес, но и передать клиенту дополнительную информацию, такую, как адрес сервера TFTP и имя файла загрузки. В отличие от RARP, протокол уже поддерживал relay — небольшие сервисы, которые пересылали запросы «главному» серверу. Это сделало возможным использование одного сервера на несколько сетей одновременно. Вот только оставалась необходимость ручной настройки таблиц и ограничение по размеру для дополнительной информации. Как результат, на сцену вышел современный протокол DHCP, который является совместимым расширением BOOTP (DHCP-сервер поддерживает устаревших клиентов, но не наоборот).

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

Клиент ищет сервер широковещательным запросом, запрашивая в том числе и дополнительные настройки.
Сервер отвечает клиенту, предлагая ему IP-адрес и другие настройки.
Клиент подтверждает принятую информацию широковещательным запросом, указав в подтверждении IP-адрес выбранного сервера.
Сервер соглашается с клиентом, отправляя ему запрос, по получении которого клиент уже настраивает сетевой интерфейс или отвергает его.

Схема общения клиента с сервером пересылки и сервером.

На нескольких собеседованиях меня спрашивали: «А какой транспорт и порт использует DHCP?» На всякий случай отвечаем: «Сервер UDP:67, клиент UDP:68».

С разными реализациями DHCP-сервера сталкивались многие, даже при настройке домашней сети. Действительно, сейчас сервер есть:

На практически любом маршрутизаторе, особенно SOHO.
На системах Windows Server. О сервере и его настройке можно почитать в официальной документации.
На системах *nix. Пожалуй, самое популярное ПО — ISC DHCP Server (dhcpd) и «комбайн» Dnsmasq.

Конкретных реализаций довольно много, но, например, на SOHO-маршрутизаторах настройки сервера ограничены. В первую очередь это касается дополнительных настроек, помимо классического «IP-адрес, маска, шлюз, сервер DNS». А как раз эти дополнительные опции и вызывают наибольший интерес в работе протокола. С полным списком можно ознакомиться в соответствующем RFC, я же разберу несколько интересных примеров.

Option 6 и Option 15. Начнем с простого. Настройка под номером 6 — это серверы DNS, назначаемые клиентам, 15 — суффикс DNS. Назначение суффикса DNS может быть полезным при работе с доменными ресурсами в недоменной сети, как я описывал в статье «Как мы сокращали персонал через Wi-Fi». Настройка MikroTik под спойлером.

Знание, что сервер DNS — это тоже опция, недавно пригодилось мне, когда разным клиентам нужно было выдать разные серверы DNS. Решение вида «выдать один сервер и сделать разные правила dst-nat на 53 порт» не подходило по ряду причин. Часть конфигурации снова под спойлером.

Option 66 и Option 67. Эти настройки пришли еще с BOOTP и позволяют указать TFTP-сервер и образ для сетевой загрузки. Для небольшого филиала довольно удобно установить туда микротик и бездисковые рабочие станции и закинуть на маршрутизатор подготовленный образ какого-нибудь ThinStation. Пример настройки DHCP:

Option 121 и Option 249. Используются для передачи клиенту дополнительных маршрутов, что может быть в ряде случаев удобнее, чем прописывать маршруты на шлюзе по умолчанию. Настройки практически идентичные, разве что клиенты Windows предпочитают вторую. Для настройки параметра маршруты надо перевести в шестнадцатеричный вид, собрав в одну строку маску сети назначения, адрес сети и шлюз. Также, по RFC, необходимо добавить и маршрут по умолчанию. Вариант настройки — под спойлером.

Предположим, нам нужно добавить клиентам маршрут вида dst-address=10.0.0.0/24 gateway=192.168.88.2, а основным шлюзом будет 192.168.88.1. Приведем это все в HEX:

Данные для настройки	DEC	HEX
Маска	24	0x18
Сеть назначения	10.0.0.0	0x0A 00 00
Шлюз	192.168.88.2	0xc0 a8 58 02
Сеть по умолчанию	0.0.0.0/0	0x00
Шлюз по умолчанию	192.168.88.1	0xc0 a8 58 01

Соберем все это счастье в одну строку и получим настройку:

Подробнее можно прочитать в статье «Mikrotik, DHCP Classless Route».

Option 252. Автоматическая настройка прокси-сервера. Если по каким-то причинам в организации используется непрозрачный прокси, то удобно будет настроить его у клиентов через специальный файл wpad (pac). Пример настройки такого файла разобран в материале «Proxy Auto Configuration (PAC)». К сожалению, в MiroTik нет встроенного веб-сервера для размещения этого файла. Можно использовать для этого пакет hotspot или возможности metarouter, но лучше разместить файл где-либо еще.

Option 82. Одна из полезнейших опций — только не для клиента, а для DHCP-релея. Позволяет передать серверу информацию о порте коммутатора, к которому подключен клиент, и id самого коммутатора. Сервер на основе этой информации в свою очередь может выдать уже клиенту какой-то определенный набор настроек или просто занести в лог — чтобы в случае необходимости найти порт подключения клиента, не приходилось заходить на все свитчи подряд (особенно, если они не в стеке).

После настройки DHCP-Relay на маршрутизаторе в информации о клиентах появятся поля Agent Circuit ID и Agent Remote ID, где первое — идентификатор порта коммутатора, а второе — идентификатор самого коммутатора.

Выдача адресов с option 82.

Информация выдается в шестнадцатиричном формате. Для удобства восприятия при анализе журнала DHCP можно использовать скрипты. Например, решение для решения от Microsoft опубликовано в галерее скриптов Technet под названием «Декорирование DHCP опции 82».

Также опция Option 82 активно используется в системе биллинга провайдеров и при защите сети от посторонних вмешательств. Об этом чуть подробнее.

Это функция коммутатора, которая позволяет «привязать» DHCP-сервер к определенному порту. Ответы DHCP на других портах будут заблокированы. В некоторых коммутаторах можно настроить и работу с Option 82 при ее обнаружении в пакете (что говорит о присутствии релея): отбросить, заменить, оставить без изменения.

В коммутаторах MikroTik включение DHCP Snooping производится в настройках бриджа:

Настройка в других коммутаторах происходит аналогичным образом.

Стоит отметить, что не все модели MikroTik имеют полную аппаратную поддержку DHCP Snooping — она есть только у CRS3xx.

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

Красивая коммутационная — залог здоровья.

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

Казалось бы, можно поделить область выдачи между двумя серверами, и пусть один выдает одну половину адресов, а второй — другую. Вот только парализованная половина инфраструктуры немногим лучше, чем целая.

Разберем более практичные варианты.

В системах Windows Server начиная с 2012 система резервирования DHCP работает «из коробки», в режиме балансировки нагрузки (active-active) или в режиме отказоустойчивости (active-passive). С подробным описанием технологии и настройками можно ознакомиться в официальной документации. Отмечу, что отказоустойчивость настраивается на уровне зоны, поэтому разные зоны могут работать в разном режиме.

Настройка отказоустойчивости DHCP-сервера в Windows.

В ISC DHCP Server для настройки отказоустойчивости используется директива failover peer, синхронизацию данных предлагается делать самостоятельно — например, при помощи rsync. Подробнее можно почитать в материале «Два DHCP сервера на Centos7. »

Если же делать отказоустойчивое решение на базе MikroTik, то без хитростей не обойтись. Один из вариантов решения задачи был озвучен на MUM RU 18, а затем и опубликован в блоге автора. Если вкратце: настраиваются два сервера, но с разным параметром Delay Threshold (задержка ответа). Тогда выдавать адрес будет сервер с меньшей задержкой, а с большей задержкой — только при выходе из строя первого. Синхронизацию информации опять же приходится делать скриптами.

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

Расскажите, а вам приходилось сталкиваться с проказами DHCP?

История аренды IP-адресов на DHCP сервере

Постановка задачи

И так у вас развернут DHCP сервер на Windows. В какой-то момент вам потребовалось выяснить, кем был зарезервирован IP-адрес, например несколько дней назад. Когда у вас время аренды большое, это сделать проще, если настроено резервирование, то это еще проще, но мы рассмотрим, что у вас время аренды, пусть будет сутки и резервирования нет. Благодаря моей инструкции вы сможете вычислить компьютер и mac-адрес устройства, кто получал нужный нам ip-адрес.

Как найти историю аренды ip-адресов DHCP

Откройте оснастку DHCP, и откройте свойства вашего пула IPV6 или IPV6. Убедитесь, что у вас включена функция "Вести журнал аудита DHCP", если нет то включаем ее.

На вкладке "Дополнительно" вы можете посмотреть куда сохраняется журнал с событиями сервера. По умолчанию, это C:Windowssystem32dhcp.

Читайте также: