Резервирование адресов dhcp windows server 2012

В случае отказа сервера DHCP и невозможности быстро вернуть его в строй компьютеры не могут получить доступ к сети, потому что у них нет действительных IP-адресов. И если у вас отсутствуют средства мониторинга, вероятно, вы узнаете о сбое DHCP, только когда возрастет число пользователей с самоназначаемыми IP-адресами в диапазоне действия службы Automatic Private IP Addressing (APIPA).

В предыдущих версиях Windows, таких как Windows Server 2008 R2 и Windows Server 2003, у нас было две основные возможности для обеспечения высокой доступности протокола DHCP.

— Установить сервер DHCP на отказоустойчивом кластере, а информация о настройке при этом хранится в общей папке.

— Настроить разделенные области адресов. При настройке область адресов разделяется таким образом, что 80% диапазона используется для аренды адресов на первичном сервере DHCP отдельной подсети, чтобы отвечать на запросы клиентов. Оставшиеся 20% адресов аренды находятся на сервере DHCP удаленной подсети. Эти адреса используются клиентами только тогда, когда DHCP-сервер с 80% адресов недоступен.

Windows Server 2012 облегчает доступность DHCP, предоставляя функцию отказоустойчивости протокола DHCP в служебной роли DHCP. Отказоустойчивость DHCP позволяет обеспечить высокую доступность службы DHCP без настройки разделенных областей или развертывания отказоустойчивого кластера. Сначала я подробно расскажу о новой функции, а потом покажу, как ее настроить.

Условие отказоустойчивости DHCP

Отказоустойчивость DHCP подразумевает настройку двух компьютеров Server 2012 со служебной ролью DHCP и установку их в паре. Эта пара способна обеспечить высокую доступность DNS, благодаря следующим техническим возможностям.

*Режим балансировки нагрузки (Load balance mode). Режим балансировки нагрузки (в документации он иногда называется режимом распределения нагрузки, load sharing mode) – это способ настройки отказоустойчивости DHCP по умолчанию. Когда вы настраиваете два сервера DHCP в режиме балансировки нагрузки, каждый сервер будет предоставлять IP-адреса из одной и той же области, и при этом адреса не дублируются. Балансировка нагрузки позволяет каждому серверу выдавать адреса в аренду из указанного диапазона. При отказе одного из серверов DHCP другой продолжает предоставлять адреса, пока первый сервер DHCP снова не начнет работать. На экране 1 приведен пример настройки диапазона адресов DHCP в режиме балансировки нагрузки.

Экран 1. Просмотр свойств диапазона DHCP при использовании режима Load Balance

*Режим горячей замены (Hot standby mode). Когда вы настраиваете два сервера с ролью DHCP, реализованной в режиме горячей замены, или горячего резервирования, серверы работают в отношениях отказоустойчивости. Активный сервер предоставляет IP-адреса и информацию о настройке клиентам. Второй же сервер выполняет эту функцию в том случае, если первый недоступен. На экране 2 показана область DHCP, настроенная в режиме горячей замены.

Экран 2. Просмотр свойств диапазона DHCP при включении режима Standby Mode

Настройка отказоустойчивого DHCP

Отказоустойчивый DHCP подразумевает взаимодействие двух серверов DHCP. Только два сервера DHCP могут взаимодействовать друг с другом, но вы можете настроить различные партнерские отношения между серверами DHCP. Например, в вашей инфраструктуре партнерами могут быть DHCP-ОДИН и DHCP-ДВА, DHCP-ДВА и DHCP-ТРИ или DHCP-ОДИН и DHCP-ТРИ. Тем не менее, отдельная область DHCP может использоваться исключительно в одном партнерстве. Например, вы можете настроить диапазон SCOPE-ALPHA с высокой доступностью на серверах DHCP-ОДИН и DHCP-ДВА, но этот диапазон не может быть представлен и для DHCP-ТРИ.

Чтобы настроить отказоустойчивый вариант DHCP, выполните следующие шаги.

