DHCP failover в Windows Server 2025: что реплицируется автоматически, а что нужно синхронизировать вручную

У одного из наших клиентов на 42 рабочих местах прошлым летом развернули Windows Server 2025 и включили DHCP failover в режиме Hot Standby между двумя площадками. Через три месяца бухгалтерия пожаловалась: сетевой принтер в допофисе «переехал» на другой адрес после планового обслуживания основного контроллера. Резервация для принтера была — но только на одном из двух серверов пары. Ниже — разбор, что в DHCP failover реплицируется автоматически, а что нужно репликнуть руками, и как мы в АйТи Фреш закрыли этот разрыв регламентом, а не проверкой «на глаз».

Кейс: резервация есть, а на партнёре её не существует

Схема у клиента типовая для наших проектов на 30–50 рабочих мест: два сервера DHCP на Windows Server 2025, отношение failover в режиме Hot Standby, имя отношения условно «HQ-Reserve», активная область 10.20.30.0/24 с длительностью аренды 8 дней по умолчанию. Резервацию для сетевого МФУ бухгалтерии администратор клиента добавил командой Add-DhcpServerv4Reservation на основном сервере — том, что в паре считается активным (ServerRole Active). Принтер получил постоянный адрес, всё работало полгода.

Проблема вскрылась не сразу, а именно при плановом обслуживании: основной сервер вывели в перезагрузку на патчинг вне окна декларативного failover (без вызова Set-DhcpServerv4Failover -State PartnerDown), партнёр по счётчику State Switchover Interval перевёл себя в роль обслуживающего, и в какой-то момент цикла аренды МФУ получил уже другой адрес из общего пула — потому что на втором сервере записи резервации для его MAC попросту не существовало. Для принтера это означало разрыв всех прописанных вручную маршрутов печати на рабочих местах, для нас — повод разобрать протокол failover заново и превратить разбор в регламент.

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

Что физически передаёт протокол DHCP failover

DHCP failover в Windows Server (доступен с 2012 R2, без изменений в базовой модели до 2025) построен поверх черновика IETF по failover-протоколу DHCP и работает по TCP через порт 647 для управляющего канала между партнёрами. По этому каналу передаются два типа сообщений о состоянии аренды — BNDUPD (Binding Update) и BNDACK (Binding Acknowledgement). Они несут конкретную запись о привязке: IP-адрес, идентификатор клиента, время истечения аренды, статус привязки (ACTIVE, EXPIRED, FREE, BACKUP, PENDING). Это и есть то самое «состояние», которое синхронизируется у партнёров почти в реальном времени — отсюда ощущение, что failover «реплицирует всё».

Конфигурация области — границы диапазона, список исключений, резервации, DHCP-опции (003 Router, 006 DNS Servers, 015 DNS Domain Name, 051 Lease и т.д.), политики на основе MAC-адреса или vendor class — в этот обмен не входит. Она живёт в локальной базе DHCP-сервера (JET-база в %systemroot%\System32\dhcp) отдельно на каждом узле пары и протоколом BNDUPD/BNDACK не затрагивается вовсе. Официальная позиция Microsoft по этому разделению прямая: аренды реплицируются автоматически, а при изменении опций области, резерваций, политик или исключений нужно принудительно инициировать репликацию конфигурации отдельной командой.

Второй важный технический факт: DHCP failover в Windows Server существует только для IPv4. Для DHCPv6 такого механизма нет в принципе — если в инфраструктуре есть выдача IPv6-адресов через DHCP, для неё придётся проектировать отказоустойчивость отдельно (сплит скоупов, RA-based резервирование и т.д.), это не входит в тему конкретной пары failover-серверов.

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

Таблица: что реплицируется автоматически, а что требует ручной команды

Мы собрали для внутреннего регламента таблицу, которую теперь показываем клиентам на каждом внедрении DHCP failover — она снимает главное заблуждение за одну минуту.

Практический вывод из этой таблицы: единственное, что администратор может спокойно не трогать руками — сами выданные адреса. Всё, что он вводит через консоль DHCP или PowerShell как настройку, требует либо повторения на обоих серверах, либо явного вызова репликации.

