Не работает dhcp windows server 2016

09.09.2024 17:05

Создатель темы

Настроил 2 виртуальные машины в VM VirtualBox: Windows Server 2016 и Windows 7 в роли клиента. У обеих стоят адаптеры, первый — Сетевой мост, второй — Внутренняя сеть intent. Через графический интерфейс сервера был настроен DHCP. Основной ip-адрес для сервера, и сеть в которой мне нужен клиент, прописывал и на первом адаптере и на втором, все бестолку. Клиент не получает ipшник от DHCP сервера, который мне нужен. Не понимаю, в чем проблема, прошу без осуждений, так как Windows Server изучаю недавно.

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

Но сначала немного истории.

До выхода Windows Server 2012 единственным способом обеспечить отказоустойчивость DHCP-сервера была так называемая схема 80\20. Суть этой схемы заключается в том, что для обслуживания одной области используются два DHCP-сервера. Область делится между ними в пропорции 80\20, соответственно основному серверу отдается 80%, а резервному 20% имеющихся IP-адресов. В нормальном режиме работы область обслуживается основным сервером, а при выходе из его строя резервный берет на себя нагрузку и выдает клиентам адреса из оставшихся 20%, тем самым поддерживая работу сети.

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

• При разделении области имеющиеся адреса используются не самым оптимальным образом;
• Клиенты не могут продлить аренду с имеющимся адресом;
• Проблемы при использовании резервирования.

Примечание. Резервирование (DHCP reservation) — настройка DHCP-сервера, при которой к MAC-адресу клиента привязывается постоянный IP-адрес. Это гарантирует, что клиент всегда будет получать в аренду один и тот же адрес. Резервирование настраивается на конкретном сервере и при его недоступности клиент не сможет получить зарезервированный за ним адрес.

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

DHCP failover может работать в двух режимах.

Режим балансировки (Load balance)

В этом режиме область делится на две части в определенной пропорции и обслуживается обоими серверами одновременно. При получении запроса каждый сервер вычисляет хэш MAC-адреса клиента в соответствии с алгоритмом, описанным в RFC 3074. MAC-адреса хэшируются в диапазоне от 1 до 256, балансировка происходит по следующему принципу: если нагрузка распределена в пропорции 50\50 и если при вычислении хэша получено значение от 1 до 128, то отвечает первый сервер, если же от 129 до 256 — то отвечает второй. При изменении коэффициента распределения нагрузки распределение хэш-блоков между серверами изменяется в той же пропорции. Такой подход гарантирует, что за одного конкретного клиента отвечает только один сервер.

Если же один из серверов перестает отвечать, то второй забирает всю область и продолжает обслуживать как своих клиентов, так и клиентов партнера.

Режим горячей замены (Hot Standby)

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

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

От теории перейдем к практике. Для создания отказоустойчивой конфигурации возьмем 2 сервера — SRV1 и SRV2, находящихся в одной подсети. На SRV1 создаем область (Scope) и полностью настраиваем ее, на SRV2 только устанавливаем роль DHCP, никаких настроек не производим. После этого приступаем к настройке DHCP failover.

Настройка DHCP failover

Для начала настроим режим балансировки (Load balance). Для этого заходим на сервер SRV1 и открываем оснастку DHCP. Выбираем область, кликаем на ней правой клавишей и в контекстном меню отмечаем пункт «Configure Failover».

запуск мастера настройки

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

выбор области для настройки dhcp-failover

Добавляем сервер-партнер, на котором будет находится второй экземпляр области.

выбор сервера-партнера

На следующем этапе выбирается режим работы и основные настройки.

В качестве имени для создаваемых доверительных отношений (Relationship Name) по умолчанию используются имена серверов, но в принципе можно указывать что угодно. Режим работы (Mode) выбираем балансировку (Load balance) и в поле «Load Balance Percentage» указываем в процентах пропорции, в которых будет разделена область между двумя серверами. По умолчанию нагрузка делится в соотношении 50\50, но мы сделаем по привычной схеме 80\20, т.е. 80% обслуживает основной сервер и 20% резервный.

Теперь два очень важных параметра, на которых надо обратить внимание:

