Что такое DHCP и как это работает?!
Привет, друзья! Сегодня я хочу рассказать что же такое DHCP, для чего это нужно и как всё работает. Почему я поднимаю эту тему? Да просто уже устал объяснять прописные истины. Ко мне постоянно поступает множество вопросов по настройкам модемов и роутеров и я понимаю, что большинство просто не в курсе даже самых-самых основополагающих принципов функционирования локальной сети. Смысл тогда лезть в настройку устройства, если не понимаешь даже что собираешься делать?! Именно для повышения уровня компьютерной грамотности я и написал эту статью.
Напомню сначала, что есть два основных типа вычислительных сетей — локальные (LAN) и глобальные (WAN).
Локальная сеть работает в пределах одной комнаты \ квартиры \ здания \ организации. То есть её размер ограничен одним или несколькими сегментами.
Глобальная сеть — это, конечно же, самая крупная глобальная сеть в мире — Интернет. К какой бы сети Вы не подцепились — Вы должны получить в ней адрес, помогающий идентифицировать любое подключенное устройство. Он будет присвоен на время (динамически) или навсегда (статически). Кроме этого вы получаете маску сети, адрес шлюза и DNS-серверов. Без этого работать ничего нормально не будет. Так вот контролировать этот процесс в автоматическом режиме и призван протокол DHCP. Без него в крупной сети будет полнейший бардак.
Есть такой протокол DHCP….
И вот мы плавно подошли к основной теме статьи. DHCP — Dynamic Host Configuration Protocol— это протокол динамической настройки узла. Он клиент-серверный и предназначен для настройки каждого подключенного хоста с помощью удаленного сервера. На сегодняшний день DCHP поддерживается «из коробки» практически каждого современной операционной системой. В крупных сетях это реально отличная альтернатива рутинной ручной настройке сетевых параметров для сервера и подключаемых устройств, позволяющая системному администратору упросить настройку и управление своим сегментом сети.
Протокол DHCP имеет свой собственный порядок обмена сообщениями между сервером и клиентами, в процессе которого они обмениваются сообщениями. Структура сообщений DHCP выглядит так:
| Поле | Длина (байты) | Описание |
| op | 1 | Тип сообщения |
| htype | 1 | Тип адреса аппаратной части |
| hlen | 1 | Длина адреса аппаратной части |
| hops | 1 | Используемое количество агентов ретрансляции. Клиенты устанавливают значение на 0. |
| xid | 4 | ID (уникальный идентификационный номер) транзакции используемой клиентом и серверов во время сессии |
| secs | 2 | Прошедшее время (в секундах) с момента запроса клиентом начала процесса |
| flags | 2 | Значение флагов |
| ciaddr | 4 | IP-адрес клиента (если имелся ранее). |
| yiaddr | 4 | IP-адрес, предложенный сервером клиенту |
| siaddr | 4 | IP-адрес сервера |
| giaddr | 4 | IP-адрес relay-агента (агента ретрансляции) |
| chaddr | 16 | Адрес аппаратной части клиента (в основном MAC). |
| sname | 64 | Имя сервера. |
| file | 128 | Название загрузочного файла. |
| options | Переменная. Поле опций, где указываются различные дополнительные параметры конфигурации | Дополнительные опции |
Как работает DHCP
При работе протокола динамической адресации используются четыре типа сообщений, которыми обмениваются клиент и сервер. Давайте рассмотрим их подробнее.
DHCPDISCOVER
С данного сообщение начинается процесс взаимодействия между клиентом и сервером посредством DHCP. Оно отправляется клиентом (компьютером, телефоном, планшетом, телевизором или устройством), которое подключилось к данной сети. Сообщение широковещательное, то есть в нём используется 255.255.255.255 как IP-адрес доставки, а исходным адресом является 0.0.0.0
DHCPOFFER
Это сообщение отправляется сервером хосту в ответ на полученный ранее DHCPDISCOVER. В нём содержатся все необходимые сетевые настройки, применив которые новое устройство сможет работать в этом сегменте.
DHCPREQUEST
Опять широковещательно сообщение, которое клиент отправляет серверу в ответ DHCPOFFER. Оно означает, что клиент выбрал отправленный ему вариант конфигурации сетевого подключения.
DHCPACK
Финальное сообщение от сервера DHCP клиенту в ответ на DHCPREQUEST. Оно обозначает конец процесса общения, начатого с сообщения DHCPDISCOVER. Получив его, клиент должен применить согласованные ранее настройки сетевого интерфейс, используя предоставленные опции.
Прочие сообщения протокола:
DHCPNAK
Полная противоположность сообщению DHCPACK. Оно означает прекращение общения между сервером, описанного выше. Необходимо начать процедуру заново!
DHCPRELEASE
Сообщение отправляется клиентом в тот момент, когда он завершает процесс использования занимаемого им IP-адреса.
DHCPDECLINE
Если предлагаемый сервером IP-адрес уже занят, то клиент отправляет серверу данное сообщение и после этого процесс их общения перезапускается с самого начала.
DHCPINFORM
Этот вид сообщений отправляется клиентом серверу в тех случаях, когда клиенту присвоен статический IP-адрес, и выделение динамического не требуется. В ответ сразу прилетает DHCPACK.
Механизм общения клиента и сервера
Теперь, когда мы узнали все типы используемых в протоколе DHCP сообщений, давайте посмотрим как на практике происходит общение клиента и сервера.
Этап 1. Клиентское устройство — компьютер, телефон, принтер, телевизор и т.п.- подключается к сети. Он отправляет широковещательный запрос DHCPDISCOVER в поисках сервера. Для этого используется транспортный протокол UDP и порт 67. Начинается процесс авторизации.
Этап 2. Сервер получил запрос DHCPDISCOVER, то в ответ шлёт сообщение DHCPOFFER, где предлагает клиенту варианты настройки сетевого адаптера — IP-адрес, маску подсети, шлюз и DNS-серверы. и информация о шлюзе. Отправка идёт уже не в широковещательном формате а непосредственно хосту, отправившему запрос. Для этого в поле CHADDR прописывается его MAC-адрес. Теперь используется тот же протокол UDP, но порт уже 68.
Этап 3. Клиент просматривает выбранные конфигурации, выбирает приемлемую ему и формирует сообщение DHCPREQUEST, указав в нём какой вариант он выбрал. Если в сети несколько DHCP-серверов и прилетело несколько сообщений DHCPOFFER, то клиент указывает в ответе нужный ему сервер.
Этап 4. Сервер получает от клиента DHCPREQUEST и отправляет в ответ DHCPACK, говоря клиентскому устройству о том, что оно теперь в праве использовать назначенный ему IP-адрес. На этом процесс общения оканчивается и новый хост появляется в сети.
Аренда IP-адресов
Когда срок аренды адреса истечёт, а подтверждение не прилетит, либо прилетит пакет DHCPRELEASE, сервер сможет присвоить данный IP-адрес другому компьютеру или устройству, подключающемуся в данный момент времени.
Настройка DHCP на роутере
Первым делом Вы должны попасть в настройки своего WiFi-роутера. Сделать это можно либо с компьютера, введя в браузере его локальный IP (обычно это 192.168.1.1 или 192.168.0.1). После авторизации необходимо в главном меню веб-интерфейса найти раздел, отвечающий за локальную сеть (LAN). В некоторых случаях, как в моём примере, настройка DCHP на роутере выведена в отдельный раздел:
Включение и выключение сервера обычно выполняется с помощью галочек «Включить»/»Отключить» или «Enable»/»Disable». На некоторых моделях это может быть выполнено в виде выпадающего списка.
Как правило, на любом WiFi-маршрутизаторе можно задать пул IP-адресов для клиентов, которые будут выдаваться сервером. При необходимости его можно увеличить, либо убавить, оставив адреса для статических подключений.
Ещё один важный параметр — это время аренды IP-адреса (тот самый Lease Time) о котором я рассказывал выше. По умолчанию на моём роутере он выставлен на 120 минут. Максимальное значение — 2000 минут. После того, как Вы внесёте какие-то изменения в настройки устройства — обязательно не забудьте сохранить настройки. В противном случае, после перезагрузки в силу вступят старые параметры.
Что такое DHCP-протокол
Рассказываю о том, как компьютеры получают IP-адреса для работы в сети.
Способы выдачи IP-адресов
Чтобы компьютер мог работать в сети, ему нужен IP-адрес. Он выглядит как 4 числа через точку. Например, IP-адрес timeweb.com – 185.114.246.105. Это как страна, город, улица и дом в почтовом адресе, только в интернете – это узлы связи и магистральные роутеры. Если устройству не выдали IP-адрес, оно не может общаться с другими устройствами в сети.
«IP» расшифровывается как Internet Protocol. Данный протокол имеет две версии: IPv4 и IPv6.
Устройство может получить IP-адрес двумя способами: статическим (ручным) и динамическим.
Динамический способ подойдет как для предприятий, где количество устройств фиксировано, так и для кафе, через Wi-Fi которых каждый день проходит много разных гаджетов.
Протокол DHCP и динамический IP
Для динамической выдачи IP-адресов используется сетевой протокол DHCP («Dynamic Host Configuration Protocol»), что переводится как протокол динамической настройки узла.
DHCP работает по модели «клиент-сервер». Он автоматически раздает IP-адреса и другие параметры конфигурации устройствам, чтобы те могли работать в сети.
Взаимодействие DHCP-сервера и клиента
Сервер и клиент обмениваются сообщениями по принципу «запрос-ответ». Взаимодействие состоит из 4 этапов и сокращенно называется «DORA». По одной букве на каждый этап:
Подтверждение – Acknowledgement (ACK).
Поиск (Discover): Клиент → Сервер
На этом этапе клиенту главное найти и узнать, где находится сервер.
Мы включили компьютер, который находится в сети. Еще в этой же сети работает DHCP. В данном случае наш компьютер – это клиент, а DHCP – сервер. Теперь нашему устройству необходимо получить IP-адрес и другую необходимую информацию о сети, например шлюз, адреса DNS и маску подсети. Поэтому клиент начинает поиски сервера и посылает сообщение «DHCPDISCOVER» на компьютеры внутри этого сегмента сети.
Такое сообщение называется широковещательным (broadcast) – это значит, что поток данных от клиента получат все устройства внутри его сети. Ответить на такое сообщение смогут только DHCP-серверы.
Запрос клиента получат все участники сети, но ответит только сервер
Предложение (Offer): Сервер → Клиент
DHCP-сервер получает сообщение от клиента, после чего выбирает свободный IP-адрес из числа доступных и отправляет его в ответном сообщении «DHCPOFFER».
Как правило, IP-адрес закрепляется за клиентом на определенное время, поэтому может меняться между сеансами работы в сети.
Если клиенту ответили несколько серверов, он выберет какой-то один и получит от него IP-адрес с настройками.
Запрос (Request): Клиент → Сервер
Клиент получил IP-адрес и отправляет серверу ответное сообщение: «DHCPREQUEST». В нем он еще раз прописывает полученный адрес и тем самым подтверждает, что будет использовать его.
Ответное сообщение с IP-адресом получают все DHCP-серверы в сети, если их несколько. Это необходимо для того, чтобы каждый сервер знал, что этот адрес занят, и не предлагал его другим клиентам.
Только один сервер продолжает взаимодействие с клиентом. Это тот, который предложил выбранный клиентом IP-адрес.
Подтверждение (ACK): Сервер → Клиент
Сервер отправляет сообщение «DHCPACK» и тем самым закрепляет IP-адрес за клиентом. В сообщении содержится сам адрес, срок его использования и дополнительные настройки сети. Клиент проверяет эти настройки, применяет полученную конфигурацию и получает доступ к сети.
В общем виде весь процесс взаимодействия выглядит так:
– (Клиент) Кто тут сервер? Мне надо получить IP-адрес: «DHCPDISCOVER».
– (Сервер) Я сервер, предлагаю тебе использовать вот этот IP: «DHCPOFFER».
– (Клиент) Хорошо, я буду использовать этот IP, что ты мне отправил: «DHCPREQUEST».
– (Сервер) Вот и договорились. Приятной работы в сети: «DHCPACK».
Другие варианты сообщений
«DHCPINFORM» – так клиент запрашивает локальные настройки сети. В ответ на это сообщение сервер посылает запрашиваемую конфигурацию.
«DHCPNAK» – так сервер отказывает клиенту пользоваться IP-адресом.
Длительность использования IP-адреса
Время, на которое клиент получает IP-адрес от сервера, называется «срок аренды» (lease time). Он может составлять несколько минут, часов и даже суток. Когда срок аренды заканчивается, адрес освобождается, и сервер может отдать его другому клиенту.
Клиент может продлить аренду и использовать IP-адрес дальше. Для этого он ждет, пока пройдет половина срока, который изначально назначил сервер. После этого клиент посылает серверу сообщение «DHCPREQUEST», в котором указывает свой текущий IP-адрес. В ответном сообщении «DHCPACK» сервер запускает срок аренды заново. Получилась укороченная схема взаимодействия «клиент-сервер» из двух последних этапов (запрос → подтверждение).
Если сервер молчит и не отправляет подтверждение «DHCPACK», то клиент пробует отправить повторный запрос «DHCPREQUEST», когда пройдет половина от того времени, что осталось сейчас. И так до тех пор, пока не пройдет ⅞ времени всей аренды. После этого клиент начнет отправлять широковещательные запросы на свою сеть и ждать ответа от другого сервера.
Перед тем как завершить работу и отключиться от сети, клиент автоматически отправит серверу сообщение «DHCPRELEASE». Это значит, что IP-адрес свободен и сервер может передать его другому компьютеру.
Способы раздачи IP-адресов в DHCP
DHCP-сервер может назначать IP-адреса тремя способами:
Фиксированный – в этом случае происходит настройка DHCP сервера, в ходе которой администратор вручную прописывает соответствие между каждым MAC-адресом и IP-адресом. Таким образом, за каждым устройством закрепляется свой адрес, который будет выдавать сервер.
Это удобно в рамках небольшой сети, когда известны MAC-адреса всех компьютеров.
Автоматический – при таком способе каждое устройство автоматически получает IP-адрес, который не будет меняться. DHCP-сервер выдает адрес в бессрочную аренду, пока клиент от него не откажется.
Динамический – DHCP-сервер выдает клиенту любой адрес из диапазона свободных. Эти адреса не закрепляются за конкретными устройствами.
Динамическим способом раздают IP-адреса, когда состав пользователей и их количество в сети постоянно меняется, например при использовании Wi-Fi в кафе. В этом случае кафе покупает определенное количество IP-адресов и выдает посетителям, которые подключаются к сети.
Связь DHCP и клиента в разных подсетях
Обычно сеть дополнительно разделяют на подсети. Это помогает повысить производительность и обеспечить безопасность. Производительность повышается за счет того, что таким образом равномерно распределяется широковещательный трафик.
DHCP-сервер и клиент могут оказаться в разных подсетях, разделенных одним или несколькими маршрутизаторами. Как правило, маршрутизаторы не пропускают широковещательный трафик.
Вспомним, что первое сообщение, которое отправляет клиент, чтобы найти сервер («DHCPDISCOVER»), – широковещательное. Следовательно, клиент и сервер из разных подсетей не смогут просто так взаимодействовать.
Эту проблему решают с помощью ретрансляции или DHCP relay. С помощью этой настройки маршрутизаторы смогут передавать только широковещательный трафик, который относится к протоколу DHCP.
Таким образом, если маршрутизатор может работать в режиме DHCP relay, то у него получится передать первый запрос клиента «DHCPDISCOVER» серверу в другой подсети. В этом случае взаимодействию «клиент-сервер» ничего не помешает.
Краткие выводы
Для связи с другими устройствами и работы в сети компьютеру требуется IP-адрес.
Устройство может получить статический или динамический IP-адрес.
Динамические IP-адреса назначаются с помощью протокола DHCP.
Чтобы получить IP-адрес, устройство-клиент взаимодействует с DHCP-сервером по модели «DORA».
Сервер может назначить IP-адрес клиенту тремя способами: фиксированно, автоматически или динамически.
Если сервер и клиент находятся в разных подсетях, они смогут взаимодействовать с помощью ретрансляции DHCP relay.
[Конспект админа] Как подружиться с 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:
| Данные для настройки | DEC | HEX |
| Маска | 24 | 0x18 |
| Сеть назначения | 10.0.0.0 | 0x0A 00 00 |
| Шлюз | 192.168.88.2 | 0xc0 a8 58 02 |
| Сеть по умолчанию | 0.0.0.0/0 | 0x00 |
| Шлюз по умолчанию | 192.168.88.1 | 0xc0 a8 58 01 |
Соберем все это счастье в одну строку и получим настройку:
Подробнее можно прочитать в статье «Mikrotik, DHCP Classless Route».
Option 252. Автоматическая настройка прокси-сервера. Если по каким-то причинам в организации используется непрозрачный прокси, то удобно будет настроить его у клиентов через специальный файл wpad (pac). Пример настройки такого файла разобран в материале «Proxy Auto Configuration (PAC)». К сожалению, в MiroTik нет встроенного веб-сервера для размещения этого файла. Можно использовать для этого пакет hotspot или возможности metarouter, но лучше разместить файл где-либо еще.
Option 82. Одна из полезнейших опций — только не для клиента, а для DHCP-релея. Позволяет передать серверу информацию о порте коммутатора, к которому подключен клиент, и id самого коммутатора. Сервер на основе этой информации в свою очередь может выдать уже клиенту какой-то определенный набор настроек или просто занести в лог — чтобы в случае необходимости найти порт подключения клиента, не приходилось заходить на все свитчи подряд (особенно, если они не в стеке).
После настройки DHCP-Relay на маршрутизаторе в информации о клиентах появятся поля Agent Circuit ID и Agent Remote ID, где первое — идентификатор порта коммутатора, а второе — идентификатор самого коммутатора.
Выдача адресов с option 82.
Информация выдается в шестнадцатиричном формате. Для удобства восприятия при анализе журнала DHCP можно использовать скрипты. Например, решение для решения от Microsoft опубликовано в галерее скриптов Technet под названием «Декорирование DHCP опции 82».
Также опция Option 82 активно используется в системе биллинга провайдеров и при защите сети от посторонних вмешательств. Об этом чуть подробнее.
Добавим сети надежности и безопасности
Ввиду простоты протокола и присутствия широковещательных запросов есть эффективные атаки на инфраструктуру — в основном типа MITM («человек посередине»). Атаки производятся посредством поднятия своего DHCP-сервера или релея: ведь если контролировать выдачу сетевых настроек, можно запросто перенаправить трафик на скомпрометированный шлюз. Для облегчения атаки используется DHCP starvation (представляясь клиентом или релеем, злоумышленник заставляет «родной» DHCP-сервер исчерпать свои IP-адреса). Подробнее про реализацию атаки можно почитать в статье «Атакуем DHCP», методом же защиты является DHCP Snooping.
Это функция коммутатора, которая позволяет «привязать» DHCP-сервер к определенному порту. Ответы DHCP на других портах будут заблокированы. В некоторых коммутаторах можно настроить и работу с Option 82 при ее обнаружении в пакете (что говорит о присутствии релея): отбросить, заменить, оставить без изменения.
В коммутаторах MikroTik включение DHCP Snooping производится в настройках бриджа:
Настройка в других коммутаторах происходит аналогичным образом.
Стоит отметить, что не все модели MikroTik имеют полную аппаратную поддержку DHCP Snooping — она есть только у CRS3xx.
Помимо защиты от злых хакеров эта функция избавит от головной боли, когда в сети появляется другой DHCP-сервер — например, когда SOHO-роутер, используемый как свич с точкой доступа, сбрасывает свои настройки. К сожалению, в сетях, где встречается SOHO-оборудование, не всегда бывает грамотная структура кабельной сети с управляемыми маршрутизаторами. Но это уже другой вопрос.
Красивая коммутационная — залог здоровья.
К другим методам защиты можно отнести Port Security («привязка» определенного MAC-адреса к порту маршрутизатора, при обнаружении трафика с других адресов порт будет блокироваться), Анализ трафика на количество DHCP-запросов и ответов или ограничение их количества, ну и, конечно, различные системы 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?
