что такое dhcp и зачем он нужен

Протокол DHCP

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016

Этот раздел можно использовать для краткого обзора DHCP в Windows Server 2016.

Помимо этого раздела, доступна следующая документация по DHCP.

Протокол DHCP — это протокол клиента или сервера, который автоматически предоставляет узел протокола IP с его IP-адресом и другие связанные сведения о конфигурации, такие как маска подсети и шлюз по умолчанию. RFC 2131 и 2132 определяют протокол DHCP в качестве стандарта Internet Engineering Task Force (IETF), основанного на протоколе начальной загрузки (BOOTP), протокола, с помощью которого DHCP предоставляет много сведений о реализации. DHCP позволяет узлам получать необходимые сведения о конфигурации TCP/IP от DHCP-сервера.

Windows Server 2016 включает DHCP-сервер, который является необязательной ролью сервера сети, которую можно развернуть в сети для аренды IP-адресов и других сведений клиентам DHCP. все клиентские операционные системы на основе Windows включают dhcp-клиент как часть TCP/IP, а dhcp-клиент включен по умолчанию.

Зачем использовать DHCP?

Каждое устройство в сети на основе TCP/IP должно иметь уникальный IP-адрес одноадресной рассылки для доступа к сети и ее ресурсам. Без DHCP IP-адреса новых компьютеров или компьютеров, перемещаемых из одной подсети в другую, необходимо настроить вручную. IP-адреса для компьютеров, удаленных из сети, необходимо вручную освободить.

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

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

Допустимые параметры конфигурации TCP/IP для всех клиентов в сети.

Допустимые IP-адреса, поддерживаемые в пуле для назначения клиентам, а также исключенные адреса.

Зарезервированный IP-адрес адреса, связанные с конкретными клиентами DHCP. Это обеспечивает единообразное назначение одного IP-адреса одному клиенту DHCP.

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

Клиент с поддержкой DHCP при принятии предложения аренды получает:

Допустимый IP-адрес для подсети, к которой подключается.

Запрошенные параметры DHCP, которые являются дополнительными параметрами, настроенными DHCP-сервером для назначения клиентам. Некоторые примеры параметров DHCP: маршрутизатор (шлюз по умолчанию), DNS-серверы и доменное имя DNS.

Преимущества DHCP

DHCP предоставляет следующие преимущества.

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

Сокращенное администрирование сети. Служба DHCP включает следующие функции для сокращения сетевого администрирования:

Централизованная и автоматизированная конфигурация TCP/IP.

Возможность определять конфигурации TCP/IP из центрального расположения.

Возможность назначать полный диапазон дополнительных значений конфигурации TCP/IP с помощью параметров DHCP.

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

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

Источник

Курс по основам компьютерных сетей на базе оборудования Cisco. Этот курс поможет вам подготовиться к экзаменам CCENT/CCNA, так как за его основу взят курс Cisco ICND1.

9.1 Зачем нужен протокол DHCP? Что такое DHCP опции (DHCP options) и зачем они нужны?

Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем изучать основы работы компьютерных сетей. В девятой части мы с вами будем разбираться с тем, как работает протокол DHCP (Dynamic Host Configuration Protocol) и зачем он вообще нужен? Эта запись как раз будет про назначение и возможности протокола DHCP, а также мы с вами рассмотрим DHCP опции и их назначение в протоколе. Как всегда, торопиться никуда не будем, сперва рассмотрим DHCP в общих чертах, а затем будем разбираться с частностями.

9.1.1 Введение

В курсах ICND1 и ICND2 протокол DHCP рассматривается очень поверхностно, да и в целом Cisco размазала информацию об этом протоколе на треки разных направлений и по разным уровням. Мы же рассмотрим DHCP довольно подробно и, пожалуй, рассмотренной информации хватит не только для того, чтобы ответить на вопросы по DHCP, которые могут встретиться на экзамене CCNA R&S, но и на вопросы, которые могут быть на экзамене CCNP R&S.

9.1.2 Зачем нужен протокол DHCP и как он связан с протоколом IP?

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

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

В этой теме мы будем разбираться с протоколом DHCP в связке с протоколом IPv4, хотя стоит заметить, что рассматривать DHCP без протокола IP вообще нет никакого смысла, просто дело всё в том, что DHCPv6 имеет несколько другие задачи, но это совсем другая история. Вообще, протокол DHCP, как и многие другие протоколы (например, NAT), возник из-за недостатков IPv4, дело в том, что в IPv4 нет механизма по автоматическому назначению IP-адресов на интерфейсы, а вот в IPv6 такой механизм уже имеется. То есть DHCP расширяет возможности IPv4 и делает жизнь сетевого инженера более простой и приятной, правда этому инженеру придется изучать как этот DHCP работает.

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

Протокол DHCP был стандартизован в 1993 году и является наследником протокола BOOTP, это мы увидим, когда познакомимся со структурой сообщений в DHCP, кстати говоря, по схожему принципу с DHCP работает протокол RARP, но он нам совсем неинтересен. DHCP описан в спецификации RFC 2131.

9.1.3 Режимы работы DHCP сервера

Куда важнее понимать режимы работы DHCP-сервера, чтобы он работал так, как вам хочется, а не так, как получается. Эта тема для нас не нова, поэтому здесь я буду краток.

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

Автоматическое назначение статических адресов. Главной особенностью работы этого режима является то, что сервер выдает IP-адрес клиенту не на определенное время (в DHCP это время называется временем аренды или lease time), а навсегда. DHCP-сервер выдает клиенту IP-адрес без вмешательства администратора, при первом обращение клиента сервер его запоминает и затем постоянно выдает этому клиенту один и тот же IP-адрес.