• State Switchover Interval — интервал времени, по истечении которого партнер считается недоступным (PARTNER_DOWN). Если не задавать этот параметр, то при падении партнера автоматического переключения не произойдет и переключатся придется вручную;
• Maximum Client Lead Time — очень интересный параметр, определяющий срок продления аренды в случае падения основного сервера. Когда клиент пытается продлить аренду, полученную на основном сервере, то резервный сервер продлевает ее не на срок аренды, указанный в свойствах области, а на время, указанное в данном параметре. И так пока основной сервер не восстановит работу. Также этот параметр определяет, сколько времени сервер будет ждать возвращения партнера из состояния PARTNER_DOWN прежде чем забрать контроль над всей областью. А еще этот параметр определяет время перехода в нормальное состояние при возвращении партнера.

Примечание. Параметры State Switchover Interva и Maximum Client Lead Time определяют скорость срабатывания failover-а. Каждый из партнеров обслуживает свой диапазон адресов до того момента, пока один из серверов не перейдет в состояние PARTNER_DOWN  и не пройдет время, указанное в параметре Maximum Client Lead Time. Только после этого ″оставшийся в живых″ сервер возьмет на себя контроль над всей областью.

Сервера должны безопасно общаться друг с другом. Для этого включаем параметр «Enable Message Authentication» и в поле «Shared Secret» задаем кодовое слово, которое сервера будет использоваться для связи.

выбор режима и настройка параметров

В заключение проверяем настройки, подтверждаем создание failover-а

подтверждение настроек

и ждем завершения процесса.

завершение настройки

Посмотреть настройки и текущее состояние партнеров можно в свойствах области, на вкладке «Failover».

То же самое можно сделать с помощью PowerShell. Создаем доверительные отношения:

Add-DhcpServerv4Failover -ComputerName srv1.test.local -Name ″srv1-srv2″ -PartnerServer srv2.test.local -ScopeId 10.0.0.0 -LoadBalancePercent 80 -MaxClientLeadTime 00:10:00 -AutoStateTransition $true -StateSwitchInterval 00:10:00 -SharedSecret ″12345678″ -Force

Проверяем результат:

Get-DhcpServerv4Failover -Name ″srv1-srv2″ | fl

настройка dhcp-failover с помощью PowerShell

Теперь сменим конфигурацию, сначала отключив failover. Для этого в оснастке DHCP кликаем на область и выбираем пункт меню «Deconfigure Failover».

отключение dhcp-failover

Затем подтверждаем удаление доверительных отношений,

запрос на подтверждение отключения dhcp-failover

еще раз подтверждаем удаление

финальный запрос на отключение запрос на подтверждение отключения dhcp-failover

и ждем завершения. При удалении на сервере-партнере будут удалены все области, для которых был настроен failover.

завершение отключения dhcp-failover

Для удаления с помощью PowerShell достаточно выполнить одну команду:

Remove-DhcpServerv4Failover -Name ″srv1-srv2″ -Force

отключение dhcp-failover с помощью PowerShell

Теперь настроим DHCP failover в режиме Hot standby. Для этого опять запускаем мастер на SRV1 и выбираем сервер-партнер. Обратите внимание, что если между серверами ранее уже были настроены доверительные отношения, то их можно использовать повторно.

повторное включение dhcp-failover

Выбираем режим Hot standby и производим настройки. Для режима Hot standby они несколько отличаются:

• Role of Partner Server — серверы делятся на основной (Active) и резервный (Standby) и надо выбрать роль для  сервера-партнера. Если мы выбираем Standby, то текущий сервер соответственно становится Active, и наоборот.
• Addresses reserved for standby server — еще один важный параметр, задающий процент адресов, выделенный для резервного сервера. Суть этого параметра в том, что после выхода из строя основного сервера и перехода в состояние PARTNER_DOWN должно пройти время, заданное в параметре Maximum Client Lead Time. Только после этого резервный сервер забирает контроль над над всем диапазоном IP-адресов. В промежутке между этими двумя событиями резервный сервер может обслуживать клиентов, выдавая им адреса из данного резерва. Если этот параметр установить в ноль, то резервный сервер не сможет выдавать адреса до тех пор, пока не захватит всю область.

настройка параметров

Дальше все так же — проверяем настройки, подтверждаем их

подтверждение настроек

и ждем завершения.

завершение настройки

То же из консоли PowerShell:

