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

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

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

9.3.1 Введение

Здесь мы рассмотрим структуру DHCP пакета и поговорим о их назначении DHCP-сообщений. В частности будут рассмотрены такие виды DHCP сообщений как: DHCPDISCOVER, DHCPOFFER, DHCPREQUEST и DHCPACK. Дам небольшое пояснение по поводу того, что я буду подразумевать под словом DHCP-пакет, а что под DHCP-сообщением. Под первым я буду понимать физическую сущность со строгой структурой, а под вторым я буду понимать логический смысл, который несет в себе физическая сущность, пакет всего один, а сообщений много и они разные.

9.3.2 Общая структура DHCP пакета, назначение его полей и их размер

Мы довольно наглядно рассмотрели процесс получения IP-адреса по DHCP в Cisco Packet Tracer, но хотелось бы понимать то, как устроены пакеты DHCP, которыми обменивается клиент и сервер. Тут у меня для вас две новости:

1. Начну с хорошей. При обмене различными сообщениями и клиент, и сервер используют пакеты с одинаковой структурой, а это означает, что поля в различных DHCP-сообщениях имеют одинаковые названия и одинаковый размер, за исключением поля Options, о котором мы говорили, в записи про DHCP протокол, но в них указываются разные значения.
2. Вторая новость не то что бы плохая, но всё же. Различного рода сообщений в DHCP много и не со всеми вы будете сталкиваться и не все вам будут нужны, но если столкнетесь, то придется почитать RFC, чтобы понять, как это должно работать, а потом заглянуть в дамп, чтобы увидеть, как это работает по факту.

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

9.3.1 Структура DHCP-пакета, поля и их размер

Сама по себе картинка нам еще ничего не дает, кроме названия полей в DHCP-пакета, также мы видим, что пакет разбивается на строки (иначе, машинные слова), каждая строка 32-а бита. Крайний левый бит в слове имеет нулевой порядковый номер, а крайний правый бит 31-ый. Размер всех полей в битах кратен числу 8.

Давайте теперь поговорим более подробно о каждом поле DHCP пакета. Для их описания я подготовил таблицу.

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

9.3.3 Сообщение DHCPDISCOVER или как клиент ищет DHCP сервер?

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

9.3.2 Как инкапсулируется и передается по сети сообщение DHCPDISCOVER

Всё самое важное подсвечено красным цветом. Мы видим, что в качестве мак-адреса источника клиент подставил свой мак-адрес, а вот мак-адрес сервера он не знает, поэтому использует широковещательный мак-адрес. Даже если клиент будет знать IP-адрес DHCP-сервера, ему это не поможет, ведь для того, чтобы обратиться к серверу по протоколу IP, клиент должен сделать ARP-запрос, а как он это сделает, если у него еще нет IP-адреса?

В заголовке IP-пакета в качестве адреса источника клиент использовал 0.0.0.0, а IP-адрес назначения опять широковещательный – 255.255.255.255. DHCP упаковывается на транспортном уровне в UDP, поскольку сообщение DHSPDISCOVER генерирует клиент, он в качестве порта источника использует значение 68, а в качестве порта назначения 67. Ну и наконец мы видим, что Wireshark смог определить, что это сообщение DHCPDISCOVER. Попробуем определить и мы.

9.3.3 Формат сообщения DHCPDISCOVER

Для этого заглянем внутрь DHCP-пакета и проанализируем значения его полей. В самом верху мы видим тип сообщения Boot Request (это поле opcode), значение 1 говорит нам о том, что это клиент что-то посылает серверу. Следующих два поля сообщают нам, что на канальном уровне используется Ethernet и указана длина аппаратного адреса. Поле Hops имеет значение 0, а значит клиент считает, что он находится с сервером в одной канальной среде. Когда клиент начал общение с сервером, он сгенерировал уникальный Transaction ID, по которому можно будет отличить этот процесс получения IP-адреса от какого-нибудь другого. Поле Second Elapsed никому не интересно, тут обычно стоит 0.

Флаги – отдельная тема, сейчас мы их пропустим. У клиента еще нет и не было IP-адреса, клиент не знает IP-адрес сервера, клиент ничего не знает по DHCP Relay Agent, клиент сам себе не может выдать IP-адрес, поэтом следующих четыре поля имеют значения 0.0.0.0. В поле Client MAC Address клиент сообщает свой мак-адрес серверу. А вот поле Client Hardware Address Padding различается для машин с Windows и Linux, сейчас вы видите значение для Windows, это поле мы обсудим позже.

Далее клиент сообщает серверу о том, что ему не нужно сообщать hostname сервера и не надо давать ссылку на Boot-файл. Ну а поле Magic Cookie сообщает о том, что начались DHCP опции и нам нужно обратить внимание на следующий рисунок.

9.3.4 DHCP опции, которые передает клиент серверу в сообщение DHCPDISCOVER

Во-первых, стоит сразу отметить, что количество опции, да и сами опции, которые будут в сообщение DHCPDISCOVER зависят от настроек клиента. Первая опция имеет код 53, так клиент сообщает всем в сети, что данное сообщение является сообщением DHCPDISCOVER. Опция с кодом 61 используется клиентом, чтобы сообщить свой мак-адрес. В опции с кодом 50 клиент сообщает, что хотел бы получить от сервера IP-адрес 192.168.0.100. Опция с кодом 12 используется клиентом, чтобы сообщить свой hostname.

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

Список опций завершает опция с кодом 255, так сервер поймет, что опций больше не будет и само DHCP-сообщение закончилось.

9.3.4 Сообщение DHCPOFFER или как сервер предлагает клиенту IP-адрес?

Перейдем к сообщение DHCPOFFER, которым сервер отвечает на запрос DHCPDISCOVER от клиента, тут самый первый вопрос, который у вас должен возникнуть: а как сервер отправляет сообщение DHCPOFFER – broadcast или unicast. Правильным будет ответ: сервер может передавать сообщение DHCPOFFER как широковещательно, так и адресно, вот что написано в RFC протокола DHCP.

Если поле giaddr в сообщении DHCP от клиента отлично от 0, сервер передает все отклики на сообщения в порт DHCP server транслятору BOOTP, адрес которого указан в поле giaddr. Если giaddr = 0, а поле ciaddr отлично от нуля, сервер передает сообщения DHCPOFFER и DHCPACK по индивидуальному адресу ciaddr. Если giaddr = 0, ciaddr = 0 и установлен флаг broadcast, сервер передает сообщения DHCPOFFER и DHCPACK по широковещательному адресу 0xffffffff. Если флаг broadcast не установлен, а giaddr и ciaddr имеют значение 0, сервер передает сообщения DHCPOFFER и DHCPACK по индивидуальному аппаратному адресу клиента и yiaddr. Во всех случаях, когда giaddr = 0, сервер отправляет сообщения DHCPNAK по широковещательному адресу 0xffffffff.

9.3.5 DHCPOFFER — сообщение, которое отправляет сервер в ответ на DHCPDISCOVER

Если посмотреть на дамп протокола IP, то можно будет увидеть, что сервер не просто направил клиенту DHCPOFFER юникастом, но и более того, в поле IP-адрес назначения был подставлен IP-адрес, который был запрошен клиентом в сообщение DHCPDISCOVER. Главным образом такое поведение DHCP-сервера связано с тем, какие флаги были получены им от клиента.
Обратите внимание, что в сообщение DHCPOFFER сервер еще не использует предлагаемый IP-адрес в поле Client IP Address, там еще находятся унылые нули. В поле Your IP Address сервер предлагает клиенту тот IP-адрес, который он у него запросил, естественно, перед тем как его предложить, сервер убедился в том, что этот адрес свободен. Как видим, сообщение DHCPOFFER по своему содержимому не сильно отличается от DHCPDISCOVER, теперь давайте посмотрим на опции, которые сервер предложил клиенту.

9.3.6 DHCP опции в сообщение DHCPOFFER

Во-первых, опции в сообщение DHCPOFFER, как и в любых других сообщениях, начинаются с Magic Cookie, а заканчиваются 255 опцией. Во-вторых, сервер не знал всех опций, которые у него попросил клиент, поэтому выдал то, что смог. После Magic Cookie сервер сообщает, что этот пакет несете в себе сообщение DHCPOFFER. Следующим шагом он сообщает клиенту свой идентификатор. А вот опция с кодом 51 несет в себе очень важную информацию о времени аренды IP-адреса, об этом времени у нас будет отдельный разговор.