Механика отказа: почему принтер всё-таки словил чужой адрес

Здесь стоит разобрать до конца, почему проблема не проявляется мгновенно после создания резервации без репликации — иначе у инженеров складывается ложное чувство безопасности. Пока активный сервер жив и именно он отвечает на DHCPREQUEST принтера, резервация применяется корректно: сервер видит MAC в своей локальной таблице резерваций и всегда выдаёт один и тот же адрес. Сама аренда (уже как факт binding) при этом реплицируется партнёру как обычная активная запись — но без пометки «эта запись закреплена резервацией», потому что привязка (binding) и резервация (reservation) в модели DHCP-сервера — разные сущности, и по протоколу failover передаётся только первая.

Момент разрыва наступает не при переключении партнёра как таковом, а при следующем полном цикле DHCPDISCOVER для этого клиента — например, после перезагрузки принтера с очисткой текущей аренды, после длительного простоя дольше срока аренды, или после сетевого конфликта, из-за которого клиент стартует заново, а не продлевает (REBIND/RENEW) существующий адрес. Если в этот момент обслуживающим остаётся сервер без резервации, он обращается с MAC-адресом принтера как с обычным динамическим клиентом и может выдать любой свободный адрес из пула — в нашем случае так и произошло на второй день после переключения, когда МФУ ушёл в спящий режим и затем поднялся заново.

Отдельно отметим: сама по себе точная последовательность пакетов, при которой происходит расхождение, зависит от состояния DHCP-клиента конкретного устройства (принтеры и сетевые ИБП нередко реализуют DHCP-стек упрощённо и чаще уходят в полный DISCOVER, чем ноутбуки с корректным REBIND) — это наблюдение из практики диагностики, а не заявление из документации Microsoft, поэтому фиксируем его как оценочное, не как гарантированный протоколом сценарий.

Практический вывод для проектирования области: если в сегменте много устройств с упрощённым DHCP-стеком (принтеры, ИБП, точки доступа, промышленные контроллеры), закладывать нужно не только репликацию резерваций после создания, но и повторную сверку после каждого планового или внепланового перехода партнёра в роль обслуживающего — именно в первые часы после переключения риск максимален, потому что часть устройств в сегменте неизбежно проходит полный цикл получения адреса заново.

Диагностика: как быстро увидеть расхождение между партнёрами

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

Get-DhcpServerv4Failover -ComputerName SRV-DHCP01 |
  Format-List Name, PartnerServer, Mode, ScopeId, State,
              MaxClientLeadTime, StateSwitchInterval, AutoStateTransition

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

$scope = '10.20.30.0'
$r1 = Get-DhcpServerv4Reservation -ComputerName SRV-DHCP01 -ScopeId $scope
$r2 = Get-DhcpServerv4Reservation -ComputerName SRV-DHCP02 -ScopeId $scope
Compare-Object $r1 $r2 -Property IPAddress, ClientId, Name -PassThru |
  Select-Object IPAddress, ClientId, Name, SideIndicator

Если в выводе есть строки с SideIndicator отличным от совпадения по обеим сторонам — резервация присутствует только на одном сервере пары, и это именно тот класс расхождения, который взорвался у нас с МФУ. Такой же принцип сверки применяем к опциям области через Get-DhcpServerv4OptionValue -ScopeId и к исключениям через Get-DhcpServerv4ExclusionRange -ScopeId.

Полезно смотреть и журнал событий — DHCP-сервер в Windows Server 2025 ведёт два отдельных канала в разделе Applications and Services Logs \ Microsoft \ Windows \ DHCP-Server: канал Admin (переходы состояния failover, смена ролей партнёров) и канал Operational (аудит изменений конфигурации, включая добавление и удаление областей из отношения failover). Практическая команда для быстрой проверки последних расхождений синхронизации:

Get-WinEvent -LogName 'Microsoft-Windows-DHCP Server Events/Admin' -MaxEvents 100 |
  Where-Object Id -in 20291, 20292 |
  Select-Object TimeCreated, Id, Message