Add-DhcpServerv4Failover -ComputerName srv1.test.local -Name ″srv1-srv2″ -PartnerServer srv2.test.local -ScopeId 10.0.0.0 -ReservePercent 10 -MaxClientLeadTime 00:10:00 -AutoStateTransition $true -StateSwitchInterval 00:10:00 -SharedSecret ″12345678″ -Force

настройка dhcp-failover с помощью PowerShell

Изменить настройки и режим работы DHCP failover можно ″на лету″, не удаляя текущую конфигурацию. Для этого в оснастке управления надо выбрать раздел IPv4 (или IPv6, если failover настраивался для этого протокола), кликнуть правой клавишей мыши и выбрать пункт «Properties».

переход к редактированию настроек dhcp-failover

Затем перейти на вкладку «Failover», выбрать доверительные отношения и нажать «Edit».

В открывшемся окне мы можем поменять абсолютно любые настройки и даже изменить режим работы failover-а, например перейти с Load Balance на Hot Standby.

А теперь с помощью PowerShell вернемся обратно к режиму балансировки, попутно изменив интервалы MaxClientLeadTime и StateSwitchInterval:

Set-DhcpServerv4Failover -Name ″srv1-srv2″ -Mode LoadBalance -LoadBalancePercent 80 -MaxClientLeadTime 00:02:00 -StateSwitchInterval 00:02:00 -Force

изменение режима работы dhcp-failover с помощью PowerShell

Тестирование работы DHCP failover

В завершение давайте протестируем работу DHCP failover. На предыдущем шаге мы уменьшили до 2 минут временные интервалы, отвечающие за переключение. Также для ускорения процесса в свойствах области уменьшим время аренды до 10 минут.

Теперь зайдем в свойства DHCP failover и проверим состояние серверов-партнеров.

Запомним полученные настройки на клиенте. Как видите, клиент имеет адрес 10.0.0.20, полученный с сервера 10.0.0.1 (SRV1).

текущее состояние клиента

Теперь погасим сервис DHCP на SRV1 и перейдем на SRV2. Здесь откроем оснастку DHCP и перейдем в настройки доверительных отношений. Как видите, после потери связи с партнером здесь стала активна кнопка ″Change to partner down″. С помощью этой кнопки можно перевести сервер в состояние PARTNER_DOWN, не дожидаясь пока истечет State Switcover Interval.

Еще раз проверяем состояние серверов. Резервный сервер перешел в состояние Partner down и готов к захвату контроля над областью.

Ждем 2 минуты и еще раз проверяем настройки на клиенте. Как можно увидеть, IP-адрес не изменился, при этом в качестве DHCP-сервера указан уже 10.0.0.2 (SRV2). Т.е. клиент успешно продлил на SRV2 аренду адреса, полученного от SRV1.

состояние клиента после отключения партнера

Возвращаем SRV1 в строй, ждем пока клиент обновит аренду и еще раз проверяем его настройки. Как видите, IP-адрес не изменился, а адрес DHCP-сервера опять SRV1.

состояние клиента после включения партнера

Вот так и работает DHCP-failover.

Добрый день. Может я не правильно понимаю ситуацию…. Так как делаю первый раз.
Есть DHCP сервер на windows 2016 с двумя областями (192.168.145.0 и 10.11.12.0).
У хоста DHCP один ip 10.11.12.13.
Windows DHCP не пробует отдавать адрес в область 192.168.145.0 если на хосте сервера dchp нет ip из 192.168.145.х.
Как только добавляешь — всё нормально работает. Это нормально? Неужели нужно будет выдумывать ip хосту если областей будет >50 например?
Пробовал объединять в суперобласть — не помогло.

Mikrotik настроен как DHCP Relay. В настройках relay указан dhcp server 10.11.12.13 и local адрес 192.168.145.66 (он есть и в ip>addresses и смотрит на порт с клиентами).
Проверил WireShark’ом:
1. Если есть доп ip:

5fddcbb2bc458446411326.jpeg

2. Если у DHCP только один ip (10.11.12.13)

5fddcc28b3344779628545.jpeg

Как видно ARP запроса от DHCP уже нет.


  • Вопрос задан

  • 1467 просмотров