1. Установите роль DHCP на двух отдельных серверах под управлением Server 2012, которые являются членами одного и того же домена Active Directory (AD).
2. Убедитесь, что роль DHCP на каждом сервере авторизована в AD.
3. Создайте соответствующие области на первом сервере DHCP.
4. Выберите область адресов, для которой вы включаете функцию отказоустойчивости. В меню Action нажмите Configure Failover.
5. На странице Introduction to DHCP Failover мастера Configure Failover убедитесь в наличии выбранной вами области и нажмите Next.
6. На странице Specify the partner server to use for failover нажмите Add Server. На экране 3 в окне Add Server вы видите список всех компьютеров Server 2012, выполняющих служебную роль DHCP и авторизованных в домене. Выберите сервер DHCP, который хотите использовать в качестве сервера-партнера, и нажмите OK.
7. На странице Specify the partner server to use for failover нажмите Next.
8. На странице Create a new failover relationship выберите либо режим Load balance, либо Hot standby в раскрывающемся списке Mode.
9. Если вы настраиваете сервер в режиме балансировки нагрузки, определите приоритет weight, который нужно назначить каждому серверу. По умолчанию каждый сервер работает в варианте равномерного распределения нагрузки equal load, как показано на экране 4. Если вы настраиваете сервер в режиме горячей замены, задайте роль сервера-партнера (Active, либо работающий в режиме ожидания Standby) и процент адресов, выделенный для резервного сервера из диапазона, как показано на экране 5.
10. При желании задайте параметр State Switchover Interval. Данная настройка определяет временной интервал до начала выдачи резервным сервером адресов клиентам сети.
11. Выберите общий секретный ключ shared secret. Это позволит вам объединить в пару серверы DHCP. Щелкните Next.
12. На последней странице нажмите Finish.

Экран 3. Выбор DHCP Server в качестве партнера

Экран 4. Настройка DHCP в паре при использовании режима Load Balance

Экран 5. Настройка DHCP в паре при использовании режима горячей замены

Вы можете настроить только один тип отношений отказоустойчивости между двумя серверами DHCP. Так, если вы настраиваете отношения отказоустойчивости при использовании режима балансировки нагрузки между DHCP-ОДИН и DHCP-ДВА, все настроенные отказоустойчивые области DHCP будут использовать режим load balance. Если вы настраиваете отношения между DHCP-ONE и DHCP-THREE, эти отношения могут задействовать различные способы обеспечения отказоустойчивости. Вы можете видеть взаимосвязи сервера DHCP в таблице Failover диалогового окна IPv6 Properties или IPv4 Properties, как показано на экране 6.

Экран 6. Просмотр взаимосвязей отказоустойчивости DHCP сервера DHCP

Доступный DHCP с минимальными усилиями

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

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

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

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

В Windows Server 2012 появилась возможность объединить два DHCP-сервера в конфигурацию высокой доступности, которая может работать в двух режимах: балансировки нагрузки или горячей замены.

Режим балансировки нагрузки является предпочтительным, в этом случае оба сервера одновременно обслуживают одну и ту же область, реплицируя данные между собой. Запросы клиентов делятся между серверами в заданной пропорции, по умолчанию 50/50. В случае отказа одного из серверов обслуживание продолжает оставшийся сервер.

Схема работы предельно проста и аналогична работе других сетевых сервисов, таких как DNS или AD — клиентские запросы обслуживаются до тех пор, пока в сети есть хоть один сервер, способный обработать запрос. Однако есть ограничение: два сервера на область DHCP. Следует помнить и понимать, высокая доступность DHCP реализуется не на базе серверов, а на базе областей. Если один сервер содержит несколько областей, то он, соответственно, может входить в несколько конфигураций высокой доступности.

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

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

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

Как видим, возможностей вполне достаточно для реализации самых разных схем и сценариев. Перейдем от теории к практике.

На двух серверах сети, в нашем случае это контроллеры домена SRV-DC01 и SRV-DC02, добавим роль DHCP-сервера, который обязательно авторизуем в Active Directory.

На одном из серверов добавляем и настраиваем область DHCP.

Затем щелкнув правой кнопкой мыши на нужную область, в выпадающем меню, выбираем Настройка обработки отказа.

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

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

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

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

В режиме горячей замены набор опций несколько иной:

• Роль сервера-партнера — позволяет выбрать роли серверов, по умолчанию активным становится сервер, на котором настраивается обработка отказа, партнер переводится в ждущий режим.
• Адреса, выделенные для резервного сервера — часть диапазона, выделяемая резервному серверу для обслуживания новых клиентов в режиме «связь потеряна».

Указав все необходимые настройки жмем Далее и завершаем работу мастера.

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

Важно! В настоящее время между серверами реплицируется только информация о выданных IP-адресах, при изменении настроек области, в том числе при резервировании адресов, изменения следует синхронизировать вручную.

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