Событие 20291 в этом канале соответствует отказу партнёра принять BINDING-ACK с неизвестной причиной (обычно рассинхронизация состояния аренды между узлами), событие 20292 — получению устаревшей информации о привязке. Оба события сигнализируют о проблемах на уровне протокола репликации аренд и требуют внимания сами по себе, но они не покажут расхождение в резервациях или опциях — за это в журнале конкретного события нет, поэтому ручная сверка через PowerShell остаётся обязательной, журнал её не заменяет.

Ручная репликация конфигурации: команда и её границы

Основной инструмент для принудительной синхронизации конфигурации — Invoke-DhcpServerv4FailoverReplication. Он реплицирует конфигурацию области (включая резервации, опции, исключения и политики) с сервера, на котором выполняется команда, на партнёра по указанному отношению failover.

# Реплицировать конкретную область на партнёра по отношению
Invoke-DhcpServerv4FailoverReplication -ComputerName SRV-DHCP01 -ScopeId 10.20.30.0 -Force

# Реплицировать все области, входящие в отношение целиком
Invoke-DhcpServerv4FailoverReplication -ComputerName SRV-DHCP01 -Name 'HQ-Reserve' -Force

Направление здесь важно: команда выполняется на том сервере, чья версия конфигурации считается актуальной, и репликация идёт с него к партнёру. Если запустить её со стороннего сервера в обратной ситуации, можно случайно затереть более свежие резервации на другом узле — поэтому перед массовым запуском мы всегда сначала делаем сверку через Compare-Object, как в предыдущем разделе, и только потом решаем, какой сервер считать источником истины.

Ограничение, о котором часто забывают: Invoke-DhcpServerv4FailoverReplication реплицирует конфигурацию только для областей, уже включённых в отношение failover. Если администратор создал новую область на одном сервере и не выполнил для неё Add-DhcpServerv4Failover -ScopeId <новый ScopeId> -Name <имя существующего отношения>, эта область не появится на партнёре вообще — ни аренды, ни конфигурация, потому что она формально не состоит в отношении. Это вторая по частоте причина «пропавших» настроек DHCP, которую мы видим после того, как клиент сам добавляет VLAN и область под новый сегмент, не подключая её к существующей паре failover.

Параметры отношения, которые определяют цену ошибки

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

Maximum Client Lead Time (MCLT) — время, на которое любой из партнёров может самостоятельно продлить аренду клиенту, не связываясь с другим партнёром. По умолчанию это 1 час, и в нуль его установить нельзя — ноль ломает саму логику протокола. Чем больше MCLT, тем дольше сервер, взявший на себя обслуживание после сбоя партнёра, продолжает работать по последним известным данным без дополнительной проверки — в том числе без знания о резервациях, которые не были реплицированы.

Auto State Switchover Interval (StateSwitchInterval) — время, через которое сервер, потерявший связь с партнёром, автоматически переводит себя из COMMUNICATION-INTERRUPTED в PARTNER-DOWN и начинает обслуживать клиентов партнёра самостоятельно. По умолчанию тоже 60 минут. Именно этот таймер сработал в нашем кейсе с МФУ: сервер решил, что партнёр не вернётся, и стал единственным источником конфигурации для сегмента — со всеми пробелами, которые в его локальной базе успели накопиться.

Для сценариев, где резервации критичны (принтеры, сетевое оборудование, ИБП, точки доступа с фиксацией по MAC), мы рекомендуем не увеличивать StateSwitchInterval бездумно «для надёжности» — это только отодвигает момент обнаружения рассинхронизации, а не устраняет её причину.

Регламент ITfresh: как мы предотвращаем повтор у клиентов

После разбора кейса с МФУ мы изменили типовой чек-лист внедрения DHCP failover для клиентов на Windows Server 2025 и добавили туда три обязательных пункта, которых раньше не было отдельной строкой.