Вопрос решен. Надеюсь, мои мытарства с этим, кому нибудь помогут не совершать ошибки на старте и не терять время. Всё оказалось намного проще…. но во всём есть нюансы и жаль, что в мануалах нет упоминания об этом.
Моя ошибка была в том, что я пытался скормить DHCP серверу запрос от relay пришедший не от шлюза. В моём лабораторном стенде у Windows Server вообще не было шлюза. Когда я указал ip MT как шлюз, всё стало на свои места.
А помогло просто банально вдумчивое рассмотрение этой картинки:

cng16_overview.jpg

Пригласить эксперта

у вас есть VLANы ?
в правильном интерфейсе висит relay на MT ?
является ли MT gateway в обеих сетях ?

Войдите, чтобы написать ответ


  • Показать ещё
    Загружается…

Минуточку внимания

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

Содержание

  • DHCP сервер Windows 2016 не раздает адреса
  • История аренды IP-адресов на DHCP сервере
  • История аренды IP-адресов на DHCP сервере
  • Постановка задачи
  • Как найти историю аренды ip-адресов DHCP
    • Рекомендуем к прочтению

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: смешивать, но не взбалтывать».

Поиск сетевых сервисов. Например, принтеров. Пожалуй, самым известным протоколом является UPnP, который помимо прочего умеет сам открывать порты на роутерах. Протокол довольно сложен, в нем используется целый набор надстроек вроде использования http, в отличие от второго известного протокола — DNS-SD (DNS Service Discovery), который попросту использует SRV-записи, в том числе при работе mDNS.

При всех плюсах 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 пакетов».

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

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

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

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

В этом разделе я рассмотрю практическое применение опций DHCP на оборудовании MikroTik. Сразу обращу внимание на то, что не все опции задаются очевидно, формат параметров описан в wiki. Следует отметить также то, что опции клиент применяет, только когда сам их попросит. В некоторых серверах можно принудительно отправить настройки: например, в ISC DHCP Server за это отвечает директива dhcp-parameter-request-list, а в Dnsmasq —* *—dhcp-option-force. MikroTik и Windows такого не умеют.

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 активно используется в системе биллинга провайдеров и при защите сети от посторонних вмешательств. Об этом чуть подробнее.

Ввиду простоты протокола и присутствия широковещательных запросов есть эффективные атаки на инфраструктуру — в основном типа MITM («человек посередине»). Атаки производятся посредством поднятия своего DHCP-сервера или релея: ведь если контролировать выдачу сетевых настроек, можно запросто перенаправить трафик на скомпрометированный шлюз. Для облегчения атаки используется DHCP starvation (представляясь клиентом или релеем, злоумышленник заставляет «родной» DHCP-сервер исчерпать свои IP-адреса). Подробнее про реализацию атаки можно почитать в статье «Атакуем DHCP», методом же защиты является DHCP Snooping.

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

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

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

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

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

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

К другим методам защиты можно отнести Port Security («привязка» определенного MAC-адреса к порту маршрутизатора, при обнаружении трафика с других адресов порт будет блокироваться), Анализ трафика на количество DHCP-запросов и ответов или ограничение их количества, ну и, конечно, различные системы IPSIDS.

Если говорить не только о защите сети, но и о надежности, то не лишним будет упомянуть и про возможности отказоустойчивого 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 сервере

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

Добрый день! Уважаемые читатели и гости одного из популярнейших IT блогов Pyatilistnik.org. В прошлый раз мы с вами разобрали тему по отключению защитника Windows 8.1. Сегодня мы разберем интересную тему по системному администрированию, а именно, как и где посмотреть историю аренды IP-адресов на сервере DHCP в Windows. Я расскажу вам сценарии, при которых эти знания окажутся для вас весьма полезными и необходимыми, да и вообще инженеры очень редко смотрят и изучают логи DHCP сервера.

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

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

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

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

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

Переходим в каталог C:Windowssystem32dhcp. Тут будут нужные нам файлы DhcpSrvLog.log. таких файлов будет 7, на каждый день недели.

Открыв файл вам сразу выскочит подсказка по кодам событий:

  • 00 Ведение журнала начато.
  • 01 Ведение журнала остановлено.
  • 02 Ведение журнала временно приостановлено из-за нехватки места на диске.
  • 10 Клиенту выдан новый IP-адрес.
  • 11 Аренда продлена клиентом.
  • 12 Аренда отменена клиентом.
  • 13 IP-адрес уже используется в сети.
  • 14 Запрос на аренду не может быть удовлетворен, так как исчерпан пул адресов этой области.
  • 15 В аренде отказано.
  • 16 Аренда удалена.
  • 17 Срок аренды истек, а DNS-записи для истекших аренд не удалены.
  • 18 Срок аренды истек, и DNS-записи удалены.
  • 20 Клиенту выдан BOOTP-адрес.
  • 21 Клиенту выдан динамический BOOTP-адрес.
  • 22 Не удалось удовлетворить запрос на выдачу BOOTP-адреса, так как исчерпан пул адресов для BOOTP.
  • 23 IP-адрес BOOTP удален, так как он не используется.
  • 24 Начата очистка IP-адресов.
  • 25 Статистика очистки IP-адресов.
  • 30 Запрос на обновление DNS к именованному DNS-серверу.
  • 31 Сбой обновления DNS.
  • 32 Успешное обновление DNS.
  • 33 Пакет отброшен в соответствии с политикой NAP.
  • 34 Сбой запроса на обновление DNS. Превышено ограничение для очереди запросов на обновление DNS.
  • 35 Сбой запроса на обновление DNS.
  • 36 из-за несоответствия хэша ИД клиента или того, что сервер находится в режиме ожидания обработки отказа.
  • 50+ Коды выше 50 используются для сведений о выявленных неавторизованных серверах.
  • 11000 Обращение DHCPv6.
  • 11001 Объявление DHCPv6.
  • 11002 Запрос DHCPv6.
  • 11003 Подтверждение DHCPv6.
  • 11004 Обновление DHCPv6.
  • 11005 Повторная привязка DHCPv6.
  • 11006 Отклонение DHCPv6.
  • 11007 Освобождение DHCPv6.
  • 11008 Запрос информации DHCPv6.
  • 11009 Заполнение области DHCPv6.
  • 11010 Запуск DHCPv6.
  • 11011 Остановка DHCPv6.
  • 11012 Приостановка журнала аудита DHCPv6.
  • 11013 Файл журнала DHCPv6.
  • 11014 Недопустимый DHCPv6-адрес.
  • 11015 DHCPv6-адрес уже используется.
  • 11016 DHCPv6-клиент удален.
  • 11017 DNS-запись DHCPv6 не удалена.
  • 11018 Срок действия DHCPv6 истек.
  • 11019 Устаревшие и удаленные аренды DHCPv6.
  • 11020 Начало очистки базы данных DHCPv6.
  • 11021 Окончание очистки базы данных DHCPv6.
  • 11022 Запрос обновления DNS для IPv6.
  • 11023 Сбой обновления DNS для IPv6.
  • 11024 Успешное обновление DNS для IPv6.
  • 11028 Сбой запроса обновления DNS для IPv6. Превышен предел очереди запросов на обновление DNS.
  • 11029 Сбой запроса обновления DNS для IPv6.
  • 11030 Записи DHCPv6-клиента без отслеживания состояния очищены.
  • 11031 Запись DHCPv6-клиента без отслеживания состояния очищена, так как для нее истек интервал очистки.
  • 11032 Запрос информации DHCPV6 с IPv6-клиента без отслеживания состояния.

Вот для примера, как выглядит продление аренды адреса.

Данная статья описывает процедуру установки и настройки DHCP сервера на базе Windows Server 2019. В статье описаны особенности установки и настройки DHCP роли, создания областей DHCP, настройки их параметров и резервации статических адресов. Мы рассмотрим как привычный способ настройки параметров DHCP сервера через графическую консоль, так и настройку DHCP из командной строки PowerShell.

Протокол DHCP (Dynamic Host Configuration Protocol) используется для автоматического назначения сетевых настроек (IP адрес, маска подсети, шлюз, DNS сервера и т.д.) устройствам в вашей сети (компьютеры, ноутбуки, сканеры, принтеры и т.д.). Также DHCP сервер позволяет более эффективно использовать адресное пространство, избегать конфликта IP адресов в сети и централизованно управлять сетевыми параметрами на клиентских устройствах.

Содержание:

  • Установка роли DHCP сервера в Windows Server 2019/2016
  • Настройка DHCP областей в Windows Server
  • Резервация IP адресов на DHCP сервере
  • Настройка и управление DHCP сервером с помощью PowerShell

Установка роли DHCP сервера в Windows Server 2019/2016

В этом примере мы установим DHCP сервер на хосте с Windows Server 2019 и IP адресом 192.168.13.4. Вы можете использовать как Server Core версию, так и Full GUI. В маленькой инфраструктуре допустимо устанавливать DHCP сервер на сервер с ролью контроллера домена Active Directory.

Обязательно назначьте статический IP адрес серверу с ролью DHCP сервер. При установке роли DHCP из консоли PowerShell на сервере с автоматическим получением IP адреса появляется предупреждение:

Configure at least one static IP address on your computer before installing DHCP.
WARNING: The following recommended condition is not met for DHCP: No static IP addresses were found on this computer. If the IP address changes, clients might not be able to contact this server. Please configure a static IP address before installing DHCP Server.

Установить роль DHCP Server можно из консоли Server Manager (Add Roles and Features -> Server Roles).

установка роли DHCP server в windows server 2019

После установки роли DHCP роли нужно выполнить Post-Deployment Configuration. Для этого в консоли Server Manager щелкните по уведомлению и выберите Complete DHCP configuration.

выберите Complete DHCP configuration

Вам будет предложено аутентифицировать новый DHCP сервер в Active Directory (экран Authorization). Для авторизации DHCP сервера в AD учетная запись должна состоять в доменной группе Enterprise Admins.

Если у вас нет прав на авторизацию DHCP в AD, вы можете указать, чтобы ваш DHCP сервер запускался без проверки авторизации в домене:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters" -Name DisableRogueDetection -Value 1 -Force

авторизовать сервер DHCP в Active Directory

Также вы можете установить и настроить DHCP роль в Windows Server из консоли PowerShell.

Установка роли DHCP:

Install-WindowsFeature DHCP –IncludeManagementTools

Проверьте, что роль и инструменты управления RSAT-DHCP установлены:

Get-WindowsFeature -Name *DHCP*| Where Installed

установка DHCP сервера с помощью powershell

Авторизуйте DHCP сервер в Active Directory (укажите DNS имя сервера и IP адрес, который будет использоваться DHCP клиентами):

Add-DhcpServerInDC -DnsName hq-dc01.contoso.com -IPAddress 192.168.13.4

Создайте локальные группы безопасности DHCP сервера:

Add-DhcpServerSecurityGroup

Чтобы Server Manager перестал показывать уведомление о том, что DHCP роль требует настройки, выполните команду:

Set-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\ServerManager\Roles\12 -Name ConfigurationState -Value 2

Перезапустите службу DHCPServer:

Restart-Service -Name DHCPServer -Force

База данных и логи DHCP сервера находятся в каталоге
%systemroot%\system32\dhcp
.

  • dhcp.mdb — файл базы данных сервера DHCP’;
  • j50.log – транзакционный журнал (используется при восстановлении конфигурации DHCP);
  • j50.chk — файл контрольной точки;
  • tmp.edb — временный рабочий файл DHCP-сервера.

Настройка DHCP областей в Windows Server

После установки роли DHCP вам нужно создать DHCP области (Scopes), которые описывают диапазоны IP адресов и другие настройки, выдающиеся сервером клиентам.

Для управления сервером DHCP используется консоль dhcpmgmt.msc (вы можете управлять DHCP сервером локально или с удаленного компьютера с установленным RSAT). Запустите консоль DHCP, разверните ваш сервер -> IPv4.

Чтобы создать новую область выберите New Scope.

создать новую dhcp область

Укажите название DHCP области.

название DHCP области

Укажите диапазон IP адресов, который будет выдаваться этой областью и маску сети. В этом примере я хочу использовать эту DHCP область для обслуживания подсети 192.168.100.0/24. В рамках этой сети DHCP сервером будет назначаться динамические IP адреса из диапазона 192.168.100.50 — 192.168.100.250. В следующем окне можно добавить исключения в этот диапазон (Add Exclusions and Delay).

диапазон IP адресов области DHCP

Далее нужно указать длительность аренды (Lease Duration) IP адреса DHCP клиентом (по умолчанию 8 дней, менять без особой необходимости не нужно).

срока аренды адреса на dhcp

Укажите, что вы хотите настроить дополнительный параметры DHCP области.

настроить опции dhcp области

.

Укажите IP адрес шлюза в подсети, который должен назначаться клиентам (в нашем примере это 192.168.100.1).

задать адрес шлюза по-умолчанию для dhcp области

Затем укажите имя домена и адреса DNS серверов, которые будут назначены клиентам DHCP.

настройки DNS для DHCP области

Осталось активировать DHCP область (разрешить ей обслуживать клиентов).

активировать DHCP зону

DHCP сервер может выдавать клиентам различный настройки (кроме IP адреса). Для этого используются Scope Options.

В Windows Server DHCP можно настроить глобальные настройки области или Scope Options для каждой области.

опции DHCP scope

Ранее мы уже настроили три опции области:

  • 003 Router
  • 006 DNS Server
  • 015 DNS Domain Name

Можно добавить и другие опции (NTP сервера, PXE и т.д.).

В разделе Server Options DHCP сервера можно настроить глобальные опции, которые будут наследуются всеми областями. Но вы можете переопределить глобальные настройки в настройках каждой области (опции области имеют приоритет над опциями сервера).

настроить параметры DHCP сервера

Один DHCP сервер может обслуживать сотни удаленных подсетей и VLAN. Поэтому вы можете создать на нем несколько областей. Главное, чтобы в каждой из подсетей был настроен ретранслятор (DHCP relay agent), который пересылает широковещательные DHCP-запросы на указанный DHCP сервер. В терминах Cisco DHCP ретранслятор называется ip helper. Вы можете настроить DHCP Relay даже на Windows Server.

Протокол DHCP в качестве транспорта использует протокол UDP. Пакеты от клиента к серверу передаются по порту 67 UDP, обратно через UDP 68

Резервация IP адресов на DHCP сервере

По умолчанию DCHP сервер выдает клиентам динамические адреса. Это означает что IP адрес у любого клиента может меняться. Если вы хотите, чтобы определенные устройства всегда получали от DHCP сервера один и тот же адрес, вы можете его зарезервировать (например, для сетевых принтеров, которые настроены у пользователей).

Для DHCP резервации выберите область и перейдите в секции Reservation. В меню выберите New Reservation.

При создании резервации нужно указать IP адрес, который нужно сохранить за клиентом и его MAC адрес (уникальное значение). MAC адрес в Windows можно получить из результатов команды
ipconfig /all
или с помощью PowerShell
get-netadapter|select name,macaddress
). Опционально можно указать имя и описание устройства.

Укажите MAC адрес устройства для резервации IP адреса на DHCP

Также вы можете зарезервировать текущий динамический адрес за устройством, найдя его в разделе Address Leases. Щелкните по устройству и выберите Add to Reservation.

Add to Reservation

Настройка и управление DHCP сервером с помощью PowerShell

Все операции по настройке и управлению DHCP сервером на Windows Server 2019/2016 можно выполнять из консоли PowerShell. Рассмотрим основные команды управления DHCP. Для этого используется модуль DHCPServer. Импортируйте модуль в сессию:

Import-Module DHCPServer

Вывести полный список командлетов в моделе DHCP можно так:

Get-Command -Module DHCPServer

PowerShell модуль DHCPServer

Следующая команда выведет список авторизованных DHCP серверов в Active Directory:

Get-DhcpServerInDC

Вывести список DHCP областей на указанном сервере:

Get-DhcpServerv4Scope –ComputerName msk-dhcp1

Если нужно показать все параметры области (Delay, Description, Name и т.д.):

Get-DhcpServerv4Scope –ComputerName msk-dhcp1| FL *

Список областей на DHCP сервере

Если нужно отобразить данные о IPv6 областях:

Get-DHCPServerv6Scope

Получить настройки для конкретной области:

Get-DhcpServerv4Scope –ComputerName msk-dhcp1 –ScopeID 10.10.1.0

Создадим новую (неактивную) область с диапазоном адресов с 192.168.113.50 до 192.168.113.250:

Add-DhcpServerv4Scope -Name “Brahch1 192.168.113.0” -StartRange 192.168.113.50 -EndRange 192.168.113.250 -SubnetMask 255.255.255.0 -State InActive

Настроить следующие параметры DHCP сервера: DNS сервер, домен и адрес шлюза по-умолчанию:

Set-DhcpServerv4OptionValue -ScopeID 192.168.113.0 -DnsDomain contoso.com -DnsServer 192.168.13.4 -Router 192.168.113.1