Если по истечении времени интервала переключения сервер партнер не вернется в строй, то оставшийся сервер перейдет в состояние «партнер отключен» и начнет самостоятельно выдавать адреса из всего диапазона. При этом обратившиеся за продлением аренды клиенты партнера вместо продления получат новый адрес. После того как партнер вернется в строй клиенты будут автоматически распределены между ними в заданной пропорции (но это не приведет к изменению адресов, просто переданные назад партнеру клиенты по истечении аренды получат новый адрес уже у него).

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

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

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

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

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

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

Zeroconf или зачем нам вообще какой-то DHCP

В принципе, специально для функционирования небольших сетей был создан стек технологий под названием 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.

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

В этом разделе я рассмотрю практическое применение опций 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 под спойлером.

#Добавляем опцию 15. содержимое — сконвертированный в HEX суффикс.

/ip dhcp-server option

add code=15 name=dns-suffix value=0x57687920616c6c207468697320736869743f

#создаем набор опций

/ip dhcp-server option sets

add name=dns option=dns-suffix

#Добавляем опцию к DHCP-серверу для клиентов.

/ip dhcp-server network

set [find comment="wi-fi client dhcp"] dhcp-option-set=dns

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

#настройка опций, обратите внимание, что ip экранирован одинарными кавычками

/ip dhcp-server option

add code=6 name=google value="'8.8.8.8'"

add code=6 name=cloudflare value="'1.1.1.1'"

#настройка клиентов

/ip dhcp-server lease

add address=10.0.0.2 dhcp-option=google mac-address=11:11:11:11:11:11 server=dhcp

add address=10.0.0.3 dhcp-option=cloudflare mac-address=22:22:22:22:22:22 server=dhcp

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

/ip dhcp-server option

add name="option66" code=66 value="s'192.168.88.1'"

add name="option67" code=67 value="'pxelinux.0'"

/ip dhcp-server option sets

add name="set-pxe" options=option66,option67

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

/ip dhcp-server option

add code=121 name=classless value=0x0A0000c0a8580200c0a85801

Подробнее можно прочитать в статье «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 производится в настройках бриджа:

#Включаем dhcp-snooping и option 82

/interface bridge

add name=bridge

set [find where name="bridge"] dhcp-snooping=yes add-dhcp-option82=yes

#ставим настраиваем доверенный порт

/interface bridge port

add bridge=bridge interface=ether1

add bridge=bridge interface=ether2 trusted=yes

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

Стоит отметить, что не все модели 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?

В Windows Server 2000/2003 отказоустойчивость DHCP можно было организовать только с помощью кластера Microsoft, в Windows Server 2008 уже без кластера, но с помощью довольно ограниченной функции DHCP Failover. В Windows Server 2012 R2 появился новый встроенный функционал высокой доступности (High Availability) DHCP, позволяющий с легкостью обеспечить HA для сервиса DHCP.

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

Содержание:

• Установка роли DHCP Server в Windows Server 2012 R2
• Настройки отказоустойчивости DHCP
• Несколько полезных замечаний о DHCP HA

Есть два режима обеспечения высокой доступности DHCP:

• балансировка нагрузки – запросы клиентов распределяется между серверам
• горячая замена – второй сервер реплицирует данные зоны с основного сервера, и при выходе его их строя активируется и начинает обслуживать клиентов

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

Установка роли DHCP Server в Windows Server 2012 R2

Установка роли DHCP крайне проста и не требует перезагрузки сервера.

1. Откройте консоль Server Manager.
2. Нажмите Add Roles and Features.
3. В списке ролей выберите DHCP Server .

При помощи PowerShell установить роль еще проще

Add-WindowsFeature DHCP –IncludeManagementTools

Даже если система запросит перезагрузку сервера, можно проигнорировать этот запрос. После установки роли, администратор должен настроить DHCP зоны и их параметры. В нашем примере на первом DHCP сервере мы создадим одну DHCP зону с именем Servers, настроим параметры шлюза, DNS сервера и другие настройки зоны. В качестве динамического диапазона адресов укажем диапазон с 10.60.1.100 по 10.60.1.150.

Затем нужно установить роль DHCP на втором сервере (зону настраивать при этом не нужно).

Настройки отказоустойчивости DHCP

Отказоустойчивость DHCP настраивается с помощью мастера, который можно вызвать, щелкнув ПКМ по зоне и выбрав Configure Failover.

На первом этапе мастер DHCP Failover предлагает выбрать зоны, отказоустойчивость которых нужно обеспечить. У нас она одна, поэтому нажимаем Next.

На втором шаге нужно будет указать имя второго DHCP сервера партнера.

В следующем окне нужно указать имя связи (Relationship name), режим балансировки нагрузки между серверами (в каком соотношении будет разделена область между двумя серверами), время аренды ip адреса новым клиентом (это же время определяем время ожидания восстановления канала связи с партнёром), интервал автоматического переключения.

Знакомимся с результирующими настройками и жмем Finish.

На этом все. Реплицированная область появится на втором DHCP сервере.

Несколько полезных замечаний о DHCP HA

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

• В ваших сетях могут быть настроены DHCP relay (IP Helper) на уровне VLAN для пересылки запросов на определенный сервер. В этом случае нужно добавить адреса обоих DHCP серверов в конфигурацию сетевого оборудования
• С помощью команды ipconfig /all на клиенте можно узнать имя DHCP-сервера, выдавшего IP адрес. Это бывает полезно при поиске неисправностей.
• DHCP репликация выполняется только на уровне зоны. Если вы настроили некие параметры на уровне сервера (как правило, это имя домена, DNS сервера и т.д.), убедитесь что они одинаковые на обоих DHCP серверах.
• При удаленном подключении к компьютеру клиента, чтобы освободить текущий адрес и запросить новый, пользуйтесь командой:ipconfig /release && ipconfig /renew

Добрый день, дорогие читатели. Данная статья является второй частью моей статьи, про установку и настройку DHCP сервера. Сегодня я расскажу Вам как корректно настроить DHCP сервер на OC Windows Server 2012. После установки DHCP сервера мы заходим в Панель управления — Администрирование — DHCP.

Зайдя в DHCP мы увидим список серверов на которых установлена роль DHCP сервера в нашем домене. Поскольку сервер DHCP у меня один я вижу только его. Кликнем по серверу левой кнопки мыши и увидим что в сервере имеются настройки для двух протоколов (IPv4 и IPv6). Для настройки протокола IPv4 кликнем по нему правой клавишей мыши и выберем пункт Создать область.

Запустится Мастер создания сети,  нажимаем далее в появившемся окне.

Присваиваем имя нашей DHCP области (DHCP scope) и оставляем небольшое описание.

После заполнения данных нажимаем кнопку далее.

Следующим шагом идут настройки конфигурации для DHCP сервера и клиента.

Мы указываем начальный и конечный IP адреса для нашей области резервирования, а также указываем маску подсети. В своей сети я выбрал классическую подсеть класса D (192.168.x.x.) с количеством клиентов до 254. Если бы количество ПК в моей организации достигало нескольких тысяч я выбрал бы подсеть класса B или С.

После ввода IP адресов и маски подсети нажимаем далее

Затем Мастер создания сети попросит ввести диапазон адресов, которые необходимо исключить из резервирования. Эти IP адреса можно будет ввести на устройствах (клиентах) вручную, чтобы они не изменялись (на серверах, сетевые принтерах, сканерах, камерах и т.д.). Я обычно выделяю 40-50 IP адресов.

Мы вводим диапазон и нажимаем клавишу Добавить он должен появиться внизу в окне Исключаемый диапазон адресов, а затем нажимаем кнопку Далее

Одним из последних шагов является установка срока действия арендованных адресов (на какой срок выдавать клиентам IP адрес). Я обычно выставляю 30 дней.

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

После этого мы можем ввести IP адрес нашего роутера и нажать Добавить, а потом нажить кнопку Далее.

Затем мастер предложит указать DNS сервер и имя домена, в этом шаге оставляем все как есть и нажимаем Далее.

В Wins серверах оставляем поля пустыми и тоже нажимаем Далее.

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

В конце появляется окно с информацией о успешном создании области резервирования. Радуемся и нажимаем Готово.

На этом настройка DHCP для протокола IPv4 подошла к концу. После подключения к нашей сети клиентов мы можем наблюдать их в DHCP во вкладке арендованные адреса. На этом наша статья подошла к концу, спасибо что внимательно прочитали ее до конца.

Отказоустойчивый сервис DHCP теперь новая возможность  Windows Server 2012, дающий нам следующие возможности:

• Доступность сервиса DHCP  в сети предприятия  в любое время
• Если один из серверов DHCP недоступен, клиенты DHCP могут продлить аренду IP адерса , обратившись к другому DHCP серверу.

Задача

Конфигурируем DHCP failover для  домена, которому сегодня повезло- contoso  и сети 10.0.0.0/8

Среда

1. На App01, выполняем вход с правами Domain Administrator.

2. Запускаем”Server Manager“.

3. Выбираем “Add roles and features“.

4. На экране “Before you begin” , выберите “Next“.

5. На экране “Installation Type” , выберите “Role-based or feature-based installation“, и щелкните “Next“.

6. На экране “Server Selection” , щелкните “Next“.

7. На экране “Server Roles” , отметьте “DHCP Server“, и щелкните “Add Features“.

8. Щелкните “Next“.

9. На экране “Features” , щелкните “Next“.

10. На экране “DHCP Server” , щелкните”Next“.

11. На экране “Confirmation” , выберите”Install“.

12. После окончания инсталляции,  щелкните”Completed DHCP configuration“.

13. а экране”Description” , щелкните”Next“.

14. На экране “Authorization” , выберите”Use the logged in user’s credentials“.

Замечание: Вы можете выбрать “alternate credentials” для авторизацииs DHCP сервера, и указать другие учетные данные

15. Щелкните “Commit“.

16. Щелкните “Close“.

17. Повторите шаги с 1-го по 16-й step 1 – 16 на сервере App02.

18. На сервере App01, запустите остнастку “DHCP Console“.

19. Выберите  “app01.contoso.com > IPv4“,щелкните правой клавишей на”IPv4“, и выберите”New Scope“.

20. Создайте ноую область DHCP для сети 10.0.0.0/8 .

21. Щелкните правой клавишей на области , и выберите, “Configure Failover“.

22. На экране “Introduction” , оставьте выделенным чекбокс “Select all“.

23. Щелкните “Next“.

24. На экране “Specify the partner server to use for failover” , щелкните”Add Server“.

25. Выберите “This authorized DHCP server > app02.contoso.com“.

26. Щелкните”OK“.

27. Click “Next“.

Опция Relation name: Уникальное имя конфигурации требуется для конфигурирования отказоустойчивых отношений между двумя серверами. Поскольку множество таких отношений может существоватьна одном или более сервере, каждое именование такого схождения должно быть уникальным для сервера.

Maximum Client Lead Time: Эта опция определяет временной период для аренды адреса клиента, обратившегося к отказоустойчивому серверу.

Mode: Определяет режим работы DHCP  “Hot Standby” или”Load balance“.

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

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

Auto State Switchover Interval: Сервер, который утратил связь со своим партнером, переходит в состояние прерванного соединения.Потеря связи может означать проблемы на сетевом уровне, либо сервер-партнер просто может быть выключен.Поскольку для сервера не существует способа  для выявления причин потери связи со своим партнером, сервер будет продолжать поддерживать состояние прерванного соединения, пока администратор вручную изменяет состояние партнера  на “не недоступен”. Альтернативным режимом будет авто переключение по таймауту, по умолчанию равному 10 минутам.

Enable Message Authentication: Для настройки проверки подлинности сообщений, мастер  конфигурирования DHCP failover предлагает администратору указать общий секрет на каждом из серверов.

28. Изменим значение “Maximum Client Lead Time“, до 1 минуты для тестирования.

29. Оставим режим “Mode“, по умолчанию – “Load balance“.
30. CИзменим “Auto State Switchover interval“, до “20” минут.

31. Предоставим общий секрет “Shared Secret“.

32. Щелкните “Next“.

33. Щелкните “Finish“.

34. Щелкните “Close“.

35. Щелкните правой клавишей на области DHCP , и выберите”Properties“.

36. Выберите значение “Lease duration for DHCP clients“,ограничьте его до “Limted to” 8 минут.

37. Щелкните”OK“.

38. На сервере App02, запустите остнастку”DHCP Console“.

Заметьте, что область DHCP была создана автоматически.

39. Щелкните на области правой клавишей, и выберите “Properties“.
40. Ограничьте значение “Lease duration for DHCP clients“, изменив его до “Limted to” 5 минут.

Результаты тестирования
1. Включите обе рабочие станции.
2. Проверьте  IP адреса на обоих клиентах командой “ipconfig /all“.

Клиент 1 получил в аренду  IP адрес с сервера  App01

Клиент 2 получил в аренду  IP адрес с сервера  App02

Конфигурируем режим DHCP failover.

3. Отключите сетевое подключение от сервера App01.

4. Когда время аренды истечет, выполните “ipconfig /all” на клиенте 1.

Поскольку сервер App01 недоступен, клиентская машина 1 получила тот же самый IP адрес с APP02.

5. Вернитесь на App02, щелкните правой клавишей на области DHCP , и выберите “Properties“.

6. Измените опцию на вкладке “Failover” .

Теперь область DHCP  обслуживается  App02. Это доказывает функционирование DHCP failover.

Ссылки:

Step-by-Step: Configure DHCP for failover

Understand and Troubleshoot DHCP failover in Windows Server