Что произойдет если у dhcp сервера закончится пул адресов

[Конспект админа] Как подружиться с 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?

Источник

Как связаны длительность аренды DHCP и процесс сбора мусора в DNS

В качестве предисловия. При общении с коллегами, отвечая на их вопросы о совместной настройке DNS и DHCP, часто отсылаю их к замечательной статье Шона Айви на Technet. К сожалению, аналогичного материала на русском языке я не находил. В очередной раз, устно переведя её знакомому, я решил оформить письменный перевод, чтобы иметь возможность отсылать к нему.

Привет всем, меня зовут Шон Айви и я US PFE (Premier Field Engineer). Моя специализация — операционная система Windows и службы Active Directory. Проще говоря, я специализируюсь на Active Directory и связанных с ней сетевых службах. Недавно, у трёх разных клиентов, я помогал SCCM-администраторам, у которых была проблема с установкой SCCM агента. В логе ccm.log значилась ошибка Failed to get token for current process (5). Мы обнаружили, что проблема была не в SCCM, а во взаимодействии DNS и DHCP. Как оказалось, другие службы тоже испытывали связанные с этим проблемы, просто либо демонстрировали иные симптомы, либо не демонстрировали их совсем. Давайте поговорим о том почему так получалось и как это можно предотвратить!

Рассмотрим следующий сценарий:

Пока всё хорошо. Это довольно типовой сценарий работы DHCP сервера и всё происходит именно так, как мы ожидаем. Давайте теперь добавим сюда DNS сервер.

Рисунок 1

Итак, у нас в DNS есть два разных имени, ссылающихся на одинаковый IP адрес. И, скорее всего, всё именно так и останется еще минимум 6 дней, пока не истекут описанные выше интервалы. Какие проблемы это может вызвать? Давайте посмотрим.

Проблема

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

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

Рисунок 2

А вот это уже интересно. Во первых, клиент А даже не включен… но мы получаем ответ от его имени. И это ошибка аутентификации! Некоторые из вас уже догадались, что это происходит, когда вы посылаете сеансовый ключ Kerberos предназначенный для одного компьютера другому, но давайте по порядку.

Мы видим, что наш компьютер (Infra-App1) посылает в DNS запрос на имя client-a.corp.contoso.com. В ответ он получает IP адрес 10.0.0.100.

Рисунок 3

Насколько знает DNS, так оно и есть. Клиент А действительно имеет адрес 10.0.0.100, но точно такой же адрес имеет Клиент Б.

Отлично, теперь мы получаем сеансовый ключ Kerberos. Вот только DNS запрос был на имя Клиента А, так что ответ от службы Kerberos также будет на имя клиента А.

Рисунок 4

Рисунок 5

Мы видим запрос на Рисунке 4 и ответ контроллера домена на Рисунке 5.

Теперь, получив ключ, мы можем попытаться подключиться, к тому, что мы считаем Клиентом А.

Рисунок 6

Здесь мы видим сеансовый ключ Kerberos.

И, наконец, мы видим сообщение об ошибке от Клиента А. Почему? Потому, что клиент А это не Клиент А, а Клиент Б.

Рисунок 7

Всё это только подтверждает то, что вы, вероятно, и так знали. Для того чтобы Kerberos отработал нормально, вы должны обратиться с правильным сеансовым ключом к правильному адресату (Если вы хотите узнать больше о Kerberos, почитайте блог Роба Грина «Kerberos для занятых админов» Примечание: аналогичного материала на русском я не нашёл, но с общими сведениями можно ознакомиться вот здесь).

Конечно, всё отлично сработает, если вместо FQDN имени мы обратимся по IP адресу. Почему? Потому, что в этому случае вместо Kerberos будет использована аутентификация NTLM. Используя IP адрес, мы не делаем никаких предположений о том, к какому клиенту мы подключаемся. Мы просто подключаемся по определённому IP адресу. Некоторые из вас могут подумать, что и для FQDN должно сработать. В конце концов, получив ошибку при использовании Kerberos, мы должны переключиться на NTLM, верно? Не совсем. Я не буду углубляться в детали, но мы переключимся на NTLM, только если мы не смогли договориться об использовании Kerberos. Вы можете прочитать об этом подробнее здесь. В любом случае, Kerberos не возвращал нам ошибки, он штатно ответил нам сеансовым ключом.

Как предотвратить

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

Примечание: я рекомендую уменьшить интервал очистки для каждого из этих способов до 1-3 дней. Интервал в 7 дней, используемый по умолчанию, позволяет проблемным записям оставаться в DNS чересчур долго.

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

Поиск DNS записей с одинаковыми IP адресами

Почти всё! Теперь мы понимаем, почему происходит такая ситуация, когда возникает проблема и как её предотвратить. Но как нам легко и быстро найти такие записи, если беда уже случилась? Вы можете легко найти такие парные записи в DNS используя несложный PowerShell скрипт (это, конечно же, не единственный способ).

Ниже приведён образец вывода этого скрипта:

Рисунок 8

Заключение

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

Надеюсь, что статья была вам полезна! Правильная настройка интеграции DNS и DHCP избавит вас от такого рода проблем в вашей сети!

Источник

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

9.4 Время аренды IP-адреса в DHCP или lease time. Как происходит перезапрос и освобождение IP-адреса?

Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем изучать основы работы компьютерных сетей. Продолжаем рассматривать и разбирать протокол DHCP, на этот раз мы рассмотрим срок аренды IP-адреса в DHCP, который передается при помощи опции 51 (Option 51 IP Address Lease Time). В общем, нам нужно понять зачем нужно время аренды и как правильно настроить этот параметр в своей компьютерной сети.

9.4.1 Введение

Сразу скажу, что в DHCP-клиенты получают IP-адреса не насовсем, а на строго определенное время, которое задается на сервере, это время называется временем аренды IP-адреса или lease time. Такой механизм в DHCP необходим, поскольку было бы глупо заставлять сервер постоянно проверять: а пользуется ли клиент выданным IP-адресом? Во-первых, у сервера может быть несколько тысяч или десятков тысяч клиентов, а его ресурсы не бесконечны, во-вторых, представьте, как не экономно расходовалась бы полоса пропускания, если бы сервер проверял доступность клиентов.

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

9.3.2 Зачем нужен срок аренды в DHCP и как его правильно выбрать?

Давайте начнем с того, что поговорим: зачем в протоколе DHCP нужно время аренды IP-адреса и как его правильно выбрать. А затем посмотрим на практике, как это всё работает.

9.3.2.1 Зачем нужно время аренды IP-адреса в DHCP?

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

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

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

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

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

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

9.3.2.2 Рекомендации по выбору и настройки времени аренды в DHCP

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

Для начала представим, что под нашим управлением находится ресторан быстрого питания с суточной пропускной способностью в тысячу человек человек, среднее время, которое посетитель находится в ресторане, составляет не больше 20 минут, да и не каждый посетитель хочет подключаться к нашей сети, чтобы воспользоваться халявным Интернетом. Тогда мы легко можем прийти к выводу, что для того, чтобы все были довольны, нам хватит сети с маской /25, а время аренды IP-адреса должно быть не более 20 минут, если посетитель будет пользоваться нашей сетью дольше 20 минут, то для него ничего страшного не произойдет, его устройство просто продлит время аренды.

Следующий пример. У нас есть офисная сеть с нормальным офисным планктоном, который работает пять дней в неделю по 8 часов. В нашей сети 50 сотрудников, которые раз в год уходят в отпуск на месяц и иногда болеют, все остальное время они работают. Вообще, тут напрашивается статика, но это очень лень, когда есть DHCP-сервер, поэтому смело выставляем время аренды несколько больше, чем 30 дней и берем сеть с маской /26. Все довольны.

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

Ну а что делать, если в гостинице есть важные клиенты, которые в любом случае должны иметь доступ к сети, в этом случае для таких гостей можно зарезервировать IP-адрес и не париться. Заметили, что я все время указывал сравнительно небольшие сетки, которые должен раздавать DHCP-сервер? Почему не стоит создавать большие пулы IP-адресов, даже скажу так: почему не стоит создавать пул больше, чем /24? Дело все в том, что и клиент, и сервер обычно находятся в одной канальной среде, что будет, если клиента заштормит или случится какая другая оказия, правильно, всем остальным клиентам тоже будет плохо, и они не смогут работать, а нас это не устраивает, ведь так? У нас все должны работать. А теперь представьте – каково это – искать заглючившую железку в огромной сети.

9.3.3 Истечение срока аренды IP-адреса или как DHCP-клиент делает повторный запрос?

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

9.3.3.1 Ключевые особенности времени аренды

Ключевые особенности протокола DHCP, связанные с временем аренды мы уже перечислили ранее, но сделали это размыто, сейчас мы просто акцентируем внимание.

Эти особенности стоит помнить, при использовании протокола DHCP.

9.3.3.2 Option 51 IP Address Lease Time

Время аренды сообщает сервер клиенту, это тот процесс, за который отвечает сервер, администратор может изменить время аренды IP-адреса в любой момент. Для того, чтобы DHCP-сервер мог сообщить клиенту время аренды используется Option 51 (IP Address Lease Time). Если я всё правильно помню, то в качестве единиц измерения всегда используются секунды, ниже вы видите фрагмент дампа с сообщением DHCPOFFER, в котором сервер сообщает клиенту время, после которого IP-адрес должен быть освобожден.

9.4.1 Option 51. Сервер сообщает клиенту время аренды IP-адреса в сообщение DHCPOFFER

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

9.3.3.3 Как клиент продлевает время аренды IP-адреса

Срок аренды IP-адреса обычно обозначается буквой Т, но мы для ясности будем считать, что клиент арендовал адрес на 100 секунд, как только он получил этот адрес, пошел отсчет: 100, 99, 98, 97… Но что если клиенту мало 100 секунд, может он хочет побыть в сети немного подольше, снова проходить весь процесс получения IP-адреса, это долго и это broadcast, то есть неудобно. Поэтому клиент сделает попытку продлить IP-адрес, у него есть на это право по истечению половины периода времени аренды, это у нас время равное T/2 или 50 секунд для нашего случая.

Клиент будет пытаться продлить IP-адрес при помощи сообщения DHCPREQUEST, но в отличие от получения, продление отправляется как unicast с использованием IP-адреса того сервера, у которого клиент получил IP-адрес. Если DHCPREQUEST таки дошел до сервера, то он отправит в ответ DHCPACK тоже юникастом, так он сообщает клиенту, что запрос получил и с ним согласен, можно снова начинать отсчет, начиная со 100 секунд.

А что если выдавший IP-адрес сервер вышел из строя, но есть резервный сервер, как поступит клиент? Клиент в этом случае отправит еще одно unicast сообщение на основной сервер на 75-ой секунде (это для нашего случая, а вообще, попытка будет сделана по истечению половины оставшегося времени) при этом, если половина оставшегося времени от времени аренды, это позже, чем 7/8Т, то есть 87.5% времени аренды или 87.5 секунд для нашей ситуации, то следующая попытка продления IP-адреса будет широковещательная.

Как только истекло 87.5 секунд, клиент начнет отправлять DHCPREQUEST в сеть, используя broadcast адрес, чтобы его слышали все, в том числе и резервный DHCP-сервер, если он, конечно, есть. Если резервный сервер есть, то он может продлить аренду клиенту, в этом случае клиент получит DHCPACK, а может отказать клиенту в продлении, например, если у резервного сервера нет пула IP-адресов, в который попадает IP-адрес клиента. Тогда сервер отправит клиенту DHCPNACK, а клиент поймет, что нужно просить другой адрес.

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

9.3.4 Освобождение IP-адреса и получение нового адреса в ОС Windows

В завершении разговора поговорим о том, как происходит освобождения IP-адреса до истечения времени аренды и получение нового IP на компьютерах под управлением Windows 10. Для этого нам потребуется Wireshark, командная строка или эмулятор терминала и стандартная сетевая утилита ipconfig. Запускаем командую строку и для начала выполним команду ipconfig.

Источник