Добавить исключения в DHCP область:

Add-DhcpServerv4ExclusionRange -ScopeID 192.168.113.0 -StartRange 192.168.113.90 -EndRange 192.168.113.100

Активировать DHCP область:

Set-DhcpServerv4Scope -ScopeID 192.168.113.0 -State Active

Add-DhcpServerv4Scope - создать и настроить области на DHCP сервере командами PowerShell

Для удобства можно использовать такую команду PowerShell при создании новой области:

$HashArgs = @{
'Name' = 'EKB Office Scope';
'Description' = 'workstations';
'StartRange' = '192.168.140.10';
'EndRange' = '192.168.140.200';
'SubnetMask' = '255.255.255.0';
'State' = 'Active';
'LeaseDuration' = '1.00:00:00';
}
Add-DhcpServerv4Scope @HashArgs

Опции для DHCP сервера добавляется так (к примеру, WPAD):

Add-DhcpServerv4OptionDefinition -ComputerName msk-dhcp1 -Name WPAD -OptionId 252 -Type String

Вывести список настроенных опций DHCP сервера можно так:

Get-DHCPServerv4OptionValue -ComputerName msk-dhcp1 | Format-List

Выведем список настроенных параметров зоны:

Get-DHCPServerv4OptionValue -ComputerName msk-dhcp1 -ScopeId 10.10.1.0 | Format-List

Показать текущий список арендованных адресов для области 10.10.1.0:

Get-DHCPServerv4Lease -ScopeId 10.10.1.0 -ComputerName msk-dhcp1

Список аренд на DHCP сервере

Создать DHCP резервацию для клиента, которому назначен динамический IP адрес 10.10.1.88 (конвертировать выданный адрес в зарезервированный):

Get-DhcpServerv4Lease -ComputerName msk-dhcp1 -IPAddress 10.10.1.88| Add-DhcpServerv4Reservation -ComputerName msk-dhcp1

Можно массово зарезервировать IP адреса для компьютеров по списку из csv файла. Для этого создайте текстовый файл в формате:

ScopeId,IPAddress,Name,ClientId,Description
10.10.1.0,10.10.1.88,Client1,ba-ab-5c-3d-4e-6f,Reservation PC-msk-s1
10.10.1.0,10.10.1.89,Client2,ba-ab-5c-5d-2e-3f,Reservation PC-msk-s2

Сохраните файл с именем
c:\dhcp\DHCPReservations.csv
и запустите следующую команду, которая импортирует данные из csv файла и создаст DHCP резервации для клиентов:

Import-Csv –Path c:\dhcp\DHCPReservations.csv | Add-DhcpServerv4Reservation -ComputerName msk-dhcp1

Отключить область на DHCP сервере:

Set-DhcpServerv4Scope -ComputerName msk-dhcp1-ScopeId 10.10.1.0-State InActive

Удалить область с DHCP сервера:

Remove-DHCPServerv4Scope -ComputerName msk-dhcp1-ScopeId 10.10.1.0 -Force

Возможно получить статистику DHCP сервера (количество областей, резерваций, процент использования адресов и пр.).

Get-DhcpServerv4Statistics -ComputerName msk-dhcp1

Статистика использования DHCP сервера

Аналогичная информация для конкретной области может быть получена с помощью командлета Get-DhcpServerv4ScopeStatistics.

Конфигурацию DHCP сервера можно экспортировать в указанный XML файл с помощью команды:

Export-DHCPServer -ComputerName msk-dhcp1 -File C:\dhcp\dhcp-export.xml

Совет. Заданием с такой командой в планировщике задач можно реализовать регулярное резервное копирование конфигурации DHCP сервера.

В дальнейшем эти настройки DHCP сервера можно импортировать (перенести) на другой DHCP сервер:

Import-DHCPServer -ComputerName msk-dhcp2 -File C:\dhcp\dhcp-export.xml -BackupPath C:\dhcpbackup\

Понравилась статья? Поделить с друзьями:
0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
  • Сколько должно быть фоновых процессов windows 10
  • Как использовать ssh на windows 10
  • Для создания новой папки в программе windows commander надо нажать на клавиатуре кнопку
  • После обновления windows 10 не видит hdmi
  • Как выйти из синего экрана смерти windows 7