Еще из полезного сервер предложил в качестве опций клиенту IP-адрес шлюза по умолчанию, маску подсети и адрес DNS-сервера.

9.3.5 Сообщение DHCPREQUEST или как клиент делает запрос на получение IP-адреса?

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

ПРИМЕЧАНИЕ: здесь мы пропускаем все проверки на занятость/свободность IP-адреса, это мы обсудили при прошлом разговоре и сейчас считаем, что они есть и в результате этих проверок IP-адрес свободен.

Давайте посмотрим, как выглядит сообщение DHCPREQUEST в дампе Wireshark.

9.3.7 Сообщение DHCPREQUEST или как клиент делает запрос на получение IP-адреса

Сразу бросается в глаза то, что DHCPREQUEST отправляется не адресно, а широковещательно, тут дело в том, что клиент должен сообщить всем серверам о том, какой адрес он хочет получить и с каким сервером он хочет продолжать взаимодействие. Все поля сверху, за исключением поля Message Type, имеют точно такие же значения, как и в сообщение DHCPDISCOVER, а вот поля опций изменились, давайте на них и посмотрим.

[php]
Magic cookie: DHCP
Option: (53) DHCP Message Type (Request)
Length: 1
DHCP: Request (3)
Option: (61) Client identifier
Length: 7
Hardware type: Ethernet (0×01)
Client MAC address: IntelCor_b3:71:b7 (bc:a8:a6:b3:71:b7)
Option: (50) Requested IP Address
Length: 4
Requested IP Address: 192.168.0.100
Option: (54) DHCP Server Identifier
Length: 4
DHCP Server Identifier: 192.168.0.1
Option: (12) Host Name
Length: 15
Host Name: DESKTOP-B0A442D
Option: (81) Client Fully Qualified Domain Name
Length: 18
Flags: 0×00
A-RR result: 0
PTR-RR result: 0
Client name: DESKTOP-B0A442D
Option: (60) Vendor class identifier
Length: 8
Vendor class identifier: MSFT 5.0
Option: (55) Parameter Request List
Length: 14
Parameter Request List Item: (1) Subnet Mask
Parameter Request List Item: (3) Router
Parameter Request List Item: (6) Domain Name Server
Parameter Request List Item: (15) Domain Name
Parameter Request List Item: (31) Perform Router Discover
Parameter Request List Item: (33) Static Route
Parameter Request List Item: (43) Vendor-Specific Information
Parameter Request List Item: (44) NetBIOS over TCP/IP Name Server
Parameter Request List Item: (46) NetBIOS over TCP/IP Node Type
Parameter Request List Item: (47) NetBIOS over TCP/IP Scope
Parameter Request List Item: (119) Domain Search
Parameter Request List Item: (121) Classless Static Route
Parameter Request List Item: (249) Private/Classless Static Route (Microsoft)
Parameter Request List Item: (252) Private/Proxy autodiscovery
Option: (255) End
Option End: 255

[/php]

Показываю в виде дампа, так как не удалось вывести все опции в одном скрине. Опция 53 сообщает нам о том, что это сообщение у нас DHCPREQUEST. Далее идут знакомые нам уже опции, а вот на опции с кодом 54 мы остановимся (DHCP Server Identifier), этой опцией клиент сообщает все серверам о том, с кем из них он намерен продолжать сотрудничать. Опцией 81 клиент сообщает серверу свое имя, а вдруг пригодится. А в опции 55 клиент пытается упрекнуть сервера, мол, смотри, сколько я у тебя опций запрашивал и что ты мне выдал, ты точно не сможешь дать мне все то, о чем я тебя прошу?

3.6 Сообщение DHCPACK или как сервер назначает IP-адрес клиенту?

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

9.3.8 Сообщение DHCPACK или как сервер подтверждает выдачу IP-адреса клиенту

Обычно сообщение DHCPACK сервер старается выслать клиенту адресно, не прибегая к широковещанию, хотя иногда бывают и исключения. Главным требованием к содержимому сообщения DHCPACK должна быть непротиворечивость тому, что было отправлено в сообщение DHCPOFFER. Пожалуй, это всё, что следовало сказать про DHCPACK.

3.7 Выводы

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