1. Еженедельная сверка конфигурации по расписанию. На основном DHCP-сервере через планировщик задач запускаем PowerShell-скрипт, который для каждой области в отношении failover сравнивает резервации, опции и исключения на обоих партнёрах через Compare-Object (тот же принцип, что в разделе диагностики) и при расхождении отправляет отчёт администратору до того, как оно проявится на реальном устройстве.
2. Вызов репликации конфигурации сразу после любого изменения области. Правило для инженеров: любая команда Add-DhcpServerv4Reservation, Set-DhcpServerv4OptionValue, Add-DhcpServerv4ExclusionRange или создание Policy для области, состоящей в failover, обязательно завершается вызовом Invoke-DhcpServerv4FailoverReplication -ScopeId <ScopeId> -Force в той же сессии, без переноса «на потом».
3. Подключение новых областей к отношению в тот же день, когда область создана. Если область не связана с существующим отношением failover командой Add-DhcpServerv4Failover, она в принципе не защищена — ни по арендам, ни по конфигурации, и это фиксируется отдельным пунктом в акте по итогам работ у клиента, чтобы не потеряться в общем списке задач.

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

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

Аварийный сценарий: когда репликация не спасает и нужен полный экспорт

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

# На сервере, чья конфигурация считается актуальной
Export-DhcpServer -ComputerName SRV-DHCP01 -Leases -File C:\dhcp-export\srv01-full.xml

# На партнёре: сначала останавливаем службу DHCP,
# затем импортируем с заменой существующих областей
Import-DhcpServer -ComputerName SRV-DHCP02 -Leases -File C:\dhcp-export\srv01-full.xml -BackupPath C:\dhcp-import-backup -ScopeOverwrite

Export-DhcpServer без параметров ScopeId/Prefix выгружает конфигурацию сервера целиком — все области IPv4 и IPv6, серверные настройки, и при указанном ключе -Leases также текущие данные аренд. Это тяжёлая операция, которую мы не используем как рутинный инструмент синхронизации (для этого есть Invoke-DhcpServerv4FailoverReplication), а держим как процедуру для пересборки партнёра с нуля или как проверенный источник для DR-восстановления DHCP-роли на новом сервере.

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

Частые вопросы

Реплицируются ли опции сервера (Server Options), а не только опции области?

Нет. Server Options действуют в области видимости конкретного DHCP-сервера и в протокол failover не входят вовсе — их нужно настраивать отдельно на каждом партнёре командой Set-DhcpServerv4OptionValue без указания ScopeId, либо синхронизировать сравнением конфигурации вручную. Это тот же принцип, что и с опциями области, просто на другом уровне иерархии настроек DHCP-сервера.

Что произойдёт с устройством, если резервация есть только на активном сервере, а он выйдет из строя?

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

Как часто нужно вызывать Invoke-DhcpServerv4FailoverReplication вручную?

Правильная практика — сразу после каждого изменения конфигурации области (новая резервация, опция, исключение, политика), а не по расписанию раз в день или неделю. Расписание имеет смысл держать как контрольную сверку на случай пропущенного вызова, а не как основной механизм синхронизации: между плановыми запусками расхождение может успеть повлиять на реальное устройство.

Работает ли DHCP failover для IPv6-областей?

Нет, DHCP failover в Windows Server реализован только для IPv4. Для отказоустойчивости DHCPv6, если он используется в инфраструктуре, нужны другие подходы (разделение диапазонов между серверами, механизмы на уровне SLAAC/Router Advertisement) — в рамках одного отношения failover они не закрываются.

Можно ли настроить регулярную автоматическую сверку конфигурации без стороннего ПО, только штатными средствами Windows Server 2025?

Да. Мы используем именно этот подход: PowerShell-скрипт на базе Get-DhcpServerv4Reservation, Get-DhcpServerv4OptionValue и Get-DhcpServerv4ExclusionRange с обеих сторон отношения, сравнение через Compare-Object и запуск по расписанию планировщика заданий Windows с отправкой отчёта при расхождении. Дополнительное ПО для этого не требуется, важна только дисциплина внедрения и подключения в общий мониторинг инфраструктуры.