Хабрахабр

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

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

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

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

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

Он позволяет обойтись без каких-либо централизованных сервисов и серверов, включая, но не ограничиваясь выдачей IP-адресов. В принципе, специально для функционирования небольших сетей был создан стек технологий под названием Zeroconf. Им закрываются (ну, или почти закрываются) следующие вопросы:

Система сама назначает себе IP из сети 169. Получение IP-адреса (Automatic Private IP Addressing или APIPA). 0. 254. Такая система позволяет избежать конфликтов, а адрес из этой сети называют link-local — в том числе и потому, что эти адреса не маршрутизируются. 0/16 (кроме сеток /24 в начале и конце диапазона), основываясь на MAC-адресе и генераторе псевдослучайных чисел.

Система анонсирует свое сетевое имя, и каждый компьютер работает с ним как с DNS, храня записи у себя в кэше. Поиск по имени. Apple использует технологию mDNS (Multicast DNS), а Microsoft — LLMNR (Link-local Multicast Name Resolution), упомянутую в статье «Домены, адреса и Windows: смешивать, но не взбалтывать».

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

При всех плюсах Zeroconf — без каких-либо сакральных знаний можно собрать рабочую сеть, просто соединив компьютеры на физическом уровне, — IT-специалистам он может даже мешать.

Немного раздражает, не так ли?

В системах Windows для отключения автонастройки на всех сетевых адаптерах необходимо создать параметр DWORD с именем IPAutoconfigurationEnabled в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters и поставить ему значение 0.

Чтоб не мучаться со статическими настройками каждого компьютера, были созданы специальные протоколы, включая героя дня — DHCP. Разумеется, Zeroconf подходит разве что для небольших изолированных сетей (например, встретились с приятелем с ноутбуками, соединили их по Wi-Fi и давай играть Diablo II, не тратя время на какие-то сервера), да и выводить локальную сеть в интернет тоже хочется.

Если немного упростить принцип его работы, то выглядело это так: клиент делал запрос на широковещательный адрес сети, сервер его принимал, находил в своей базе данных привязку MAC-адреса клиента и IP — и отправлял в ответ IP. Одна из первых реализаций протокола для выдачи IP-адресов появилась более 30 лет назад и называлась RARP (Reverse Address Resolution Protocol).

Схема работы RARP протокола.

Но у протокола были минусы: нужно было настраивать сервер в каждом сегменте локальной сети, регистрировать MAC-адреса на этом сервере, а передавать дополнительную информацию клиенту вообще не было возможности. И все вроде работало. Поэтому на смену ему был создан протокол BOOTP (Bootstrap Protocol).

В отличие от RARP, протокол уже поддерживал relay — небольшие сервисы, которые пересылали запросы «главному» серверу. Изначально он использовался для бездисковых рабочих станций, которым нужно было не только выдать IP-адрес, но и передать клиенту дополнительную информацию, такую, как адрес сервера TFTP и имя файла загрузки. Вот только оставалась необходимость ручной настройки таблиц и ограничение по размеру для дополнительной информации. Это сделало возможным использование одного сервера на несколько сетей одновременно. Как результат, на сцену вышел современный протокол DHCP, который является совместимым расширением BOOTP (DHCP-сервер поддерживает устаревших клиентов, но не наоборот).

Достигается это за счет менее тривиальной процедуры получения адреса. Важным отличием от устаревших протоколов является возможность временной выдачи адреса (lease) и передачи большого количества разной информации клиенту. Если в старых протоколах схема была простая, вида запрос-ответ, то теперь схема следующая:

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

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

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

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

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

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

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

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

Настройка под номером 6 — это серверы DNS, назначаемые клиентам, 15 — суффикс DNS. Option 6 и Option 15. Начнем с простого. Настройка MikroTik под спойлером. Назначение суффикса DNS может быть полезным при работе с доменными ресурсами в недоменной сети, как я описывал в статье «Как мы сокращали персонал через Wi-Fi».

Настройка MikroTik, option 15

#Добавляем опцию 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

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

Настройка MikroTik, option 6

#настройка опций, обратите внимание, что 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

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

/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, необходимо добавить и маршрут по умолчанию.

Настройка маршрутов

0. Предположим, нам нужно добавить клиентам маршрут вида dst-address=10. 0/24 gateway=192. 0. 88. 168. 168. 2, а основным шлюзом будет 192. 1. 88. Приведем это все в HEX:

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

/ip dhcp-server option add code=121 name=classless value=0x0A0000c0a8580200c0a85801

Подробнее можно прочитать в статье «Mikrotik, DHCP Classless Route».

Если по каким-то причинам в организации используется непрозрачный прокси, то удобно будет настроить его у клиентов через специальный файл wpad (pac). Option 252. Автоматическая настройка прокси-сервера. К сожалению, в MiroTik нет встроенного веб-сервера для размещения этого файла. Пример настройки такого файла разобран в материале «Proxy Auto Configuration (PAC)». Можно использовать для этого пакет hotspot или возможности metarouter, но лучше разместить файл где-либо еще.

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

После настройки DHCP-Relay на маршрутизаторе в информации о клиентах появятся поля Agent Circuit ID и Agent Remote ID, где первое — идентификатор порта коммутатора, а второе — идентификатор самого коммутатора.

Выдача адресов с option 82.

Для удобства восприятия при анализе журнала DHCP можно использовать скрипты. Информация выдается в шестнадцатиричном формате. Например, решение для решения от Microsoft опубликовано в галерее скриптов Technet под названием «Декорирование DHCP опции 82».

Об этом чуть подробнее. Также опция Option 82 активно используется в системе биллинга провайдеров и при защите сети от посторонних вмешательств.

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

Ответы 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.

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

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

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

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

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

Разберем более практичные варианты.

С подробным описанием технологии и настройками можно ознакомиться в официальной документации. В системах Windows Server начиная с 2012 система резервирования DHCP работает «из коробки», в режиме балансировки нагрузки (active-active) или в режиме отказоустойчивости (active-passive). Отмечу, что отказоустойчивость настраивается на уровне зоны, поэтому разные зоны могут работать в разном режиме.

Настройка отказоустойчивости DHCP-сервера в Windows.

Подробнее можно почитать в материале «Два DHCP сервера на Centos7...» В ISC DHCP Server для настройки отказоустойчивости используется директива failover peer, синхронизацию данных предлагается делать самостоятельно — например, при помощи rsync.

Один из вариантов решения задачи был озвучен на MUM RU 18, а затем и опубликован в блоге автора. Если же делать отказоустойчивое решение на базе MikroTik, то без хитростей не обойтись. Тогда выдавать адрес будет сервер с меньшей задержкой, а с большей задержкой — только при выходе из строя первого. Если вкратце: настраиваются два сервера, но с разным параметром Delay Threshold (задержка ответа). Синхронизацию информации опять же приходится делать скриптами.

Лично я в свое время изрядно потрепал себе нервов, когда в сети «случайно» появился роутер, подключенный в локальную сеть и WAN, и LAN интерфейсами.

Расскажите, а вам приходилось сталкиваться с проказами DHCP?

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть