Release dhcp ip address windows

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов рунета Pyatilistnik.org. В прошлый раз я вам подробно показал, как решается ошибка CredSSP при входе на удаленный рабочий стол. Сегодня мы с вами поговорим еще об одной интересной ситуации с которой может столкнуться любой системный администратор в своей практике, мы разберем вопрос, как обновить или перезапросить IP-адрес на компьютере, рассмотрим ситуации, когда это необходимом сделать, уверен что новичкам будет весьма полезно.

Зачем перезапрашивать IP адрес?

Давайте мы с вами разберем ситуации при которых вам потребуется сделать запрос на обновление IP-адреса.

1. В большинстве провайдерских и корпоративных сетях, IP адреса назначаются автоматически за с чем службы DHCP, это позволяет минимизировать ошибки. Бывают ситуации, что по какой-то причине вы не можете связаться с сервером DHCP, в результате ваш компьютер сам себе назначает IP-адрес из диапазона APIPA (169.254.X.X). Если вы получили такой адрес, то вы не сможете обратиться с данного компьютера практически никуда, кроме, как к такому же компьютеру или устройству имеющему адрес из 169.254.X.X. После обращения в тех поддержку или самостоятельному устранению причины такого поведения вам нужно выполнить запрос на обновление IP адреса компьютера.
2. Вторая ситуация связана с тем, что ваш компьютер и другой получили одинаковые адреса, тем самым вызвав конфликт IP, об этом мы уже говорили. Как говорится, кто первый встал того и тапки, в такой ситуации, второму участнику, кто позже получил адрес, потребуется его перезапросить у DHCP.
3. Третья ситуация при которой нужно обновить IP адрес, это когда на одном устройстве вы хотите его освободить дабы отдать другому. Например вы хотите отдать айпишник принадлежащий компьютеру в пользу сетевого оборудования, которое было заранее настроено именно под них или принтеру.
4. Четвертый вариант, ваш устройство перенесли в другой сегмент сети и другой VLAN, чтобы поймать новые настройки необходимо сделать новый запрос на обновление.

Методы обновления IP адреса компьютера

Показывать все манипуляции я буду на моей тестовой виртуальной машине с Windows 10, но все методы будут актуальны и для других версий ОС, будь то клиентские или серверные релизы. Как видим у меня есть неопознанная сеть, по какой-то причине я не смог из этой системы достучаться до моего DHCP сервера, например отошел сетевой шнурок или сетевой администратор включил данный порт не в тот VLAN. Мы решили данную проблему и хотели бы обновить IP, какие наши действия?

• Первый метод, это использования центра управления сетями. Универсальный метод попасть в список ваших сетевых адаптеров, работающий на любой версии Windows, заключается в том чтобы нажать сочетание клавиш WIN+R и в окне выполнить ввести ncpa.cpl.

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

Через правый клик отключаем сетевой интерфейс

Он побледнеет, щелкаем правым кликом и включаем его

В итоге мне удалось получить ip адрес автоматически от моего DHCP сервера

так же попасть в центр управления сетями вы можете в Windows 10, через правый клик по значку сети, выбрав пункт «Открыть параметры сети и интернет».

Тут вы можете в пункте «Просмотр свойств сети» увидеть текущие настройки по IP, чтобы идентифицировать проблему не того адреса.

А если нажать «Центр управления сетями и общим доступом»

То вас перекинет уже в нужную оснастку, где вам необходимо будет нажать «Изменение параметров адаптера«.

В Windows 7 и 8.1 все еще проще, достаточно просто на значке сети выбрать пункт «Центр управления сетями и общим доступом».

• Второй метод обновить ip адрес компьютера, это использование командной строки Windows. Открываем cmd и смотрим текущие настройки командой:

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

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

• Третий метод обновить ip адрес, это использование PowerShell. Запускаем оснастку PowerShell и пишем аналог команды ipconfig.

или же более подробную информацию через команду:

Я виду автонастроенный IP-адрес APIPA (169.254.234.232)

Теперь вы можете выполнить:

К сожалению своих аналогов в виде командлетов в PowerShell нет для запроса IP-адреса.

Но можно пойти еще вот таким путем, отключив и включив сетевой адаптер.

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

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

Удаленное обновление IP адреса на компьютере

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

Резервация статических адресов на DHCP сервере в Windows Server 2016

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

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

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

Настройка DHCP для существующих клиентов DHCP

Допустим клиент DHCP сервера уже получил динамический IP адрес с вашего DHCP сервера (о том, что адрес динамический свидетельствует дата окончания резервации в поле Lease Expiration в секции Address Leases конкретной DHCP области).

Чтобы зафиксировать данный IP адрес за клиентом, щелкните по нему правой кнопкой и выберите пункт Add to Reservation.

После этого в папке Reservations появится новая запись резервации IP адреса за данным клиентом.

Чтобы удалить резервацию, просто удалите запись из папки Reservations.

Настройка DHCP резерваций для новых клиентов

Чтобы зафиксировать IP адрес для новых клиентов (которые еще не получали адрес с DHCP сервера, или получили адрес из динамического диапазона) вам нужно знать MAC адрес (аппаратный адрес) сетевой карты клиента. Например, мы хотим установить новый сетевой принтер и закрепить за ним конкретный IP адрес.

В консоли DHCP найдите и разверните DHCP зону, в которой нужно создать резервацию. Щелкните ПКМ по папке Reservations и выберите пункт New Reservation.

В появившемся окне укажите имя резервации (Reservation name), фиксируемый IP адрес, MAC адрес устройства, и (опционально) его описание и нажмите кнопку Add.

Теперь, при если принтер включить в сеть, по его MAC адресу DHCP сервер определит, что за ним уже закреплен адрес и назначит его принтеру.

Создаем DHCP резервации из командной строки PowerShell

Конечно, DHCP резервации можно заводить не из графической консоли, а из командной строки PowerShell. Для этого используется командлет Add-DhcpServerv4Reservation.

Первый пример показывает, как создать резервацию для уже устройтсва, уже получившего IP адрес.

Get-DhcpServerv4Lease -ComputerName «dhcpsrv1.vmblog.ru» -IPAddress 192.168.1.11 | Add-DhcpServerv4Reservation -ComputerName

Второй пример – добавляет произвольную DHCP резервацию (нужно указывать MAC адрес):

Add-DhcpServerv4Reservation -ScopeId 10.10.10.0 -IPAddress 192.168.1.8- ClientId «F0-11-DA-12-02-7A» -Description «HP Sender 2100»

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

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

9.2 Процесс получения IP-адреса по DHCP. DHCP-клиент и DHCP-сервер

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

9.2.1 Введение

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

9.2.2 Упрощенный алгоритм взаимодействия DHCP-сервера и DHCP-клиента.

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

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

1. Как и в любой порядочной схеме клиент-сервер, взаимодействие по DHCP инициирует клиент. Когда клиент просыпается и осознает, что сетевые настройки нужно получить по DHCP, он формирует специальное широковещательное сообщение, называемое DHCPDISCOVER, этим сообщением он пытается найти DHCP-сервер в своей сети. Вы же помните, что широковещательные сообщения в протоколе Ethernet не выходят за пределы канальной среды?
2. Если в канальной среде с клиентом находится сервер, то он получит DHCPDISCOVER, если сервера нет, то, возможно, это сообщение получит DHCP Relay Agent и перешлет его серверу, если нет и его, то клиент обломится.
3. Но представим, что сервер есть и сообщение он получил. В ответ на DHCPDISCOVER сервер сформирует сообщение, называемое DHCP-предложением или на древнерусском DHCPOFFER. В сообщение DHCPOFFER содержится IP-адрес, который сервер хочет предложить клиенту и другая информация, которая может пригодиться. Сообщение DHCPOFFER может быть отправлено сервером как broadcast, так и unicast, ведь мак-адрес клиента сервер уже изучил. От чего это зависит мы увидим чуть позже.
4. В нашей сети может быть несколько DHCP-серверов, и они все могут получить DHCPDISCOVER от клиента и направить ему DHCPOFFER. Естественно, клиент их все получит и обычно выберет первое неконфликтное предложение от одного единственного сервера. В ответ на выбранный DHCPOFFER клиент сформирует сообщение DHCPREQUEST, из которого будет понятно, с каким сервером он станет дальше дружить. DHCPREQUEST – широковещательное сообщение, это сделано специально, чтобы все сервера в сети видели, какие параметры выбрал клиент и с кем он дальше решил работать.
5. Все серверы получают DHCPREQUEST, но только выбранный сервер продолжит взаимодействие с клиентом, на DHCPREQUEST сервер ответит сообщением DHCPACK, которое служит подтверждением или, если хотите, официальным разрешением от сервера на использование клиентом выбранного IP-адреса.
6. Как только клиент получил сообщение DHCPACK, он переходит в рабочее состояние и смело пользуется IP-адресом.

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

9.2.1 DHCP сообщения, которыми обмениваются клиент и сервер, когда клиент пытается получить IP-адрес

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

9.2.3 DHCP-клиент и DHCP-сервер, базовая настройка.

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

9.2.2 Схема сети для демонстрации взаимодействия между DHCP-клиентом и сервером

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

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

9.2.3.1 Настройка протокола DHCP на сервере и клиенте в Cisco Packet Tracer

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

9.2.3 Настройки протокола IP на DHCP сервере

Серверу я не стал давать адрес шлюза по умолчанию, так как серверу не нужен доступ в Интернет, где найти IP настройки для устройств в Cisco Packet Tracer, вы уже должны знать, показывал и не один раз. Следующим пунктом нашей программы будет настройка DHCP на сервере. Для этого перейдите на вкладку Services и в левом меню выберете DHCP.

9.2.4 Настройки DHCP на сервере

Обратите внимание, здесь уже заполнены поля Start IP Address и Subnet Mask, мы же еще помним, что и клиент, и сервер должны находиться в одной канальной среде, чтобы было всё гуд. Когда мы назначили IP-адрес на интерфейс сервера, Cisco Packet Tracer сам назначил значения в эти поля за нас, если IP-адрес не назначать, то в этих полях будут унылые нули.

Предлагаю пока не трогать эти поля, а изменить значения у полей Pool Name и Default Gateway. Мои настройки показаны ниже.

9.2.5 Продолжаем настраивать DHCP сервер

Все изменения я выделил, для начала был включен DHCP при помощи чекбокса, затем я дал имя новому пулу IP-адресов, который сервер будет использовать для выдачи клиентам, а также была указана дополнительная опция в виде адреса шлюза по умолчанию. Чтобы пул был добавлен, следует нажать кнопку Add, после чего внизу у нас появится два пула IP-адресов: один – этот тот, что создали мы, второй – это тот, что был создан Cisco Packet Tracer автоматически. Чтобы не было проблем, удалите второй, для этого его нужно выделить и нажать на кнопку Remove, если не получится удалить автоматический пул, настройте его так, как я показал и удалите свой собственный. На втором сервере настройки нужно сделать аналогичными, разница будет только в IP-адресе, который вы назначите серверу.

Итак, что мы сделали, чтобы настроить DHCP-сервер, а сделали мы следующее:

1. Настроили IP-адрес на интерфейсе сервера.
2. Создали пул IP-адресов, из которого сервер будет выдавать настройки клиенту.
3. Дали этому пулу имя, так как пулов у DHCP-сервера может быть несколько.
4. Указали начальный IP-адрес пула (поле Start IP Address), это означает, что сервер будет пытаться выдавать IP-адреса, начиная с 192.168.0.1 (а не с 192.168.0.0, ведь сервер понимает, что это номер сети, а также он немного в курсе о том, что в 21 веке мы все используем маску подсети переменной длины, а про классовые сети мы все уже забыли).
5. Также мы дали указание серверу выдавать две опции: маску подсети и IP-адрес шлюза по умолчанию.

Собственно, это всё, что нам сейчас необходимо. Сейчас мы сконфигурировали DHCP-сервер в режиме автоматической выдачи динамических IP-адресов, для нас этот режим самый интересный.

9.2.3.2 Настройки DHCP на клиенте

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

9.2.6 Настройка протокола DHCP на клиенте

Фразы «Гибкая настройка» и Cisco Packet Tracer плохо совместимы, в реальных операционных системах вы сможете задать: какие параметры рабочая станция должна получить по DHCP, а какие параметры вы можете ввести своими руками. Но это нам сейчас не интересно, нам важно разобраться с тем, как клиент получает IP-адрес от DHCP сервера и это мы сделаем. Настройка протокола DHCP на клиенте на этом закончена.

9.2.4 Как клиент получает IP-адрес по DHCP

Схема собрана и настроена, теперь нам надо понять, как клиент получает IP-адрес по DHCP от сервера. В тот момент, когда вы завершите настройку DHCP на клиенте, машина поймет, что она не имеет IP-адрес, а также увидеть указание о том, что она должна получить этот IP-адрес по DHCP. Поэтому первое, что сделает DHCP-клиент – это сформирует запрос DHCPDISCOVER, которым попытается найти сервер.

9.2.7 Клиент сформировал сообщение DHCPDISCOVER

На зеленый пакет, сформированный сервером, не обращайте внимание. Нас интересует желтый пакет, который сформировал клиент, это и есть DHCPDISCOVER, давайте на него посмотрим.

9.2.8 Сообщение DHCPDISCOVER в Cisco Packet Tracer

Здесь сразу видно, что пртокол DHCP работает на прикладном уровне моделей OSI 7 и TCP/IP. Также тут видно, что клиент еще не разу не получал IP-адрес от сервера и даже не знает, где этот сервер находится. На транспортном уровне протокол DHCP инкапсулируется в UDP дейтаграммы, когда клиент делает запрос серверу, то в качестве порта источника он выбирает 68 порт, а в качестве порта назначения используется 67 порт.

Клиент не знает IP-адрес сервера, да и своего у него еще нет, поэтому на сетевом уровне в качестве IP-адреса источника он использует IP-адрес 0.0.0.0, а в качестве IP-адреса назначения используется 255.255.255.255. Мы видим, что это широковещательный запрос.

На канальном уровне клиент указывает свой мак-адрес в качестве источника и широковещательный мак-адрес в качестве назначения. Ниже показана структура пакета DHCPDISCOVER, но с ней мы будем разбираться на примере дампа Wireshark.

9.2.9 Структура пакета DHCPDISCOVER в Cisco Packet Tracer

А сейчас продолжим разбираться и посмотрим, что будет, когда запрос DHCPDISCOVER дойдет до серверов.

9.2.10 Запрос DHCPDISCOVER дошел до всех участников канальной среды

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

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

Поскольку у нас канальная среда Ethernet, то для проверки будет идеальным протокол ARP, он позволяет опросить все устройства в канальной среде. Вы же знаете, что при помощи ARP-запроса машины узнают мак-адреса по известному IP-адресу. И дело тут в том, что серверу известен IP-адрес, который он хочет выдать клиенту, он его и использует в ARP-запросе и кричит на всю канальную среду: кто использует IP-адрес такой-то?

ARP-запрос – это зеленый пакет, на котором нет значка паузы. Наши сервера настроены одинаково, базы данных у них сейчас одинаковые, поэтому и ARP-запросы они делают одинаковые, сам запрос показан ниже.

9.2.11 DHCP-сервер делает ARP запрос, чтобы проверить занятость IP-адреса

Тут мы видим, что наш первый сервер спрашивает всех соседей по канальной среде: у кого IP-адрес 192.168.0.1, я сервер с IP-адресом 192.168.0.2? Но, как мы помним, адрес 192.168.0.1 мы настроили на роутере, он уже занят. И ничего страшного, что этот адрес занят нашим маршрутизатором, маршрутизатор получит ARP-запрос и любезно на него ответит своим ARP-ответом, получив ответ, наши сервера поймут, что адрес 192.168.0.1 занят и нужно искать следующий адрес для выдачи.

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

9.2.13 ARP-запрос от DHCP сервера, на который никто не ответит

Тут опять же, всё зависит от конкретного DHCP-сервера, ARP-запрос может быть повторен, а после него сервер может еще и попробовать опросить адрес по ICMP, все это нужно, чтобы убедиться, что адрес еще никто не занял, а только после этого формировать сообщение DHCPOFFER.

9.2.14 Сообщение DHCPOFFER от первого DHCP-сервера клиент уже получил, а от второго сервера OFFER еще в буфере коммутатора

На рисунке показано ниже, что сообщение DHCPOFFER широковещательное, хотя это бывает и не всегда так, тут учитывается два момента:

1. Клиент может сообщить DHCP-серверу о том, как он хочет получать ответ: broadcast или unicast.
2. Выбор способа доставки сообщения DHCPOFFER может зависеть от реализации самого сервера и некоторых значений в DHCP пакете.

2.15 Сообщение DHCPOFFER в Cisco Packet Tracer

В любом случае, для доставки DHCPOFFER у сервера есть возможность использовать на канальном уровне как broadcast, так и unicast, ведь мак-адрес клиента он уже изучил, когда получил сообщение DHCPDISCOVER. На рисунке показано, что клиент получил DHCPOFFER от первого сервера. DHCPOFFER второго сервера находится еще в буфере коммутатора, оба сервера предлагают клиенту адрес 192.168.0.4.

9.2.16 Внутренности пакета DHCPOFFER

Рисунок выше показывает, что при первом получении IP-адреса по DHCP в своем пакете сервер указывает свой IP-адрес, а в качестве адреса клиента используется 0.0.0.0. Поскольку это сообщение сформировано сервером, то порт источника 68, а порт назначения 67. Если сейчас заглянуть во внутренности пакета DHCPOFFER, то без всяких пояснений можно увидеть несколько интересных моментов.

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

Получив DHCPOFFER клиент не забирает себе IP-адрес, сперва он должен убедиться, что этот адрес еще никто не использует, для этого он делает ARP-запрос в сеть, в данном случае ему был предложен адрес 192.168.0.4, значит и спрашивать клиент будет: кто в сети использует адрес 192.168.0.4? Клиенты не используют ICMP для проверки, им это не надо, а вот серверам надо, в дальнейшем мы поймем – в каких ситуациях это действительно необходимо.

Если клиент не получит ARP-ответ на свой запрос, то он может смело соглашаться на предложение DHCP-сервера, при этом соглашаться он будет на предложение того сервера, от которого был получен первый DHCPOFFER. Если клиент получит ARP-ответ на свой запрос, то он отправит серверу сообщение DHCPDECLINE, в котором сообщит о том, что он отказывается от его предложения, если же ARP-ответа не будет, то клиент сформирует широковещательное сообщение DHCPREQUEST и отправит его. Таким образом все сервера поймут две вещи:

1. С каким сервером клиент захотел работать.
2. На какой IP-адрес клиент согласился.

В процессе написания я столкнулся с еще одной странностью в Cisco Packet Tracer: после ARP-запроса клиент получил IP-адрес и на этом всё закончилось. Поэтому дальше только словесное описание, а потом мы его дополним дампами из Wireshark.

DHCP сервер, с которым клиент решил сотрудничать, тоже получит DHCPREQUEST и на этот REQUEST сервер должен будет выслать подтверждение в виде DHCPACK. Так сервер сообщает клиенту: пользуйся адресом на здоровье, я внес в свою базу данных информацию о том, что IP-адрес 192.168.0.4 закреплен за тобой. Сообщение DHCPACK может быть отправлено как адресно, так и широковещательно, чаще всего оно отправляется адресно.

Если в командной строке клиента сейчас выполнить команду ipconfig, то можно будет увидеть настройки, которые клиент получил от сервера.