Режим автоматического распределения динамических адресов. Это то, что нас больше всего интересует, самый гибкий и самый универсальный режим. В таком режиме сервер выдает IP-адрес клиенту не навсегда, а на строго определенное время, которое называется временем аренды, это время назначается администратором, когда время аренды будет истекать, клиент, если захочет, может его продлить, чтобы не менять IP-адрес. Тут стоит заметить, что в этом режиме адреса для клиентов тоже можно зафиксировать за конкретным клиентом, например, при помощи опции 82, но об этом позже.

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

9.1.4 Опции DHCP протокола и зачем они нужны? Список стандартных DHCP опций

Вы уже, наверное, поняли, что протокол DHCP относится к группе протоколов, работающих по архитектуре клиент-север, DHCP относится к прикладному уровню моделей OSI 7 и TCP/IP, а сообщения DHCP инкапсулируются в UDP дейтаграммы, но сейчас речь не об этом. Сейчас нам нужно понять, что клиент делает запрос к серверу на получение параметров, необходимы для того, чтобы клиент мог получить полноценный доступ к ресурсам компьютерной сети, эти параметры называются DHCP опции. Если говорить грубо, то клиент просто сообщает серверу – какие опции ему необходимы, а сервер на основе каких-то своих критериев может принять решение – какие опции и с какими значениями нужно выдать клиенту, а может их вообще этому клиенту выдавать не нужно.

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

Очевидная проблема, которая у вас может возникнуть: для подключения клиентского устройства к компьютерной сети нужна опция, с которой это устройство работать не умеет, ну вот не добавили поддержку этой опции производители и всё тут. Список стандартных DHCP опций описан в RFC 2132. Более того, для каждой стандартной опции есть свой RFC, который описывает – зачем эта опция нужна и как она должна работать.

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

Для передачи опций между клиентом и сервером в DHCP пакете есть специальное поле переменной длинны, которое так и называется – options. Это поле имеет переменную длину, но при этом все остальные поля DHCP сообщения фиксированные. Если учесть, что и DHCP-клиент, и DHCP-сервер должны уметь обработать пакет размером 576 байт (576 байт взято не с потолка, а из ограничений некоторых старых протоколов), а также знать размер других полей в пакете, то нетрудно будет посчитать, что поле options имеет минимальную длину 340 байт. При этом самое поле options начинается с фиксированной последовательности Magic Cookie, которая выглядит так: 0×63825363. Можно сказать и по-другому, Magic Cookie – это четыре байта со значениями 99, 130, 83, 99. Как это не назови, но по этой последовательности устройство понимает, что фиксированная часть пакета закончилась и начались DHCP опции.

Кстати говоря, в DHCP пакете есть еще два необязательных поля, то есть в пакете есть пространство, вместо которого можно передавать опции – это поля file (64 байта) и snmae (128 байт). Что еще можно добавить про опции DHCP? Каждая стандартная опция имеет уникальный номер от 0 до 255, вернее правильнее будет говорить код, а не номер. У каждой опции есть размер, при этом у некоторых опций определен не строго фиксированный размер, а какие-то границы, в которых опция может плавать. Более подробную информацию о DHCP опциях вам придется смотреть в специальных RFC, дело всё в том, что некоторые опции должны начинаться, например, с нуля, некоторые опции нельзя использовать вместе, есть еще ряд других особенностей, в которые углубляться нам смысла сейчас нет.

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

9.1.6 Список самых часто используемых DHCP опции

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

9.1.7 Выводы

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

Источник

ИТ База знаний

Полезно

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Все, что вам нужно знать про DHCP

Про динамические адреса

Полный курс по Сетевым Технологиям

В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer

DHCP за 200 секунд

Порассуждаем

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

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

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

DHCPv4 динамически назначает адреса IPv4 и другую информацию о конфигурации сети. Отдельный сервер DHCPv4 является масштабируемым и относительно простым в управлении. Однако в небольшом офисе маршрутизатор может быть настроен для предоставления услуг DHCP без необходимости выделенного сервера.

DHCPv4 включает три разных механизма распределения адресов для обеспечения гибкости при назначении IP-адресов:

Динамическое распределение является наиболее часто используемым механизмом DHCP и при его использовании клиенты арендуют информацию с сервера на определенный период. DHCP серверы настраивают так, чтобы установить аренду (лизинг) с различными интервалами. Аренда обычно составляет от 24 часов до недели или более. Когда срок аренды истекает, клиент должен запросить другой адрес, хотя обычно он снова получает старый.

Механизм работы DHCP

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

Рассмотрим процесс получения адреса:

Теперь рассмотрим, как происходит продление аренды адреса:

Полный курс по Сетевым Технологиям

В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer

Источник

[Конспект админа] Как подружиться с DHCP и не бояться APIPA

Сервис, выдающий 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_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters и поставить ему значение 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) и передачи большого количества разной информации клиенту. Достигается это за счет менее тривиальной процедуры получения адреса. Если в старых протоколах схема была простая, вида запрос-ответ, то теперь схема следующая:

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

Подробнее про схему взаимодействия сервера и клиента и про структуру запросов и ответов можно почитать, например, в материале «Структура, формат и назначение DHCP пакетов».

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

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

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

Знание, что сервер 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:

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

Подробнее можно прочитать в статье «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-запросов и ответов или ограничение их количества, ну и, конечно, различные системы IPS\IDS.

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

Источник