Разное

Лекция dhcp: НОУ ИНТУИТ | Лекция | DHCP и IP-адресация

Содержание

НОУ ИНТУИТ | Лекция | Протокол динамического конфигурирования ЭВМ DHCP

Аннотация: Описан протокол динамического конфигурирования машин DHCP, а также протоколы NAT, PAT и NETBIOS

Введение

Протокол динамической конфигурации ЭВМ DHCP (Dynamic Host Configuration Protocol, RFC-2131, -2132, -2485, -2563, -2610, -2855, -2937, -2939, -3004, -3011, -3046, -3942, -4030, -4039; [6.16], [6.17], [6.18] и [6.19]) служит для предоставления конфигурационных параметров ЭВМ, подключенных к Интернет. DHCP имеет два компонента: протокол предоставления специфических для ЭВМ конфигурационных параметров со стороны DHCP-сервера и механизм предоставления ЭВМ сетевых адресов.

Протокол DHCP используется, помимо загрузки бездисковых станций или Хтерминалов (BOOTP), сервиспровайдерами для пулов модемов, когда число одновременно занятых модемов существенно меньше их полного числа. Это позволяет сэкономить заметное число IP-адресов. Протокол эффективен для случая распределения адресов за Firewall, где для ЭВМ в защищенной зоне все равно бессмысленно выделять реальные IP-адреса.

DHCP построен по схеме клиентсервер, где DHCP-сервер выделяет сетевые адреса и доставляет конфигурационные параметры динамически конфигурируемым ЭВМ.

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

intuit.ru/2010/edi»>DHCP поддерживает три механизма выделения IP-адресов. При автоматическом выделении DHCP присваивает клиенту постоянный IP-адрес. При динамическом присвоении DHCP присваивает клиенту IP-адрес на ограниченное время. При ручном выделении, IP-адрес выделяется клиенту сетевым администратором, а DHCP используется просто для передачи адреса клиенту. Конкретная сеть применяет один или более этих механизмов, в зависимости от политики сетевого администратора.

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

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

Формат сообщений DHCP базируется на формате сообщений BOOTP, чтобы можно было воспользоваться процедурами транспортировки данных, описанными в спецификации BOOTP [6. 7, 6.16], и обеспечить совместимость DHCPсерверов с существующими клиентами BOOTP. Использование агентов транспортировки BOOTP исключает необходимость наличия DHCPсерверов в каждом физическом сегменте сети.

Существует несколько протоколов Интернет, которые так или иначе связаны с проблемой присвоения сетевых адресов. Протокол RARP (Reverse Address Resolution Protocol) [6.9] через расширения, описанные в DRARP (Dynamic RARP [6.5]), не только позволяет определить сетевой адрес, но и включает в себя автоматический механизм распределения IP-адресов.

BOOTP является транспортным механизмом сбора конфигурационной информации. Протокол BOOTP является масштабируемым, определены стандартные расширения [6.11] для нескольких конфигурационных параметров. Морган предложил расширение BOOTP для динамического присвоения IP-адресов. Протокол NIP (Network Information Protocol), использованный в проекте Athena МТИ, предоставляет распределенный динамический механизм выделения IP-адресов [6. 14]. Протокол RLP (Resource Location Protocol [6.1]) служит для нахождения серверов, предоставляющих услуги верхнего уровня. Бездисковые рабочие станции компании Sun Microsystems применяют процедуру загрузки, которая с привлечением механизма RARP, TFTP и RPC, называемого bootparams, предоставляет бездисковой ЭВМ конфигурационную информацию и фрагменты операционной системы.

Имеется предложение по использованию протокола ARP (Address Resolution Protocol) для нахождения и выбора ресурсов [6.6]. Наконец, в RFC Host Requirements [6.3, 6.4] упоминаются специфические требования к конфигурированию ЭВМ и предлагается сценарий инициализации бездисковых ЭВМ.

Протокол DHCP предназначен для предоставления клиентам конфигурационных параметров, описанных в RFC Host Requirements. После получения через DHCP необходимых параметров, клиент должен быть готов к обмену пакетами с любой другой ЭВМ в Интернет. Не все эти параметры необходимы для первичной инициализации клиента. Клиент и сервер могут согласовывать список необходимых параметров.

Протокол DHCP позволяет, но не требует конфигурации параметров клиента, не имеющих прямого отношения к IP-протоколу. DHCP не обращается к системе DNS для регистрации адреса [6.12, 6.13]. DHCP не может использоваться для конфигурации маршрутизаторов. При описании протокола применены следующие определения.

DHCP клиент Клиент DHCP является ЭВМ, подключенной к Интернет, которая использует DHCP, чтобы получить конфигурационные параметры, например, сетевой адрес
DHCP сервер Сервер DHCP является ЭВМ, подключенная к Интернет и присылающая клиенту DHCP параметры конфигурации
Агент пересылки BOOTP Агент пересылки BOOTP представляет собой ЭВМ, подключенную к Интернет, или маршрутизатор, который осуществляет связь между клиентом и сервером. DHCP спроектирован так, чтобы обеспечить совместимость со спецификациями протокола BOOTP
Binding Сопряжение (binding) представляет собой совокупность конфигурационных параметров, включая, как минимум, IP-адрес, присваиваемый DHCP-клиенту. Сопряжением управляют DHCP-серверы

Ниже приводится список основных задач DHCP.

  • DHCP представляет собой механизм, а не политику. DHCP должен управляться местными системными администраторами, путем задания желательных конфигурационных параметров
  • Клиенты не должны требовать ручной конфигурации. Каждый клиент должен быть способен прочесть локальные конфигурационные параметры
  • Сети не должны требовать ручной конфигурации для отдельных клиентов. В нормальных условиях сетевой администратор не должен вводить каких­-либо индивидуальных конфигурационных параметров клиента
  • Клиент DHCP должен быть готов получить несколько откликов на запрос конфигурационных параметров. Для повышения надежности и быстродействия можно использовать несколько DHCPсерверов, обслуживающих перекрывающиеся области сети
  • DHCP должен сосуществовать с ЭВМ, которые сконфигурированы вручную
  • DHCP должен быть совместим с логикой работы BOOTP-агента, описанной в RFC-951 и RFC-1542 [6.16]
  • DHCP должен обслуживать существующих клиентов BOOTP

DHCP должен также:

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

С точки зрения клиента, DHCP является расширением механизма BOOTP. Такая схема позволяет существующим BOOTP-клиентам успешно сотрудничать с DHCP-серверами без необходимости изменения стартовой программы клиента. В RFC-1542 [6. 2] детализировано взаимодействие между BOOTP и DHCPклиентами и серверами [6.8]. Имеется несколько новых, опционных операций, которые оптимизируют взаимодействие между DHCPклиентами и серверами.

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

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


Рис. 6.1. Формат сообщения DHCP

DHCP вводит небольшое изменение в терминологию, имеющее целью прояснить значение одного из полей. Поле vendor extensions в BOOTP переименовано в поле опции в DHCP. Аналогично, помеченные информационные элементы, использованные в поле BOOTP vendor extensions, которые именовались как расширения производителя, теперь называются просто опции.

DHCP определяет новую опцию client identifier, которая используется для прямой передачи идентификатора клиента DHCP серверу. Это изменение исключает перегрузку поля chaddr в сообщениях BOOTP, где chaddr используется как в качестве аппаратного адреса для пересылки сообщений откликов BOOTP, так и в качестве идентификатора клиента. Идентификатор клиента представляет собой непрозрачный ключ, который не должен интерпретироваться сервером; например, идентификатор клиента может содержать аппаратный адрес, идентичный тому, который лежит в поле chaddr, или он может содержать другой идентификатор типа, такой, как DNS-имя. Идентификатор клиента, выбранный DHCP клиентом, должен быть уникальным для субсети, к которой он подключен. Если клиент использует идентификатор клиента в одном сообщении, он должен использовать тот же идентификатор во всех последующих сообщениях, чтобы гарантировать корректную идентификацию клиента всеми серверами. DHCP определяет поле siaddr как адрес сервера для применения во время следующего шага процесса начальной загрузки клиента. DHCP-сервер может прислать свой собственный адрес в поле siaddr, если сервер готов обеспечить последующую загрузку (например, доставку образа операционной системы). DHCP-сервер всегда присылает свой адрес в опции server identifier. Назначения полей заголовка представлены в таблице 6.1.

Таблица 6.1. Описание полей сообщения DHCP
поле байт описание
op 1 Код операции сообщения / тип сообщения
1 1= BOOTREQUEST, 2 = BOOTREPLY
htype 1 Тип аппаратного адреса, смотри раздел ARP в RFC «Assigned Numbers»; например, ‘1’ для Ethernet
Hlen 1 Длина аппаратного адреса (например, ‘6’ для Ethernet)
Шаги 1 Клиент устанавливает это поле равным нулю, поле используется опционно агентами транспортировки, когда загрузка осуществляется через посредника
Xid 4 ID-транзакции, случайное число, выбираемое клиентом и используемое как клиентом, так и сервером для установления соответствия между запросами и откликами
Secs 2 Заполняется клиентом, число секунд с момента начала запроса адреса или рестарта процесса
Флаги 2 Флаги (смотри рис. 6.1)
Ciaddr 4 IP-адрес клиента заполняется только в случае, если клиент находится в состоянии BOUND, RENEW или REBINDING и может реагировать на запросы ARP
Yiadd 4 IP-адрес следующего сервера, используемого в процессе загрузки; присылается сервером в DHCPOFFER, DHCPACK
Giaddr 4 IP-адрес агента транспортировки, используется, когда загрузка осуществляется через посредника
Chaddr 16 Аппаратный адрес клиента
Sname 64 Опционное имя ЭВМ-сервера, строка завершается нулем
Файл 128 Имя файла загрузки (Boot-файла), строка завершается нулем; имя generic или нуль в DHCPDISCOVER, полное описание прохода в DHCPOFFER
Опции var Поле опционных параметров

Поле опции имеет переменную длину. Клиент DHCP должен быть готов получать DHCP-сообщения с полем опции длиной, по крайней мере, 312 октетов. Это требование подразумевает, что DHCPклиент должен быть готов получать сообщения длиной до 576 октетов. DHCP-клиенты могут согласовать применение более длинных DHCP-сообщений с помощью опции maximum DHCP message size. Поле options может быть еще расширено в полях файл и sname.

В случае, когда клиент использует DHCP для начальной конфигурации (прежде чем программа клиента полностью сконфигурирована), DHCP требует использования клиентского программного обеспечения в вольной интерпретации RFC-1122. Программа должна принять и передать IP-уровню любой IP-пакет, доставленный по аппаратному адресу клиента, до того как IP-адрес будет сконфигурирован; DHCP-серверы и агенты транспортировки BOOTP могут быть неспособны доставить DHCP-сообщения клиентам, которые не могут принимать уникастные дейтограммы, до того, как программа TCP/IP сконфигурирована должным образом.

Чтобы работать с клиентами, которые не могут воспринимать уникастные IP-дейтограммы до того, как будет сконфигурирована программа, DHCP использует поле флаги [6.15]. Самый левый бит определен как флаг BROADCAST (B). Остающиеся биты поля флаги зарезервированы на будущее. Они должны быть установлены равными нулю клиентами и игнорироваться серверами и агентами транспортировки. На рис. 6.2 показан формат поля флаги.


Рис. 6.2. Формат поля флаги
B: флаг BROADCAST
       MBZ: должно быть равно нулю 
(must be zero; зарезервировано на будущее)

[Конспект админа] Как подружиться с DHCP и не бояться APIPA / Блог компании Сервер Молл / Хабр

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

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

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

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


В принципе, специально для функционирования небольших сетей был создан стек технологий под названием 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.


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

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

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

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

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


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

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

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


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

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


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

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


В этом разделе я рассмотрю практическое применение опций 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 под спойлером.


Настройка 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

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


Настройка 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

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

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


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

Предположим, нам нужно добавить клиентам маршрут вида dst-address=10.0.0.0/24 gateway=192.168.88.2, а основным шлюзом будет 192.168.88.1. Приведем это все в HEX:


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

/ip dhcp-server option

add code=121 name=classless value=0x0A0000c0a8580200c0a85801

Подробнее можно прочитать в статье «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 производится в настройках бриджа:

#Включаем 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.

Помимо защиты от злых хакеров эта функция избавит от головной боли, когда в сети появляется другой 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?

Основы компьютерных сетей. Тема №2. Протоколы верхнего уровня / Habr

И снова всем привет! Сегодня речь пойдет о протоколах верхнего уровня. Разберем, как они работают, из чего состоят и где применяются теоретически и на практике.




Как вы помните из прошлой статьи (если не читали, то в содержании есть ссылка на нее), модель OSI в нынешнее время служит только в качестве обучения ролям каждого уровня. Работают же сети по стеку протоколов TCP/IP. Хоть TCP/IP состоит из 4 уровней, он вполне реализует все функциональные возможности, реализуемые в модели OSI. Ниже на картинке приведены сравнения уровней и их ролей.
Начинаем разговор про протоколы верхнего уровня. Я не просто так назвал тему «Протоколы верхнего уровня», а не «Протоколы верхних уровней». Так как разбираем мы этот уровень по стеку TCP/IP, то у нас он «один за трех».

Вообще с точки зрения сетевика, нам все равно, что происходит внутри прикладного уровня. Этим, как правило, занимаются программисты. Но важно знать, как формируются данные и инкапсулируются в нижестоящие уровни.
У нас на работе, например, есть правило: мы обеспечиваем запуск приложения и его безошибочную передачу по сети. Если проблема заключается во внутренних программных сбоях, то мы переключаем на разработчиков, и это становится их заботой. Но бывают и проблемы, которые идут по тонкой грани между нами, и мы решаем их вместе.

Итак, протоколы прикладного уровня обеспечивают взаимодействие между человеком и сетью. Этих протоколов огромное количество, и выполняют они совершенно различные роли. Я приведу примеры часто используемых протоколов в сети и покажу, как они работают на практике: HTTP, DNS, DHCP, SMTP и POP3, Telnet, SSH, FTP, TFTP.

I) Протокол HTTP (англ. HyperText Transport Protocol). Протокол передачи данных, используемый обычно для получения информации с веб-сайтов. С каждым годом этот протокол становится все популярнее, и возможностей для его применения становится все больше. Использует он «клиент-серверную» модель. То есть существуют клиенты, которые формируют и отправляют запрос. И серверы, которые слушают запросы и, соответственно, на них отвечают.

В качестве клиентов выступают известные многим веб-браузеры: Internet Explorer, Mozilla Firefox, Google Chrome и т.д. А в качестве серверного ПО используют:Apache, IIS, nginx и т.д.

Для того, чтобы разобраться глубже в протоколе HTTP, взглянем на HTTP запрос от клиента к серверу.


Нас интересуют только самая верхняя и самая нижняя строчки.

В первой строчке используется такое понятие, как GET. Это, по сути, ключ запроса. Так как после GET стоит символ «/», то это означает, что запрашивается главная или корневая страница по URL (англ. Uniform Resource Locator) пути.

URL — это некий идентификатор какого-либо ресурса в сети.

Так же в этой строчке присутствует такая запись, как HTTP/1.1. Это версия протокола. Довольно популярная версия. Выпустили ее в 1999 году, и до сих пор она служит верой и правдой. Хоть недавно был анонс версии 2.0, версия 1.1 занимает пока лидирующее положение.

Теперь о нижней строчке. Здесь указывается адрес сервера или имя, на котором располагается нужный ресурс. Давайте посмотрим, как это работает на практике. Я буду использовать свою любимую программу Cisco Packet Tracer 6.2 (в дальнейшем CPT). Она проста в освоении и для демонстрации описанного идеально подходит. Могу сказать с уверенностью, что для подготовки к CCNA R&S, ее хватает вполне. Но только для нее.

Открываем программу и добавим туда компьютер с сервером (находятся они на вкладке «End Devices»), как на картинке ниже


Соединяем компьютер с сервером перекрестным кабелем (англ. crossover cable). В CPT он находится на вкладке «Connections», обозначается пунктиром и называется «Copper Cross-Over».

Теперь займемся настройкой компьютера и веб-сервера.


1) Отрываем вкладки «Desktop» на рабочем компьютере и сервере, далее переходим в окно «IP Configuration». Откроются окна, как на рисунке выше. Это окна конфигурации узлов в сети.

2) Укажем IP-адреса в строки, указанные цифрой 2. Как помним из предыдущей статьи, IP-адреса нужны для идентификации узлов в сети. Подробнее мы разберем эту тему позже. Сейчас главное понимать, для чего нужен IP-адрес. Я специально выбрал сеть, начинающуюся с «192.168», так как она встречается чаще всего в домашних сетях.

3) В поля, указанные цифрой 3, вводится маска подсети. Она нужна для того, чтобы узлу было понятно, в одной подсети он находится с другим узлом или нет. Но об этом позже.
Остальные значения оставим пустыми.

Теперь требуется включить сервис HTTP на сервере.


1) Переходим на вкладку «Services».
2) Выбираем слева сервис HTTP.
3) Открывается окно настройки сервиса и файловый менеджер. Если у кого есть навыки по работе c HTML, то можете здесь создать страницу. Но у нас уже есть готовый шаблон, и мы им воспользуемся. Не забываем включить службу HTTP и HTTPS.

Раз уже зашла речь о HTTPS (HyperText Transfer Protocol Secure), то скажу про него пару слов. Это, по сути, расширение протокола HTTP, которое поддерживает криптографические протоколы и передает информацию не в открытом виде, а в зашифрованном. В CPT очень поверхностно показана его работа, но для понимания вполне достаточно. Вспоминаем и запоминаем: HTTP использует 80 порт, а HTTPS 443 порт. Вообще номеров портов очень много, и все запомнить тяжело, но часто встречающиеся лучше запомнить.

Теперь самое интересное. Нам надо перевести CPT из режима «Realtime» в режим «Simulation». Отличие их в том, что в режиме «Realtime» сеть ведет себя так, как она повела бы себя в реальной жизни и в реальном времени. Режим «Simulation» позволяет нам наблюдать за поведением сети в разные временные интервалы, а также проследить за каждым пакетом, раскрыть его и посмотреть, что он в себе несет. Переключаем среду, как показано на рисунке ниже.


Здесь открывается «Simulation Panel», в которой несколько опций. Есть фильтр, в котором можно указать протоколы, которые вы хотите отслеживать, скорость перемещения пакета и навигационная панель, где можно наблюдать за сетью вручную, нажатием «Capture/Forward» или автоматически, при помощи кнопки «Auto Capture/Play».

Оставляем все, как есть, и открываем компьютер.


Переходим на вкладку «Desktop» и открываем «WEB Browser». Перед нами открывается окно веб-браузера. В строке URL пишем адрес нашего веб-сервера, нажимаем кнопку «Go» и наблюдаем следующую картину.
Появились первые посылаемые данные на схеме и в окне «Simulation Panel». Это сегменты TCP, которые создадут сессию между компьютером и сервером. Сейчас нам это не интересно, и мы об этом поговорим в следующей статье. Поэтому я пропущу их до момента, когда будут созданы HTTP. Делать я это буду при помощи кнопки «Capture/Forward».
И вот после установления соединения, компьютер формирует первые HTTP данные. В дальнейшем я буду называть их PDU, чтобы вы привыкали к данным терминам.

1) Смотрим на схему и видим, что появилось 2 конверта. Это и есть наши данные. Нас интересует фиолетовый конверт. Это и есть созданный PDU.

2) Теперь смотрим на «Simulation Panel» и видим, что в таблице появилась запись с типом HTTP. Эти данные нас интересуют. Также рядом с записью показан цвет, которым окрашены эти данные на схеме.

3) Кликаем по HTTP (фиолетовый конверт), и перед нами открывается окно данных. Тут кратко показаны все нужные сведения по каждому уровню модели OSI. Можно кликнуть по любому уровню и получить информацию о том, что происходит на нем.

Если вам интересно полностью раскрыть данные и рассмотреть подробно, из каких полей они состоят и что в них происходит, есть вкладка «Outbound PDU Details». Давайте перейдем на нее и посмотрим, как выглядят HTTP данные.


На этой вкладке будут выводиться данные на всех уровнях. Нам пока надо посмотреть на HTTP. Они находятся в самом низу, поэтому тянем бегунок вниз. Выглядят они так же, как я и описывал их раньше.

Теперь нам интересен этап, когда веб-сервер получит запрос и начнет предпринимать какие-то действия. Давайте нажмем на «Capture/Forward» и посмотрим, чем веб-сервер ответит. И вот, на рисунке ниже видим, что он отправил компьютеру какие-то данные. Давайте посмотрим, как они выглядят.


1) Я случайно пережал кнопку и он уже начал формировать TCP на закрытие сессии. Ничего страшного. Находим PDU, адресованные от веб-сервера к клиенту. Как видим, он сразу показывает нам на схеме момент времени, в который я кликнул. Выбираем нужный конверт.

2) Здесь уже видим другую картину. Сверху указывается версия HTTP, код «200 OK», означающий, что отправляется запрашиваемая страница, а не сообщение об ошибке. Далее указывается длина контента, тип файла, а также с какого сервера отправляется. И в самой нижней строке указывается, что передаются какие-то данные. После того, как данные дойдут до компьютера, можно наблюдать, что веб-браузер компьютера открыл страницу.


Вот так работает протокол HTTP. Давайте рассмотрим его расширенную версию HTTPS. Как мы помним, эта версия поддерживает шифрование и не передает данные в открытом виде. В самом начале, мы включили сервис HTTP и HTTPS. Поэтому все готово, и можно запрашивать страницу. Отличие запроса в том, что перед адресом страницы вместо HTTP, пишем HTTPS.
Видим надпись, что данные защищены, и мы их прочитать не можем. В принципе это все отличия, которые может показать CPT, но для базового понимания этого достаточно. От себя добавлю, что когда вы переходите на сайт, работающем по HTTPS, в браузере он обозначается в виде замка. Например

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

Мы поговорили про HTTP, и теперь время разобрать протокол DNS. Данный протокол тесно связан с предыдущим протоколом, и скоро вы поймете почему.

II) DNS (Domain Name System). Система доменных имен. Если говорить в целом, то она хранит информацию о доменах. Например, какому IP адресу соответствует определенное имя. Приведу пример: когда вы открываете свой любимый сайт, то обращаетесь к нему по имени. Но в поля Source Address и Destination Address, которые работают на сетевом уровне (это тема следующей статьи, но я немного забегу вперед), нельзя вставить имя. Там обязательно должен присутствовать именно IP адрес. Вот DNS как раз этим и занимается. Она сообщает, какой IP адрес у запрошенного имени. Вы, к примеру, обращаетесь на google.ru. Ваш компьютер понятия не имеет, кто и что это. Он спрашивает у DNS-сервера: Кто такой google.ru? И сервер отвечает, что google.ru — это 74.125.232.239 (это один из его адресов). И уже после этого, компьютер отправляет запрос на 74.125.232.239. Для пользователя все останется по-прежнему, и в адресной строке он также будет видеть google.ru.

Как обычно, покажу это на картинке


Думаю, что выше описанное понятно, и двигаемся дальше. Служба эта иерархичная. И часто DNS-сервер (на котором запущена эта служба) работает в связке с другими DNS-серверами. Давайте разберем, что это значит. Иерархичность его заключается в том, что он работает с доменами уровня. Работает он от младшего уровня к старшему, слева направо.

Например имя: ru.wikipedia.org. Cамым старшим будет доменное имя «org», а младшим — «ru». Но часто бывают случаи, когда DNS-сервер не может нам рассказать о каком-то доменном имени, и тогда он обращается к старшему DNS-серверу, который отвечает за доменные имена более высокого уровня. Не буду изобретать велосипед и приведу картинку из википедии. Там эта работа проиллюстрирована хорошо.


Предположим, мы набрали в браузере адрес ru.wikipedia.org. Браузер спрашивает у сервера DNS: «какой IP-адрес у ru.wikipedia.org»? Однако сервер DNS может ничего не знать не только о запрошенном имени, но даже обо всём домене wikipedia.org. В этом случае сервер обращается к корневому серверу — например, 198.41.0.4. Этот сервер сообщает — «У меня нет информации о данном адресе, но я знаю, что 204.74.112.1 является ответственным за зону org.» Тогда сервер DNS направляет свой запрос к 204.74.112.1, но тот отвечает «У меня нет информации о данном сервере, но я знаю, что 207.142.131.234 является ответственным за зону wikipedia.org.» Наконец, тот же запрос отправляется к третьему DNS-серверу и получает ответ — IP-адрес, который и передаётся клиенту — браузеру.

Открываю CPT и показываю, как это работает. Эта и следующие лабораторные работы буду основываться на предыдущей. Поэтому адресация будет такой же.


Здесь добавлен еще один сервер, который будет выполнять роль DNS-сервера и коммутатор. Когда в сети появляются 3 и более устройств, то для их соединения используют коммутатор.

Займемся настройкой DNS-сервера. Зайдем в «IP Configuration» и пропишем IP адрес с маской.

Теперь зайдем в сервисы и настроим DNS службу.


1) В окне «Name» запишем имя, которое хотим привязать к IP адресу. (я написал имя своего будущего сайта, над которым идет работа).
2) В окне «Address», соответственно, IP-адрес, который будет работать в связке с выше написанным именем. (здесь укажем тот же адрес, что и в лабораторной по HTTP — 192.168.1.2).
3) Нажимаем кнопку «Add», чтобы добавить эту запись.
4) Не забываем включить саму службу!

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


Теперь надо в настройках сервера и компьютера указать адрес DNS-сервера.
Настройка DNS-сервера и узлов закончена, и самое время проверить, как это дело работает. Переключаем среду в режим симуляции и попробуем с компьютера зайти на сайт по имени «cisadmin.ru».
И видим, что создаются 2 конверта. Первый — это DNS, а второй — ARP. О ARP мы толком не говорили, так как это тема следующей статьи. Но раз он показал себя, то вкратце расскажу, для чего он. Как мы помним, для обмена между узлами недостаточно IP адреса, так как еще используются MAC-адреса, работающие на канальном уровне. Мы указали компьютеру IP адрес DNS-сервера. Но он не знает, какой у узла с IP-адресом 192.168.1.3 MAC-адрес. Он формирует ARP сообщение и выбрасывает его в сеть. Данный кадр (данные на канальном уровне называются — кадры) является широковещательным, то есть его получат все участники, находящиеся в одной локальной сети (правильно сказать все участники в одном широковещательном домене, но пока мы это не затрагивали, и я не буду грузить вас этим термином). И тот, у кого этот адрес, отправит обратное сообщение и сообщит свой MAC-адрес. Все остальные участники отбросят этот кадр. Смотрим рисунки.
Вот кадр пришел на коммутатор, и теперь его задача разослать этот кадр на все порты, кроме того, откуда он пришел.
Кадры были разосланы и наблюдаем следующее. Кадр, который пришел на веб-сервер был отброшен, о чем говорит перечеркнутый конверт. Следовательно, кадр отбрасывается. А DNS-сервер, наоборот, узнал свой адрес и должен сформировать ответ.
И как видим, был создан ARP-ответ. Давайте немного разберем его.

1) MAC-адреса. В Source MAC он записывает свой MAC-адрес, а в Destination MAC (Target MAC) адрес компьютера.
2) В Source IP свой IP адрес, а в Target IP адрес ПК.

Я думаю, здесь все понятно. Если непонятно, то спрашивайте. В следующей статье я более подробно о нем расскажу.

Я нажимаю на «Capture/Forward» и смотрю, что будет дальше происходить.


И вижу, что компьютер успешно получил ARP от сервера. Теперь он знает MAC-адрес DNS-сервера, а значит, и как с ним связаться. И сразу решает узнать у него, кто такой «cisadmin.ru». Мы можем открыть эти данные и посмотреть, что он там решил отправить. Открываем «Outbound PDU Details» и спускаемся в самый низ. Видим, что в верхнем поле «NAME» он записал запрашиваемое имя. Жмем кнопку «Capture/Forward» и cмотрим.
DNS-сервер получает DNS-запрос. Он лезет в свою таблицу и видит, что такая запись у него присутствует, и формирует ответ. Открываем и видим, что изменилось поле LENGTH и равняется 4. То есть 4 байта. Столько занимает IP адрес. И, соответственно, записывает сам IP-адрес — 192.168.1.2. Это и есть адрес веб-сервера. Двигаюсь дальше.
Видим, что компьютер получил сообщение от DNS-сервера, о чем свидетельствует галочка на коричневом конверте. И теперь он знает IP адрес веб-сервера. Сразу же он пытается установить TCP сессию, но возникает проблема. Он не знает MAC-адрес веб-сервера и запускает аналогичный ARP запрос, чтобы узнать. Смотрим.
И тут аналогично предыдущему. DNS-сервер понял, что сообщение не для него, и отбрасывает. А веб-сервер узнает свой IP адрес и формирует ARP ответ.
Дошел до компьютера ARP ответ. Теперь он знает MAC-адрес веб-сервера и пытается установить TCP сессию. Отправляет он TCP сегмент на 80-й порт. Раз уж протокол TCP снова дал о себе знать, и в следующих протоколах он тоже будет фигурировать, то вкратце объясню зачем он нужен. Как вы помните из первой статьи, я говорил, что он устанавливает соединение. Так вот теперь каждый блок данных, который будет отправлен от сервера компьютеру, будет промаркирован. Это нужно для того, чтобы клиент понимал, все ли данные он получил или какие-то потерялись. И, если какие-то данные потерялись, он сможет запросить их повторно. Потеря блока данных сайта может привести к тому, что сайт перекосит, и он отобразится криво. Но сейчас главное понимать, что TCP располагается на транспортном уровне и работает с портами. Я специально открыл окно, где это написано, чтобы вы постепенно привыкали к этим полям.

Посмотрим, чем ответит компьютеру веб-сервер.


Веб-сервер отправляет компьютеру ответное сообщение, и устанавливается сессия. И, когда все готово, компьютер формирует HTTP и отсылает его веб-серверу. Давайте посмотрим, что изменилось. А изменилась у нас самая последняя строчка. Если раньше там был записан IP адрес веб-сервера, то теперь там красуется доменное имя «cisadmin.ru». Но не забывайте, что доменное имя тут записано только в данных прикладного уровня. IP-адрес никуда не делся. Он располагается на сетевом уровне. Поэтому давайте сразу покажу IP пакет, где представлены эти адреса.
И как видите, IP адреса на месте.

Далее процесс аналогичен лабораторной по HTTP. Поэтому приведу финальный этап, где по имени «cisadmin.ru» откроется страница, находящаяся на сервере с IP адресом 192.168.1.2.

Соответственно видим, что все прекрасно работает, и сайт открывается по доменному имени.
И напоследок упомяну об одной очень важной утилите под названием nslookup. Она позволяет обратиться к DNS-серверу и узнать у него информацию о имени или IP-адресе. В CPT эта команда присутствует, и я предлагаю взглянуть на нее.

Кликаем по компьютеру на схеме и на вкладке «Desktop» выбираем «Command Prompt». Это имитация командной строки.


Открывается у нас окошко, подобное cmd в ОС Windows. Можно ввести знак «?» и нажать ENTER. Она покажет список всех доступных команд. Нам нужна команда nslookup. Введем ее и нажмем ENTER.
Открывается сама утилита, о чем свидетельствует знак птички слева. Показывается нам адрес DNS-сервера и его имя. Так как имени нету, то он дублирует туда строку с IP-адресом.

Ну и самое время вписать туда доменное имя и узнать, что он выдаст в ответ.


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

Есть еще один файл в каждой ОС, который тесно связан с DNS. Название у него «hosts». Стандартное расположение его в Windows системах «windows\system32\drivers\etc\hosts». А в *nix подобных системах: «/etc/hosts». Делает он то же самое, что и DNS-сервера. И контролируется этот файл администратором компьютера. И самое важное: он имеет приоритет перед DNS-сервером. И, если у вас в файле написано, что сайту habrahabr.ru соответствует IP адрес, который на самом деле соответствует google.ru, то, соответственно, открывать он будет google, а не habrahabr. Этим часто пользуются злоумышленники, когда вносят исправления в этот файл. Приведу скрин этого файла со своего компьютера.


Вот так он выглядит. Можете открыть его у себя и поймете, что он точно такой же.

Вот такая интересная служба и протокол. Также как и с HTTP, приведу ссылку на скачивание данной лабы.

А мы двигаемся дальше и разбираем протокол DHCP.

III) DHCP (Dynamic Host Configuration Protocol). Протокол динамической настройки узла. Он позволяет узлам динамически получать IP адреса и другие параметры для корректной работы в сети (основной шлюз, маску подсети, адреса DNS-серверов). От себя скажу, что этот протокол спасает жизнь многим сисадминам по всему миру. Согласитесь, что ходить и вручную прописывать IP параметры каждому узлу, не самое приятное занятие.

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

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

Давайте посмотрим, как он работает на практике.


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

Настроим сервер.


Присваиваем свободный адрес и маску. Перейдем к роли DHCP.
1) Выбираем службу DHCP, и тут уже создан стандартный пул. Его удалить нельзя. Только изменить. Можете сами создать несколько пулов и вытворять с ними, что угодно, вплоть до удаления. Но стандартный всегда останется. Нам дополнительные пулы не нужны, поэтому переделаем под себя стандартный.

2) Здесь можно добавить адрес шлюза, адрес DNS-сервера. Мы пока не касались вопроса шлюза, поэтому пока не будем его трогать. DNS-сервер у нас есть, и его можно указать. Ну и старт адресов оставим, как есть.

3) Не забываем включить сервер!

Переключаем среду в режим симуляции и посмотрим, как компьютер получит адрес.


Соответственно переходим в настройки конфигурации и переключаем на DHCP.
Видим, что создался DHCP-запрос. Давайте пройдемся по каждому его уровню и поверхностно посмотрим, что внутри.

1) Протокол канального уровня (Ethernet). В «Source MAC» записывается адрес компьютера. А в «Destination MAC» записан широковещательный адрес (то есть всем).

2) Протокол сетевого уровня (IP). В «Source IP» записывается адрес «0.0.0.0». Этот адрес вставляется, когда у запрашиваемого нет адреса. А в «Destination IP» вставляется широковещательный адрес «255.255.255.255».

Смотрим дальше.


Посмотрим на поле UDP. Здесь используются порты 67 и 68. Это UDP порты, зарезервированные для DHCP.
Теперь смотрим на поле DHCP. Здесь все по нулям, и только в поле «CLIENT HARDWARE ADDRESS» записан MAC-адрес компьютера.

Мы знаем, как работает широковещательная рассылка, и посмотрим, как будут реагировать на нее участники сети.


И видим, что все кроме DHCP-сервера отбросили данные.

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

Мы пока не говорили и об этом. Поэтому заранее скажу, что утилита ping позволяет проверить доступность узла по IP-адресу. И, если на ping DHCP-серверу кто-то ответит, то значит адрес занят и всю процедуру он будет повторять, но с другим IP-адресом. Но это тоже не самое толковое решение. Сами понимаете, что если компьютер со статически назначенным адресом будет выключен, то он не ответит на ping DHCP-сервера, и, соответственно, DHCP решит, что адрес не занят и присвоит его какому-то узлу. Но, как только компьютер включится, появится 2 компьютера с одинаковыми IP-адресами. И тут могут начаться дикие чудеса. Современные системы уже научились правильно реагировать на это, но все же не стоит этого допускать и важно следить за этим. Я пропущу в CPT все эти данные, иначе получится диафильм из однообразных картинок. Я прикреплю эту лабу ниже, и вы сможете сами в этом убедиться. Приведу только конечный итог, который сформирует DHCP-сервер.


И видим, что в поле ««YOUR» CLIENT ADDRESS» добавился адрес 192.168.1.1. Это адрес, который DHCP-сервер предлагает компьютеру. В поле «SERVER ADDRESS» DHCP-сервер добавляет свой адрес, чтобы компьютер знал, кто предлагает ему адрес. В поле «CLIENT HARDWARE ADDRESS» добавляется MAC-адрес компьютера (то есть того, кто запросил). И в самом низу представлена опция «DHCP Domain Name Server Option». Сюда записывается адрес DNS-сервера, который мы указали в настройках сервиса DHCP.

Посмотрим, как компьютер получит адрес.


И наблюдаем сообщение «DHCP Request Successful». Что означает, что данные успешно получены, о чем свидетельствуют заполненные поля ниже.

Вот так работает протокол DHCP. Как обещал, ссылка для скачивания.

Переходим дальше, и дошла очередь до протоколов POP3 и SMTP. Я специально упомянул эти протоколы вместе и сейчас объясню, почему.

IV) POP3 (англ. Post Office Protocol Version 3). Протокол почтового отделения версии 3. Протокол, который используют клиенты для получения почтовых писем с сервера. Версии 1-ая и 2-ая устарели и в нынешнее время не используются. Работает он по принципу «загрузи и удали». Что это значит? Это значит, что клиент заходит на сервер и смотрит, есть ли для него письмо. И если оно присутствует, он загружает его к себе и ставит отметку об удалении на сервере. Хорошо это или плохо, вопрос спорный. Кто-то утверждает, что это хорошо, так как сервер не бывает перегружен ненужными письмами. Я считаю иначе. Во-первых современная инфраструктура позволяет хранить большой объем писем, а во-вторых часто случается, что пользователь удаляет или теряет важное письмо, и найти его потом становится трудно. Хотя, стоит упомянуть, что некоторые клиенты можно настроить так, чтобы они не удаляли письма с сервера. Однако при стандартных настройках они удаляют письма с сервера. Поэтому будьте внимательнее. Порт, который он прослушивает — 110. Довольно известный номер порта, поэтому возьмите себе на заметку. Так же как и у протокола HTTP, у него есть расширенная версия — POP3S. При помощи дополнительного криптографического протокола, как SSL, шифруется содержимое, и письма передаются в защищенном виде. POP3S использует 995 порт. Мы обязательно рассмотрим протокол POP3 на практике, после того, как узнаем про протокол SMTP.

Стоит упомянуть про аналог POP3. Это протокол IMAP (англ. Internet Message Access Protocol). Протокол доступа к электронной почте. Он более умный и посложнее, чем POP3. Но главное их различие в том, что клиент, заходя на сервер, не удаляет почту, а копирует ее. Таким образом, у клиента отображается копия почтового ящика, который хранится на почтовом сервере. И если клиент у себя удаляет какое-либо письмо, то оно удаляется только у него. На сервере оригинал остается целым. Слушает он 143 порт. Рассмотреть IMAP подробно в CPT не получится, так как полноценно он там не реализован.

V) SMTP (англ. Simple Mail Transfer Protocol). Простой протокол передачи почты. Используется он, как вы поняли, для передачи почты на почтовый сервер. Вот почему мы изучаем POP3 и SMTP параллельно. Использует он 25 порт. Это тоже важно помнить.

Также важно помнить, что все почтовые протоколы работают по TCP-соединению. То есть с установлением соединения. Здесь важно получить каждый пакет в целости и сохранности.

Думаю, с теоретической точки зрения все понятно. Давайте перейдем к практике и посмотрим, как это работает.

Открою я прошлую лабораторную работу по DHCP и слегка ее модернизирую.


Убрал я HTTP-сервер и вместо него добавил компьютер рабочего, и назвал WORKER-PC. Присвою ему IP-адрес, который был у HTTP-сервера. То есть 192.168.1.2. Старый компьютер переименовал в DIRECTOR-PC. DNS-сервер я оставил. Он нам в этой лабе еще понадобится. Сервер DHCP переименовал в Mail-Server. И давайте его настроим.
Адрес я не менял, и он остался от прошлой лабы. Пускай таким и остается. Переходим в службы и находим «EMAIL».
1) В поле «Domain Name» надо записать имя домена. Это то, что будет писаться после знака «@». Обязательное требование. Любая почта записывается в таком формате — логин@домен. И нажимаем кнопку «Set». Я ее уже нажал, поэтому она не активна, но если внести изменения в поле ввода доменного имени, то она снова станет активной.

2) И создадим пользователей. В поле «User» запишем первого пользователя. Это будет «Director». И зададим пароль «123». И нажимаем на знак «+», чтобы добавить его в базу. Аналогично создадим второго пользователя. Это будет «Worker» с таким же паролем «123».

Создание пользователей закончено, и наблюдаем следующую картину.


1) Видим в базе список созданных пользователей. Их можно удалять, добавлять и менять пароли при помощи кнопок справа.
2) Не забываем включить службы POP3 и SMTP. Они по умолчанию включены, но проверка лишней не будет.

На этом настройка на стороне сервера заканчивается, и теперь перейдем к настройке на стороне клиентов. Начнем с компьютера директора. Открываем вкладку «Desktop» и выбираем Email.


После этого сразу откроется окно настройки.
1) В поле «Your Name» пишем любое имя. Я напишу Director.
2) В поле «Email Address» пишем почтовый ящик. Для директора — это [email protected]
3) В поля «Incoming Mail Server» и «Outgoing Mail Server» записываем адрес почтового сервера (192.168.1.4)
4) В поле «User Name» пишем сам логин. То есть Director и соответственно пароль 123.
Нажимаем кнопку «Save», и перед нами открывается почтовый клиент. CPT назвал его почтовым обозревателем.

Аналогичная настройка будет на компьютере рабочего. Привожу скрин.

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

Открываем почтовый клиент на компьютере директора и создадим письмо.


Жмем на кнопу «Compose», и перед нами открывается привычное окно.
Здесь все как обычно. Пишем кому отправляем, тему письма, сам текст письма и нажимаем кнопку «Send».
Видим следующее сообщение о том, что отправка завершена успешно. Замечательно! Теперь посмотрим, как письмо будет доставлено рабочему.

Открываем почтовый клиент на компьютере рабочего.


И видим, что письма нету. А все потому, что клиент в CPT не поддерживает автоматическое обновление и приходится это делать вручную. Нажимаем кнопку «Receive».
Видим появившееся письмо и сообщение об успешном получении. Откроем письмо и посмотрим, не побилось ли.
И да, письмо, действительно, дошло целым и невредимым. Ответим на это письмо и заодно проверим, что письма ходят в обе стороны. Нажимаю я кнопку «Reply» и пишу ответ.
Отправляю письмо и перехожу к компьютеру директора. И, соответственно, жму кнопку «Receive», чтобы обновить почту.
Появилось письмо, а ниже и сообщение об успешном получении.

Открываем письмо, чтобы до конца удостовериться.


Письмо дошло, а значит все работает.

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


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

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


1) Появился долгожданный SMTP, о чем свидетельствует запись в панели симуляции, и откроем их. Обратим внимания на TCP-порты, чтобы удостовериться, что это он. И видим, что в «Destination Port» стоит 25 номер. А в «Source Port» записан динамически придуманный порт, чтобы сервер мог идентифицировать клиента. Все правильно.

2) Смотрим ниже на данные SMTP, и здесь нет ничего интересного. CPT показывает нам его, как обычный блок данных.

Дальше он передает эти данные серверу. Посмотрим, что будет происходить дальше.


Сервер, получив данные от компьютера, формирует ответное сообщение. Обратите внимание на изменения. Номера, которые присутствовали ранее, поменялись местами, а именно «Source Port» и «Destination Port». Теперь источником является сервер, а назначением — компьютер. Это сообщение о доставке письма серверу.

После этого работа протокола SMTP закончена, и компьютер может начать закрывать TCP-сессию. Чем он и займется.

Теперь когда письмо отправлено, и мы знаем, что оно лежит на сервере, попробуем получить это письмо. Открываем компьютер рабочего и жмем кнопку «Receive».


Как и с SMTP, в POP3 тоже создается TCP-сессия. Посмотрим на номера портов. В «Destination Port» стоит 110 номер порта. Это и есть стандартный номер порта для протокола POP3. В «Source Port» стоит порт 1028.

Смотрим дальше и ждем выхода POP3.


Вот он появился и наблюдаем, что в поле POP3 такая же картина, что и в SMTP, т.е. все то, что и так было понятно.

Дальше он отправляет этот запрос на сервер, и сервер должен ответить письмом, если оно там есть.


Мы знаем, что оно там есть и наблюдаем, как сервер формирует ответное сообщение. И также как с SMTP, он меняет местами порты отправления и назначения. На прикладном уровне запакованы какие-то POP3 данные. Это и есть само письмо.

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


И как только данные получены, о чем здесь свидетельствует галочка на фиолетовом пакете, письмо сразу же высвечивается в клиенте. Дальше, как и в SMTP, будет закрытие TCP-сессии.

Привожу ссылку на скачивание этой лабы.

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

Ну и самое логичное, что приходит в голову — это то, что у нас есть почтовый сервер с адресом 192.168.1.4. И с этим адресом у нас будет работать доменное имя. Соответственно заходим на DNS-сервер и сопоставим этому адресу имя.

Настройка на стороне DNS-сервера закончена, и осталось изменить 2 строчки в почтовых клиентах компьютеров. Открываем клиент на компьютере директора.


И нажимаем на кнопку «Configure Mail».

Открывается окно, которое мы видели на этапе начальной конфигурации клиента.


Здесь надо поменять строки «Incoming Mail Server» и «Outgoing Mail Server». Вместо IP-адреса записываем доменное имя и нажимаем кнопку «Save».

То же самое проделываем и на компьютере рабочего. Не буду давать лишних подробностей, просто приведу скрин.

Сразу попробуем написать письмо директору и отправить.


И после нажатия кнопки «Send», наблюдаем следующее.
Внизу появляется сообщение о том, что он спросил у DNS-сервера адрес, и тот ему выдал IP-адрес почтового сервера. Отправка прошла успешно.

Теперь зайдем на компьютер директора и нажмем на кнопку «Receive».


Получаем письмо, а надпись ниже свидетельствует об успешной доставке. Вот еще один пример использования DNS-сервера в сети.

Разобрали мы почтовые протоколы. И переходим к разбору следующего протокола.

VI) Telnet (от англ. terminal network). Если переводить дословно, то это сетевой терминал. Основы этого протокола были заложены давным давно, и до сих пор он не теряет своей актуальности. Применяется он для отображения текстового интерфейса, а также для управления ОС. Очень полезный протокол, и каждый сетевой инженер обязан уметь работать с ним. Объясню почему. Каждое сетевое устройство, интерфейс которого представляет собой командную строку, настраивается либо при помощи специального консольного кабеля, либо через виртуальные терминалы, в который и входит протокол Telnet. И, если консольный кабель требует нахождения специалиста рядом с настраиваемым оборудованием, то настройка при помощи виртуальных терминалов, а в данном случае Telnet, не ограничивает специалиста в расстоянии. Можно находиться в другой комнате, здании, городе и все равно иметь возможность доступа к оборудованию. Я считаю это огромным плюсом. Из минусов данного протокола отмечу, что он фактически не защищенный и все передается в открытом виде. Использует он 23 порт. А самые популярные дистрибутивы, которые работают с этим протоколом — это Putty, Kitty, XShell и т.д. Я думаю закрепим его работу на практике.

Использовать Telnet мы будем для доступа к коммутатору Cisco 2960. Он, как и все Cisco устройства, использует разработанную компанией Cisco операционную систему IOS. А интерфейс командной строки называется CLI (Command Line Interface). Давайте для начала настроим коммутатор. Повесим на него IP-адрес, так как без него мы не сможем попасть на коммутатор и разрешим доступ по Telnet. Я не буду приводить скриншоты, так как там нет графики. Просто дам список вводимых команд и поясню для чего они.

Switch>enable — переход в привилегированный режим. Отсюда доступно большинство команд.

Switch#configure terminal — переход в режим глобальной конфигурации. В этом режиме возможен ввод
команд, позволяющих конфигурировать общие характеристики системы. Из режима глобальной конфигурации можно перейти во множество режимов конфигурации, специфических для
конкретного протокола или функции.

Switch(config)#username admin secret cisco — создаем пользователя с именем admin и паролем cisco.

Switch(config)#interface vlan 1 — переходим в виртуальный интерфейс и повесим на него IP-адрес. Здесь прелесть заключается в том, что не важно, на каком именно из 24-х портов он будет висеть. Нам главное, чтобы просто с какого-либо порта был доступ до него.

Switch(config-if)#ip address 192.168.1.254 255.255.255.0 — присваиваем последний адрес 192.168.1.254 с маской 255.255.255.0

Switch(config-if)#no shutdown — по умолчанию интерфейс выключен, поэтому включаем его. В IOS 90% команд отменяются или выключаются путем приписывания перед командой «no».

Switch(config)#line vty 0 15 — переходим в настройки виртуальных линий, где как раз живет Telnet. От 0 до 15 означает, что применяем это для всех линий. Всего можно установить на нем до 16 одновременных соединений.

Switch(config-line)#transport input all — и разрешаем соединение для всех протоколов. Я специально настроил для всех протоколов, так как чуть позже будет рассматриваться другой протокол и лезть сюда ради одной команды не считаю разумным.

Switch(config-line)#login local — указываем, что учетная запись локальная, и он будет проверять ее с той, что мы создали.

Switch#copy running-config startup-config — обязательно сохраняем конфигурацию. Иначе после перезагрузки коммутатора все сбросится.

Итак коммутатор настроен. Давайте подключимся к нему c рабочего компьютера. Открываем командную строку. Мы ее открывали, когда рассматривали nslookup. И пишем следующее.


То есть команда telnet и адрес, куда подсоединиться.

Если все верно, то открывается следующее окно с запросом логина и пароля.


Соответственно пишем логин:admin и пароль:cisco (мы создавали его на коммутаторе).

И он сразу пускает нас на коммутатор. Для проверки проверим доступность компьютера директора, при помощи команды ping.


Ping успешен. Надеюсь, понятно, что проверка доступности осуществляется не с компьютера рабочего, а с коммутатора. Компьютер здесь является управляющим устройством и все. Рассматривать его в режиме симуляции я не буду. Он работает точно так же, как и почтовые протоколы, то есть создается TCP-сессия, и, после установления соединения, начинает работать Telnet. Как только он отрабатывает, он начинает разрывать соединение. Тут все просто. Привожу ссылку на скачивание.

Давайте теперь разберем протокол SSH.

VII) SSH (англ. Secure Shell). В переводе с английского — безопасная оболочка. Как и Telnet позволяет управлять ОС. Отличие его в том, что он шифрует весь трафик и передаваемые пароли. Шифруется при помощи алгоритма Диффи-Хеллмана. Кому интересно почитайте. Практически все современные ОС системы умеют работать с этим протоколом. Если у вас стоит выбор, какой протокол применять, то используйте SSH. Сначала немного помучаетесь в настройке, и многое будет непонятно, но со временем в голове уляжется. Главное запомните сейчас, что самое главное отличие SSH от Telnet — это то, что SSH шифрует трафик, а Telnet нет. Я думаю пора перейти к практике и посмотреть, как это работает. Подключаться и управлять мы будем тем же коммутатором. Давайте попробуем подключиться по SSH с компьютера директора к коммутатору.


Здесь синтаксис команды немного другой, нежели при подключении по Telnet. Пишем ssh с ключом l, после набираем логин (у нас это admin) и адрес, куда подключаемся (192.168.1.254). Завершаем это дело клавишей ENTER. Выдается сообщение, что соединение было закрыто внешним хостом. То есть коммутатор закрыл соединение. Все потому, что не были созданы ключи, которые работают с шифрованием. Зайду на коммутатор и настрою его для корректной работы по SSH.

Switch(config)#hostname SW1 — меняем имя коммутатора. С этим стандартным именем нельзя прописать домен, который нужен для генерации ключей.

SW1(config)#ip domain-name cisadmin.ru — прописываем домен.

SW1(config)#crypto key generate rsa — генерируем RSA ключи.

The name for the keys will be: SW1.cisadmin.ru
Choose the size of the key modulus in the range of 360 to 2048 for your
General Purpose Keys. Choosing a key modulus greater than 512 may take
a few minutes.

How many bits in the modulus [512]: 1024 — Указываем размер ключа. По умолчанию предлагается 512, но я введу 1024.
% Generating 1024 bit RSA keys, keys will be non-exportable…[OK]
Выходит сообщение о удачной генерации ключей.

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


И уже выдается другое сообщение, с запросом на ввод пароля. Вводим пароль «cisco» и оказываемся на коммутаторе.

Осталось проверить работу. Я воспользуюсь командой ping и проверю доступность рабочего компьютера.


И убедился, что все прекрасно работает. Привожу ссылку, чтобы убедились и вы.

А я перехожу к следующему протоколу.

VIII) FTP (англ. File Transfer Protocol). Протокол передачи файлов. Думаю из названия протокола ясно, что он передает файлы. Очень древний протокол, вышедший в начале 70-х годов. Появился он еще до HTTP и стека TCP/IP. Как работал раньше, так и сейчас работает по «клиент-сервер» модели. То есть, присутствует инициатор соединения и тот, кто его слушает. Есть несколько модификаций, которые поддерживают шифрование, туннелирование и так далее. Раньше с этим протоколом работали разные консольные утилиты, у которых не было графики и работали они, при помощи ввода определенных команд. В нынешнее время присутствуют и графические программы. Самой популярной и простой является Filezilla. В CPT реализован только консольный метод.

Переходим к практике. За основу я возьму предыдущую лабораторку и почтовый сервер заменю FTP-сервером.


В принципе схема аналогична предыдущей.

Откроем FTP-сервер и перейдем в сервис FTP.


По умолчанию служба включена, но лучше проверить.

1) Цифрой 1 я отметил учетку, которая по умолчанию была здесь создана. Это стандартная учетная запись с логином «cisco» и таким же паролем. В правой колонке видим «Permission» — это права доступа. И видим, что данная учетка имеет все права. В тестовой среде нам как раз это и надо, но, работая в компании, всегда следите за правами каждой учетки.

2) Цифрой 2 отмечено хранилище FTP. Здесь в основном прошивки для цисковских устройств.

Сервис настроен и раз все так прекрасно, попробуем с ним поработать. Но для начала создам текстовый файл на компьютере директора, который потом выкачаю на FTP-сервер.

Открываю компьютер директора и выбираю «Text Editor». Это аналог блокнота в ОС Windows.


Напишу туда текст и сохраню его.

Теперь попробуем залить этот файл на FTP-сервер. Открываем командную строку и пишем


То есть, как помним ранее, в начале пишется используемый протокол, а потом следует адрес. Далее, после соединения, спрашивается логин (вводим cisco) и пароль (тоже cisco). И после аутентификации попадаем на сам FTP-сервер. Список доступных команд можно проверить командой «?».

Чтобы что-то залить, используется команда «put», а скачать команда «get». Заливаем наш файл.


Ввел я команду «put» и название файла, которое хочу скопировать. И показывает он нам сообщение, что все скопировано. Файл весит 20 байтов, а скорость передачи 487 байтов в секунду. Далее ввел команду «dir», чтобы проверить содержимое сервера. И засветился на нем файл message.txt под 17 номером.

Осталось дело за малым. Это скачать файл на компьютер рабочего. Открываю я WORKER-PC и захожу в командную строку.


Выполняю я практически те же действия, что и ранее. За исключением команды «get», а не «put». Видим, что файл скачен. Еще я ввел команду «dir», чтобы показать, что при скачивании файла, оригинал не удаляется. Скачивается его копия.

И раз он скачал файл, то он должен появиться на компьютере. Открываю «Text Editor» и нажимаю File->Open.



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

Не буду повторно засорять вам голову, как это работает. Потому что работает оно точно так же, как и почтовые протоколы, Telnet, SSH и так далее. То есть создается TCP-сессия, и начинается передача/скачивание файла. Приведу только структуру его.


В TCP обращаем внимание на номер порта. Это 21 порт (стандартный порт FTP). И в поле данных FTP обозначено, что это какие-то двоичные данные.

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

И последний протокол, который остался — это TFTP.

IX) TFTP (англ. Trivial File Transfer Protocol). Простой протокол передачи файлов. Придумали его в 80-х годах. Хоть FTP был достаточно популярным, не все его функции были нужны для решения простых задач. И был придуман его простой аналог. Он работает по UDP, то есть не требует установления соединения. Также он не требует аутентификации и авторизации. Достаточно знать его IP-адрес и самому его иметь. Это конечно не безопасно, так как адрес можно подделать. Но когда нужен простой протокол и не требуется авторизация, выбор падает на него. Очень плотно с ним работает цисковское оборудование, для копирования образа или скачивания на flash-память.

Ничто не учит лучше, чем практика. Поэтому переходим к ней. Чудесным образом я обнаружил, что компьютеры в CPT не умеют работать с TFTP. Хорошо, что с цисковского оборудования не выпилили эту функцию. Поэтому будем учиться на нашем любимом коммутаторе. Схема остается такой же. Просто на FTP-сервере я включу сервис TFTP.


Вот так он выглядит. В базе куча разных прошивок для многих устройств.

Перейдем к коммутатору.

SW1#dir — команда вывода содержимого файловой системы
Directory of flash:/

1 -rw- 4414921 c2960-lanbase-mz.122-25.FX.bin
9 -rw- 1168 config.text

64016384 bytes total (59600295 bytes free)

У нас есть файл config.text. Попробуем его залить на TFTP — сервер.

SW1#copy flash: tftp: — то есть указываем откуда, а потом куда. Здесь это с flash-памяти на tftp-сервер

Source filename []? config.text — здесь он спрашивает имя файла, которое надо скопировать.

Address or name of remote host []? 192.168.1.4 — указываем куда скопировать.

Destination filename [config.text]? — и тут надо указать, под каким именем сохранить его на сервере. По умолчанию он предлагает сохранить его с тем же названием.И, если нажать клавишу ENTER, он выберет имя по умолчанию. Меня это устраивает, и я оставлю его таким же.

Writing config.text….!!!
[OK — 1168 bytes]

1168 bytes copied in 3.048 secs (383 bytes/sec)

И в заключительном сообщении он показывает, что все успешно скопировалось. Перейдем на TFTP-сервер и проверим.


И вижу, что действительно он там присутствует. Значит коммутатор меня не обманул.

Теперь попробуем что-нибудь скачать с сервера на коммутатор.

SW1#copy tftp: flash: — здесь пишем наоборот. Сначала tftp, а потом flash

Address or name of remote host []? 192.168.1.4 — адрес TFTP-сервера

Далее он спросит, что скопировать. Я не помню точное название прошивки и открою TFTP, чтобы посмотреть.


Записываю название
Source filename []? c2960-lanbasek9-mz.150-2.SE4.bin

Destination filename [c2960-lanbasek9-mz.150-2.SE4.bin]? — здесь он спрашивает, как назвать его на самом коммутаторе. Я нажму ENTER и оставлю имя по умолчанию.

Accessing tftp://192.168.1.4/c2960-lanbasek9-mz.150-2.SE4.bin…
Loading c2960-lanbasek9-mz.150-2.SE4.bin from 192.168.1.4:!!!
[OK — 4670455 bytes]

4670455 bytes copied in 0.057 secs (6587503 bytes/sec)

Выдал он мне сообщение, что загрузка прошла успешно. Проверю я наличие прошивки командой «dir».

SW1#dir
Directory of flash:/

1 -rw- 4414921 c2960-lanbase-mz.122-25.FX.bin
10 -rw- 4670455 c2960-lanbasek9-mz.150-2.SE4.bin
9 -rw- 1168 config.text

64016384 bytes total (54929840 bytes free)

Вижу, что действительно все на месте. И вдобавок он мне сообщает об объеме памяти и наличии свободного места.

Закончили мы рассматривать протоколы верхнего уровня. Не думал я, что получится настолько длинная статья. Наверное виноваты картинки. Но постарался максимально кратко и по делу. Протоколов мы рассмотрели много, и все они не заменимы. Часто выручают жизнь сисадминам и любимым нами пользователям. Спасибо, что дочитали. Если что-то непонятно, оставляйте комментарии или сразу пишите в личку. А я пошел ставить чайник и пить вкусный чай с пирожными!

Протокол DHCP для чайников — принцип работы протокола

DHCP расшифровывается, как Dynamic Host Configuration Protocol — протокол динамической конфигурации хостов. Компьютеру, для того, чтобы он мог работать в сети нужно получить IP-адрес.

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

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

Работа протокола DHCP

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

Получение IP-адреса

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

Для того, чтобы найти DHCP сервер, сообщение DHCP DISCOVER посылается на широковещательный МАК-адрес. Это сообщение принимают все компьютеры в сети.

Сервер, после того, как получил сообщение DHCP DISCOVER в ответ посылает сообщение DHCP OFFER. В сообщение DHCP сервер включает ip-адрес, который предлагает использовать клиенту.

Клиент в ответ посылает сообщение DHCP REQUEST с тем же самым ip-адресом.

На следующем шаге сервер посылает подтверждающее сообщение DHCP ACK, куда еще раз включается ip-адрес. После этого клиент может использовать ip-адрес для работы в сети. Проще всего запомнить процесс получения ip-адреса по протоколу DHCP по первым буквам DHCP сообщений DORA (Discover, Offer, Request, Ack).

Кроме тех сообщений, которые мы рассмотрели, есть и другие сообщения.

  • Сообщение NACK запрещает использование клиентом ip-адреса, который он запросил в сообщении DHCP request.
  • Сообщение RELEASE используется для освобождения ip-адреса, который уже не нужен клиенту.
  • Сообщение INFORM используется для получения информации о сети, если клиент уже знает свой IP-адрес и ему не надо получать его с помощью протокола DHCP. Например, адрес может быть сконфигурирован вручную.

Зачем нужно четыре шага?

Зачем нужно 4 шага? Ведь на первый взгляд достаточно трёх шагов. Ответ на этот вопрос Вы узнаете из видео на 3:40 минуте.

Назначение адресов в DHCP

DHCP сервер может использовать 2 способа назначения адресов компьютерам.

  1. Первый способ — фиксированный. В этом случае в конфигурационных серверах DHCP сервера для каждого МАК-адреса прописывается соответствующий ему IP-адрес, который DHCP сервер должен выдавать клиенту. Это удобно делать в небольшой сети, где Вы знаете MAC-адреса всех компьютеров. Но в крупной сети или если Вы не знаете мак-адреса всех компьютеров это сделать невозможно. Например, если вы делаете сеть в кафе, куда люди приходят со своими ноутбуками, смартфонами, планшетами, вы не можете знать заранее их мак-адреса.
  2. Другой подход — динамический. В этом случае у DHCP сервера есть пул адресов, это диапазон адресов из которого DHCP сервер может взять любой IP-адрес и назначить компьютеру. При этом DHCP сервер следит за тем, чтобы один и тот же IP-адрес из пула не был назначен двум компьютерам одновременно.

Время аренды в DHCP

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

Обновление аренды IP-адреса

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

Прекращение использования адреса

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

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

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

Конфигурационная информация

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

Поиск DHCP сервера в сети

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

Почему так происходит? Клиент DHCP при включении не знает, где находится DHCP сервер и отправляет запрос DHCP Discover на широковещательный адрес.

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

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

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

И только в этом случае DHCP сервер может выдать ip-адрес клиенту, который находится за маршрутизатором.

Заключение

Протокол DHCP используется для автоматического назначения IP-адресов и другой конфигурационной информации. Протокол DHCP использует архитектуру клиент-сервер и работает в режиме запрос ответ. Чтобы получить IP-адрес используются 4 DHCP сообщения, сокращенно DORA. DHCP сервер выдает адреса на ограниченный срок (срок аренды). Чтобы DHCP сервер мог выдавать ip-адреса клиентам, он должен находиться с ними в одной подсети или необходимо использовать DHCP Relay на маршрутизаторах и коммутаторах.

DHCP — что это такое простыми словами, как включить на роутере, адаптере?

Рад видеть Вас на fast-wolker.ru! Продолжаем изучать сетевое администрирование. Многие  пытаясь впервые настраивать роутер, сталкиваются  с неизбежными вопросами. Один из таких, на первый взгляд второстепенных вопросов — это настройка DHCP. Для  маленьких домашних сетей как правило это не актуально, и на эту опцию сначала мало кто обращает внимание.

Но, как только возникает необходимость настроить  для своих нужд работоспособную сеть  с выходом в Интернет по выделенному IP-адресу, так сказать пробелы в знаниях дают о себе знать. Читаем и берем на вооружение. В этом выпуске:

Эта статья поможет вам разобраться в теме. Все важно,  а такие «лишние» знания бесполезными не бывают и простым способом можно повысить безопасность вашей сети. Как всегда, в начале немного теории, без нее все равно никуда. Сегодня все сети построены на ключевых протоколах TCP/IP, которые во многом обеспечивает их функционирование.

Одной из служб этого протокола и является DHCP (DYNAMIC HOST CONFIGURATION PROTOCOL) или «протокол динамического конфигурирования хостов». Хостами обычно называют имена компьютеров в сети. В некотором роде они заменяют собой  IP адреса при обращении к компьютеру по имени.

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

Можно включить сервер на роутере и тогда это будет сервер. Альтернативный вариант — установить DHCP  и на компьютере , например настроить в Windows 10. Можно включать или отключать эти службы на одном из компьютеров сети — это  будет уровень клиента или  сетевого протокола.

DHCP- сервер для чего он нужен?

Представим себе ситуацию, когда наша сеть состоит хотя бы  из 100 компьютеров. Задача системного администратора — строго следить за тем, чтобы каждый компьютер и устройства в сети имели свой  уникальный IP адрес. Бедный сисадмин! Ему придется несладко, ведь он обязан все это как-то контролировать. Где-то сбился адрес и чье -то рабочее место уже не функционирует…

Первые протоколы призванные решать проблему  были разработаны для рабочих станций, у которых даже не было своих жестких дисков. Сейчас мне это кажется диким, но в году так 1998 я работал на такой сети. Загружаешься с дискетки,  MS-DOS и Far-Manager в сочетании с черно-белым монитором — это была первая моя операционная система! При включении такой  компьютер шлет в сеть сообщение. Сервер сети в ответ на это сообщение шлет свое, по которому компьютер и «узнает» свой IP.

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

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

DHCP на роутере что это?

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

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

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

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

Впрочем, на последних моделях некоторых маршрутизаторов  для ограничения доступа в Интернет достаточно сделать настройки для незарегистрированных устройств и ограничить им доступ:

DHCP relay что это? Настройка сервера на устройствах Microtic, Zyxel Keenetic Giga

На современных моделях маршрутизаторов теперь  можно встретить настройку DHCP — relay, но информации по ней в справочной системе устройства недостаточно. Опция расширяет функциональные возможности вашего устройства для системного администрирования.

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

На этот случай у вас должна быть еще одна сеть с DHCP-сервером. Все что нужно -это указать адрес  соседнего сервера DHCP  «запасной» сети. Служба DHCP-relay ageht отвечает за то, чтобы ретранслировать сообщения в другую сеть на другой сервер в случае необходимости. Адреса теперь  будет назначать не ваш сервер, а тот на который вы укажете:

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

Настройка сервера DHCP  на роутере  Zyxel Keenetic Giga

Фирма Zyxel сегодня выпускают  устройства, которые радуют глаз. Эти бренды сегодня популярны прежде всего благодаря функционалу который они предоставляют. Можно организовать несколько сетей на одном устройстве, подключить не одного провайдера а несколько и делать много других недостуных для предыдущих поколений устройств полезных вещей. Не менее хороша  фирма Microtic, сделал один раз настройки и забыл о проблемах.

Настройка сервера на маршрутизаторе самостоятельно  не представляет ничего сложного. В случае выделенного вам провайдером Интернет  IP- адреса нужно настроить подключение к Интернету:

Указываем данные от провайдера, не забываем про DNS, в качестве DNS 3 можно прописать гугловский DNS 8.8.8.8 Не помешает. Затем нужно создать сеть, или вернее сказать один из ее сегментов. В пункте «Мои сети и Wi-Fi» создаем новый сегмент:

В настройках включаем DHCP сервер. В качестве IP указываем адрес роутера, который для рабочих станций будет шлюзом:

IP роутера указан в качестве примера. Вы можете в качестве IP выбирать нестандартные диапазоны для повышения безопасности. Диапазоны определяют количество подсетей и  предельное количество рабочих станций в ней.   Начальный адрес пула   будет адресом «первого» компьютера. Размер пула — это количество компьютеров, которые у вас будут в сети. Время аренды- продолжительность выдачи адреса в секундах.

DHCP не включен на сетевом адаптере подключение по локальной (беспроводной) сети Windows 10, что делать?

По некоторым причинам (обновление Windows10, настройка Wi-FI) иногда можно увидеть эту ошибку в окне сообщений. Для начала проверим запущена ли  служба DHCP на вашем компьютере.  Нужно в «Панели управления» зайти в Администрирование — Службы…

…убеждаемся, что служба запущена; если это не так — перезапускаем ее. Теперь переходим к настройкам сетевой карты.

Как включить DHCP на сетевом адаптере Windows 10? Для этого правой кнопкой жмем на значок  подключения в нижнем правом углу монитора:

Идем в настройки параметров сетевого адаптера:

На компьютере обычно бывает больше одного сетевого адаптера. Если у вас WI-FI, то нужно выбрать его. У меня проводное подключение Нужно щелкнуть по нему правой кнопкой мыши:

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

Далее, смотрим настройки. Если у вас DHCP на роутере включен, можно поставить флаги так:

Убеждаемся, что на сетевом адаптере включился DHCP,жмем на «Дополнительно»:

Закончили настройки. Для того, чтобы изменения вступили в силу без перезагрузки, ставим галочку:

Если Вы установили Wi-Fi -адаптер

Все же бывает, что вышеописанные способы не помогают. Долго искать; поэтому  опять жмем правой кнопкой на значке подключения:

Дождитесь окончания работы мастера:

После проведенных выше настроек он гарантированно исправляет все ошибки! Вот так легко настраивать  DHCP!

Автор публикации

не в сети 5 часов

admin

0 Комментарии: 61Публикации: 386Регистрация: 04-09-2015

Процесс получения 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, то можно будет увидеть настройки, которые клиент получил от сервера.

C:\>ipconfig   FastEthernet0 Connection:(default port)   Link-local IPv6 Address………: FE80::202:17FF:FE54:C07B IP Address………………….: 192.168.0.4 Subnet Mask…………………: 255.255.255.0 Default Gateway……………..: 192.168.0.1

C:\>ipconfig

 

 

 

FastEthernet0 Connection:(default port)

 

 

 

Link-local IPv6 Address………: FE80::202:17FF:FE54:C07B

 

IP Address………………….: 192.168.0.4

 

Subnet Mask…………………: 255.255.255.0

 

Default Gateway……………..: 192.168.0.1

Чтобы окончательно убедиться в том, что все работает, можете попробовать пропинговать адрес шлюза по умолчанию.

C:\>ping 192.168.0.1   Pinging 192.168.0.1 with 32 bytes of data:   Reply from 192.168.0.1: bytes=32 time=1ms TTL=255 Reply from 192.168.0.1: bytes=32 time<1ms TTL=255 Reply from 192.168.0.1: bytes=32 time<1ms TTL=255 Reply from 192.168.0.1: bytes=32 time<1ms TTL=255   Ping statistics for 192.168.0.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 1ms, Average = 0ms

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

C:\>ping 192.168.0.1

 

 

 

Pinging 192.168.0.1 with 32 bytes of data:

 

 

 

Reply from 192.168.0.1: bytes=32 time=1ms TTL=255

 

Reply from 192.168.0.1: bytes=32 time<1ms TTL=255

 

Reply from 192.168.0.1: bytes=32 time<1ms TTL=255

 

Reply from 192.168.0.1: bytes=32 time<1ms TTL=255

 

 

 

Ping statistics for 192.168.0.1:

 

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

 

Approximate round trip times in milli-seconds:

 

Minimum = 0ms, Maximum = 1ms, Average = 0ms

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

9.2.5 Выводы

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

DHCP (протокол динамической конфигурации хоста), основы

  • 14 минут на чтение

В этой статье

Протокол динамической конфигурации хоста (DHCP) — это стандартный протокол, определенный в RFC 1541 (который заменен RFC 2131), который позволяет серверу динамически распределять IP-адресацию и информацию о конфигурации клиентам.Обычно DHCP-сервер предоставляет клиенту по крайней мере эту базовую информацию:

  • IP-адрес

  • Маска подсети

  • Шлюз по умолчанию Также может быть предоставлена ​​другая информация, например, адреса серверов службы доменных имен (DNS) и адреса серверов службы имен Интернета (WINS) Windows. Системный администратор настраивает DHCP-сервер с параметрами, которые передаются клиенту.

Дополнительная информация

Следующие продукты Microsoft предоставляют функции клиента DHCP:

  • Windows NT Server версии 3.5, 3.51 и 4.0

  • Рабочая станция Windows NT версий 3.5, 3.51 и 4.0

  • Окна 95

  • Сетевой клиент Microsoft версии 3.0 для MS-DOS

  • Клиент Microsoft LAN Manager версии 2.2c для MS-DOS

  • Microsoft TCP / IP-32 для Windows для рабочих групп версий 3.11, 3.11a и 3.11b

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

Следующие серверные операционные системы Microsoft предоставляют функции DHCP-сервера:

  • Windows NT Server версии 3.5

  • Windows NT Server версии 3.51

  • Windows NT Server версии 4.0

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

Ниже представлена ​​сводная таблица диалога между клиентом и сервером, за которой следует описание процесса на уровне пакетов: 

  Source Dest Источник Dest Packet
 MAC-адрес MAC-адрес IP-адрес IP-адрес Описание
 -------------------------------------------------- ---------------
 Клиентская трансляция 0.0.0.0 255.255.255.255 Обнаружение DHCP
 DHCPsrvr Broadcast DHCPsrvr 255.255.255.255 Предложение DHCP
 Клиентская широковещательная рассылка 0.0.0.0 255.255.255.255 DHCP-запрос
 DHCPsrvr Широковещательная рассылка DHCPsrvr 255.255.255.255 DHCP ACK

Подробный диалог между DHCP-клиентом и DHCP-сервером выглядит следующим образом:

DHCPDISCOVER

Клиент отправляет пакет DHCPDISCOVER. Ниже приведен отрывок из захвата монитора сети, показывающий части IP и DHCP пакета DHCPDISCOVER. В разделе IP вы можете увидеть, что адрес назначения — 255.255.255.255, а адрес источника — 0.0.0.0. Раздел DHCP идентифицирует пакет как пакет обнаружения и идентифицирует клиента в двух местах, используя физический адрес сетевой карты. Обратите внимание, что значения в полях CHADDR и DHCP: Client Identifier идентичны. 

 
IP: ID = 0x0; Прото = UDP; Длина: 328
 IP: Версия = 4 (0x4)
 IP: длина заголовка = 20 (0x14)
 IP: Тип службы = 0 (0x0)
 IP: Приоритет = Обычный
 IP: ... 0 .... = нормальная задержка
 IP: .... 0 ... = нормальная пропускная способность
 IP:..... 0 .. = нормальная надежность
 IP: общая длина = 328 (0x148)
 IP: Идентификация = 0 (0x0)
 IP: сводка флагов = 0 (0x0)
 IP: ....... 0 = последний фрагмент в дейтаграмме
 IP: ...... 0. = При необходимости может фрагментировать дейтаграмму
 IP: смещение фрагмента = 0 (0x0) байт
 IP: Время жизни = 128 (0x80)
 IP: Протокол = UDP - дейтаграмма пользователя
 IP: Контрольная сумма = 0x39A6
 IP: исходный адрес = 0.0.0.0
 IP: адрес назначения = 255.255.255.255
 IP: Данные: количество оставшихся байтов данных = 308 (0x0134)

DHCP: обнаружение (xid = 21274A1D)
 DHCP: код операции (op) = 1 (0x1)
 DHCP: Тип оборудования (htype) = 1 (0x1) 10 Мбит Ethernet
 DHCP: длина аппаратного адреса (hlen) = 6 (0x6)
 DHCP: Hops (переходы) = 0 (0x0)
 DHCP: идентификатор транзакции (xid) = 556223005 (0x21274A1D)
 DHCP: секунды (secs) = 0 (0x0)
 DHCP: флаги (флаги) = 0 (0x0)
 DHCP: 0............... = Нет трансляции
 DHCP: IP-адрес клиента (ciaddr) = 0.0.0.0
 DHCP: ваш IP-адрес (yiaddr) = 0.0.0.0
 DHCP: IP-адрес сервера (siaddr) = 0.0.0.0
 DHCP: IP-адрес ретрансляции (giaddr) = 0.0.0.0
 DHCP: Ethernet-адрес клиента (chaddr) = 08002B2ED85E
 DHCP: имя хоста сервера (sname) = 
 DHCP: имя загрузочного файла (файл) = 
 DHCP: Magic Cookie = [OK]
 DHCP: поле параметров (параметры)
 DHCP: Тип сообщения DHCP = Обнаружение DHCP
 DHCP: идентификатор-клиента = (Тип: 1) 08 00 2b 2e d8 5e
 DHCP: имя хоста = JUMBO-WS
 DHCP: Список запросов параметров = (Длина: 7) 01 0f 03 2c 2e 2f 06
 DHCP: конец этого поля параметра

DHCPOFFER

DHCP-сервер отвечает посылкой пакета DHCPOFFER.В разделе IP фрагмента захвата ниже адрес источника теперь является IP-адресом DHCP-сервера, а адрес назначения — широковещательный адрес 255.255.255.255. Раздел DHCP идентифицирует пакет как предложение. В поле YIADDR указывается IP-адрес, который сервер предлагает клиенту. Обратите внимание, что поле CHADDR по-прежнему содержит физический адрес запрашивающего клиента. Кроме того, мы видим в разделе «Поле параметров DHCP» различные параметры, отправляемые сервером вместе с IP-адресом.В этом случае сервер отправляет маску подсети, шлюз по умолчанию (маршрутизатор), время аренды, адрес WINS-сервера (служба имен NetBIOS) и тип узла NetBIOS. 

 
IP: ID = 0x3C30; Прото = UDP; Длина: 328
 IP: Версия = 4 (0x4)
 IP: длина заголовка = 20 (0x14)
 IP: Тип службы = 0 (0x0)
 IP: Приоритет = Обычный
 IP: ... 0 .... = нормальная задержка
 IP: .... 0 ... = нормальная пропускная способность
 IP: ..... 0 .. = нормальная надежность
 IP: общая длина = 328 (0x148)
 IP: Идентификация = 15408 (0x3C30)
 IP: сводка флагов = 0 (0x0)
 IP:....... 0 = последний фрагмент в дейтаграмме
 IP: ...... 0. = При необходимости может фрагментировать дейтаграмму
 IP: смещение фрагмента = 0 (0x0) байт
 IP: Время жизни = 128 (0x80)
 IP: Протокол = UDP - дейтаграмма пользователя
 IP: Контрольная сумма = 0x2FA8
 IP: исходный адрес = 157.54.48.151
 IP: адрес назначения = 255.255.255.255
 IP: Данные: количество оставшихся байтов данных = 308 (0x0134)

DHCP: предложение (xid = 21274A1D)
 DHCP: код операции (op) = 2 (0x2)
 DHCP: Тип оборудования (htype) = 1 (0x1) 10 Мбит Ethernet
 DHCP: длина аппаратного адреса (hlen) = 6 (0x6)
 DHCP: Hops (переходы) = 0 (0x0)
 DHCP: идентификатор транзакции (xid) = 556223005 (0x21274A1D)
 DHCP: секунды (secs) = 0 (0x0)
 DHCP: флаги (флаги) = 0 (0x0)
 DHCP: 0............... = Нет трансляции
 DHCP: IP-адрес клиента (ciaddr) = 0.0.0.0
 DHCP: ваш IP-адрес (yiaddr) = 157.54.50.5
 DHCP: IP-адрес сервера (siaddr) = 0.0.0.0
 DHCP: IP-адрес ретрансляции (giaddr) = 0.0.0.0
 DHCP: Ethernet-адрес клиента (chaddr) = 08002B2ED85E
 DHCP: имя хоста сервера (sname) = 
 DHCP: имя загрузочного файла (файл) = 
 DHCP: Magic Cookie = [OK]
 DHCP: поле параметров (параметры)
 DHCP: Тип сообщения DHCP = Предложение DHCP
 DHCP: маска подсети = 255.255.240.0
 DHCP: значение времени продления (T1) = 8 дней, 0:00:00
 DHCP: значение времени повторной привязки (T2) = 14 дней, 0:00:00
 DHCP: время аренды IP-адреса = 16 дней, 0:00:00
 DHCP: идентификатор сервера = 157.54,48,151
 DHCP: Маршрутизатор = 157.54.48.1
 DHCP: Служба имен NetBIOS = 157.54.16.154
 DHCP: Тип узла NetBIOS = (Длина: 1) 04
 DHCP: конец этого поля параметра

DHCPREQUEST

Клиент отвечает на DHCPOFFER, отправляя DHCPREQUEST. В разделе IP захвата ниже исходный адрес клиента по-прежнему 0.0.0.0, а пункт назначения для пакета по-прежнему 255.255.255.255. Клиент сохраняет 0.0.0.0, потому что клиент не получил от сервера подтверждения, что можно использовать предложенный адрес.Пункт назначения по-прежнему транслируется, потому что более одного DHCP-сервера могли ответить и могут удерживать резервирование для предложения, сделанного клиенту. Это позволяет другим DHCP-серверам знать, что они могут освободить предложенные адреса и вернуть их в свои доступные пулы. Раздел DHCP идентифицирует пакет как запрос и проверяет предложенный адрес с помощью поля DHCP: запрошенный адрес. В поле DHCP: Server Identifier отображается IP-адрес DHCP-сервера, предлагающего аренду. 

 
IP: ID = 0x100; Прото = UDP; Длина: 328
 IP: Версия = 4 (0x4)
 IP: длина заголовка = 20 (0x14)
 IP: Тип службы = 0 (0x0)
 IP: Приоритет = Обычный
 IP:...0 .... = Нормальная задержка
 IP: .... 0 ... = нормальная пропускная способность
 IP: ..... 0 .. = нормальная надежность
 IP: общая длина = 328 (0x148)
 IP: Идентификация = 256 (0x100)
 IP: сводка флагов = 0 (0x0)
 IP: ....... 0 = последний фрагмент в дейтаграмме
 IP: ...... 0. = При необходимости может фрагментировать дейтаграмму
 IP: смещение фрагмента = 0 (0x0) байт
 IP: Время жизни = 128 (0x80)
 IP: Протокол = UDP - дейтаграмма пользователя
 IP: Контрольная сумма = 0x38A6
 IP: исходный адрес = 0.0.0.0
 IP: адрес назначения = 255.255.255.255
 IP: Данные: количество оставшихся байтов данных = 308 (0x0134)

DHCP: запрос (xid = 21274A1D)
 DHCP: код операции (op) = 1 (0x1)
 DHCP: Тип оборудования (htype) = 1 (0x1) 10 Мбит Ethernet
 DHCP: длина аппаратного адреса (hlen) = 6 (0x6)
 DHCP: Hops (переходы) = 0 (0x0)
 DHCP: идентификатор транзакции (xid) = 556223005 (0x21274A1D)
 DHCP: секунды (secs) = 0 (0x0)
 DHCP: флаги (флаги) = 0 (0x0)
 DHCP: 0............... = Нет трансляции
 DHCP: IP-адрес клиента (ciaddr) = 0.0.0.0
 DHCP: ваш IP-адрес (yiaddr) = 0.0.0.0
 DHCP: IP-адрес сервера (siaddr) = 0.0.0.0
 DHCP: IP-адрес ретрансляции (giaddr) = 0.0.0.0
 DHCP: Ethernet-адрес клиента (chaddr) = 08002B2ED85E
 DHCP: имя хоста сервера (sname) = 
 DHCP: имя загрузочного файла (файл) = 
 DHCP: Magic Cookie = [OK]
 DHCP: поле параметров (параметры)
 DHCP: Тип сообщения DHCP = Запрос DHCP
 DHCP: идентификатор-клиента = (Тип: 1) 08 00 2b 2e d8 5e
 DHCP: запрошенный адрес = 157.54,50,5
 DHCP: идентификатор сервера = 157.54.48.151
 DHCP: имя хоста = JUMBO-WS
 DHCP: Список запросов параметров = (Длина: 7) 01 0f 03 2c 2e 2f 06
 DHCP: конец этого поля параметра

DHCPACK

DHCP-сервер отвечает на DHCPREQUEST DHCPACK, таким образом завершая цикл инициализации. Исходный адрес — это IP-адрес DHCP-сервера, а адрес назначения по-прежнему 255.255.255.255. Поле YIADDR содержит адрес клиента, а поля CHADDR и DHCP: Client Identifier — это физический адрес сетевой карты в запрашивающем клиенте.Раздел DHCP Option идентифицирует пакет как ACK. 

 
IP: ID = 0x3D30; Прото = UDP; Длина: 328
 IP: Версия = 4 (0x4)
 IP: длина заголовка = 20 (0x14)
 IP: Тип службы = 0 (0x0)
 IP: Приоритет = Обычный
 IP: ... 0 .... = нормальная задержка
 IP: .... 0 ... = нормальная пропускная способность
 IP: ..... 0 .. = нормальная надежность
 IP: общая длина = 328 (0x148)
 IP: Идентификация = 15664 (0x3D30)
 IP: сводка флагов = 0 (0x0)
 IP: ....... 0 = последний фрагмент в дейтаграмме
 IP: ...... 0. = При необходимости может фрагментировать дейтаграмму
 IP: смещение фрагмента = 0 (0x0) байт
 IP: Время жизни = 128 (0x80)
 IP: Протокол = UDP - дейтаграмма пользователя
 IP: Контрольная сумма = 0x2EA8
 IP: исходный адрес = 157.54,48,151
 IP: адрес назначения = 255.255.255.255
 IP: Данные: количество оставшихся байтов данных = 308 (0x0134)

DHCP: ACK (xid = 21274A1D)
 DHCP: код операции (op) = 2 (0x2)
 DHCP: Тип оборудования (htype) = 1 (0x1) 10 Мбит Ethernet
 DHCP: длина аппаратного адреса (hlen) = 6 (0x6)
 DHCP: Hops (переходы) = 0 (0x0)
 DHCP: идентификатор транзакции (xid) = 556223005 (0x21274A1D)
 DHCP: секунды (secs) = 0 (0x0)
 DHCP: флаги (флаги) = 0 (0x0)
 DHCP: 0 ............... = Нет широковещательной передачи
 DHCP: IP-адрес клиента (ciaddr) = 0.0.0.0
 DHCP: ваш IP-адрес (yiaddr) = 157.54,50,5
 DHCP: IP-адрес сервера (siaddr) = 0.0.0.0
 DHCP: IP-адрес ретрансляции (giaddr) = 0.0.0.0
 DHCP: Ethernet-адрес клиента (chaddr) = 08002B2ED85E
 DHCP: имя хоста сервера (sname) = 
 DHCP: имя загрузочного файла (файл) = 
 DHCP: Magic Cookie = [OK]
 DHCP: поле параметров (параметры)
 DHCP: Тип сообщения DHCP = DHCP ACK
 DHCP: значение времени продления (T1) = 8 дней, 0:00:00
 DHCP: значение времени повторной привязки (T2) = 14 дней, 0:00:00
 DHCP: время аренды IP-адреса = 16 дней, 0:00:00
 DHCP: идентификатор сервера = 157.54,48,151
 DHCP: маска подсети = 255.255.240.0
 DHCP: Маршрутизатор = 157.54.48.1
 DHCP: Служба имен NetBIOS = 157.54.16.154
 DHCP: Тип узла NetBIOS = (Длина: 1) 04
 DHCP: конец этого поля параметра

Если клиенту ранее был назначен IP-адрес DHCP и он перезапускается, клиент будет специально запрашивать ранее арендованный IP-адрес в специальном пакете DHCPREQUEST. Исходный адрес — 0.0.0.0, а Назначение — широковещательный адрес 255.255.255.255. Клиенты Microsoft будут заполнять поле DHCP Option Field DHCP: Requested Address ранее назначенным адресом.Клиенты, строго соответствующие RFC, будут заполнять поле CIADDR запрошенным адресом. Сервер Microsoft DHCP примет и то, и другое. 

 
IP: ID = 0x0; Прото = UDP; Длина: 328
 IP: Версия = 4 (0x4)
 IP: длина заголовка = 20 (0x14)
 IP: Тип службы = 0 (0x0)
 IP: Приоритет = Обычный
 IP: ... 0 .... = нормальная задержка
 IP: .... 0 ... = нормальная пропускная способность
 IP: ..... 0 .. = нормальная надежность
 IP: общая длина = 328 (0x148)
 IP: Идентификация = 0 (0x0)
 IP: сводка флагов = 0 (0x0)
 IP: ....... 0 = последний фрагмент в дейтаграмме
 IP: ...... 0. = При необходимости может фрагментировать дейтаграмму
 IP: смещение фрагмента = 0 (0x0) байт
 IP: Время жизни = 128 (0x80)
 IP: Протокол = UDP - дейтаграмма пользователя
 IP: Контрольная сумма = 0x39A6
 IP: исходный адрес = 0.0.0.0
 IP: адрес назначения = 255.255.255.255
 IP: Данные: количество оставшихся байтов данных = 308 (0x0134)

DHCP: запрос (xid = 2757554E)
 DHCP: код операции (op) = 1 (0x1)
 DHCP: Тип оборудования (htype) = 1 (0x1) 10 Мбит Ethernet
 DHCP: длина аппаратного адреса (hlen) = 6 (0x6)
 DHCP: Hops (переходы) = 0 (0x0)
 DHCP: идентификатор транзакции (xid) = 660034894 (0x2757554E)
 DHCP: секунды (secs) = 0 (0x0)
 DHCP: флаги (флаги) = 0 (0x0)
 DHCP: 0............... = Нет трансляции
 DHCP: IP-адрес клиента (ciaddr) = 0.0.0.0
 DHCP: ваш IP-адрес (yiaddr) = 0.0.0.0
 DHCP: IP-адрес сервера (siaddr) = 0.0.0.0
 DHCP: IP-адрес ретрансляции (giaddr) = 0.0.0.0
 DHCP: Ethernet-адрес клиента (chaddr) = 08002B2ED85E
 DHCP: имя хоста сервера (sname) = 
 DHCP: имя загрузочного файла (файл) = 
 DHCP: Magic Cookie = [OK]
 DHCP: поле параметров (параметры)
 DHCP: Тип сообщения DHCP = Запрос DHCP
 DHCP: идентификатор-клиента = (Тип: 1) 08 00 2b 2e d8 5e
 DHCP: запрошенный адрес = 157.54,50,5
 DHCP: имя хоста = JUMBO-WS
 DHCP: Список запросов параметров = (Длина: 7) 01 0f 03 2c 2e 2f 06
 DHCP: конец этого поля параметра

На этом этапе сервер может или не может ответить. Поведение DHCP-сервера Windows NT зависит от версии используемой операционной системы, а также от других факторов, таких как суперобласть. Если сервер определяет, что клиент по-прежнему может использовать адрес, он либо молчит, либо ПОДТВЕРЖДАЕТ DHCPREQUEST. Если сервер определяет, что у клиента не может быть адреса, он отправит NACK.

 
IP: ID = 0x3F1A; Прото = UDP; Длина: 328
 IP: Версия = 4 (0x4)
 IP: длина заголовка = 20 (0x14)
 IP: Тип службы = 0 (0x0)
 IP: Приоритет = Обычный
 IP: ... 0 .... = нормальная задержка
 IP: .... 0 ... = нормальная пропускная способность
 IP: ..... 0 .. = нормальная надежность
 IP: общая длина = 328 (0x148)
 IP: Идентификация = 16154 (0x3F1A)
 IP: сводка флагов = 0 (0x0)
 IP: ....... 0 = последний фрагмент в дейтаграмме
 IP: ...... 0. = При необходимости может фрагментировать дейтаграмму
 IP: смещение фрагмента = 0 (0x0) байт
 IP: Время жизни = 128 (0x80)
 IP: Протокол = UDP - дейтаграмма пользователя
 IP: Контрольная сумма = 0x2CBE
 IP: исходный адрес = 157.54,48,151
 IP: адрес назначения = 255.255.255.255
 IP: Данные: количество оставшихся байтов данных = 308 (0x0134)

DHCP: NACK (xid = 74A005CE)
 DHCP: код операции (op) = 2 (0x2)
 DHCP: Тип оборудования (htype) = 1 (0x1) 10 Мбит Ethernet
 DHCP: длина аппаратного адреса (hlen) = 6 (0x6)
 DHCP: Hops (переходы) = 0 (0x0)
 DHCP: идентификатор транзакции (xid) = 1956644302 (0x74A005CE)
 DHCP: секунды (secs) = 0 (0x0)
 DHCP: флаги (флаги) = 0 (0x0)
 DHCP: 0 ............... = Нет широковещательной передачи
 DHCP: IP-адрес клиента (ciaddr) = 0.0.0.0
 DHCP: ваш IP-адрес (yiaddr) = 0.0,0.0
 DHCP: IP-адрес сервера (siaddr) = 0.0.0.0
 DHCP: IP-адрес ретрансляции (giaddr) = 0.0.0.0
 DHCP: Ethernet-адрес клиента (chaddr) = 08002B2ED85E
 DHCP: имя хоста сервера (sname) = 
 DHCP: имя загрузочного файла (файл) = 
 DHCP: Magic Cookie = [OK]
 DHCP: поле параметров (параметры)
 DHCP: Тип сообщения DHCP = DHCP NACK
 DHCP: идентификатор сервера = 157.54.48.151
 DHCP: конец этого поля параметра

Затем клиент начнет процесс обнаружения, но пакет DHCPDISCOVER по-прежнему будет пытаться арендовать тот же адрес.Во многих случаях t-й клиент получит тот же адрес, но может и не получить. 

 
IP: ID = 0x100; Прото = UDP; Длина: 328
 IP: Версия = 4 (0x4)
 IP: длина заголовка = 20 (0x14)
 IP: Тип службы = 0 (0x0)
 IP: Приоритет = Обычный
 IP: ... 0 .... = нормальная задержка
 IP: .... 0 ... = нормальная пропускная способность
 IP: ..... 0 .. = нормальная надежность
 IP: общая длина = 328 (0x148)
 IP: Идентификация = 256 (0x100)
 IP: сводка флагов = 0 (0x0)
 IP: ....... 0 = последний фрагмент в дейтаграмме
 IP: ...... 0. = При необходимости может фрагментировать дейтаграмму
 IP: смещение фрагмента = 0 (0x0) байт
 IP: Время жизни = 128 (0x80)
 IP: Протокол = UDP - дейтаграмма пользователя
 IP: Контрольная сумма = 0x38A6
 IP: исходный адрес = 0.0,0.0
 IP: адрес назначения = 255.255.255.255
 IP: Данные: количество оставшихся байтов данных = 308 (0x0134)

DHCP: обнаружение (xid = 3ED14752)
 DHCP: код операции (op) = 1 (0x1)
 DHCP: Тип оборудования (htype) = 1 (0x1) 10 Мбит Ethernet
 DHCP: длина аппаратного адреса (hlen) = 6 (0x6)
 DHCP: Hops (переходы) = 0 (0x0)
 DHCP: идентификатор транзакции (xid) = 1053
4 (0x3ED14752)
 DHCP: секунды (secs) = 0 (0x0)
 DHCP: флаги (флаги) = 0 (0x0)
 DHCP: 0 ............... = Нет широковещательной передачи
 DHCP: IP-адрес клиента (ciaddr) = 0.0.0.0
 DHCP: ваш IP-адрес (yiaddr) = 0.0,0.0
 DHCP: IP-адрес сервера (siaddr) = 0.0.0.0
 DHCP: IP-адрес ретрансляции (giaddr) = 0.0.0.0
 DHCP: Ethernet-адрес клиента (chaddr) = 08002B2ED85E
 DHCP: имя хоста сервера (sname) = 
 DHCP: имя загрузочного файла (файл) = 
 DHCP: Magic Cookie = [OK]
 DHCP: поле параметров (параметры)
 DHCP: Тип сообщения DHCP = Обнаружение DHCP
 DHCP: идентификатор-клиента = (Тип: 1) 08 00 2b 2e d8 5e
 DHCP: запрошенный адрес = 157.54.51.5
 DHCP: имя хоста = JUMBO-WS
 DHCP: Список запросов параметров = (Длина: 7) 01 0f 03 2c 2e 2f 06
 DHCP: конец этого поля параметра

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

Для просмотра информации IP на клиенте Windows или Windows для рабочих групп используйте служебную программу IPCONFIG. Если клиент — Windows 95, используйте WINIPCFG.

Список литературы

Для получения дополнительной информации о DHCP см. RFC1541 и RFC2131. RFC можно получить через Интернет на многих сайтах, например: http: // www.rfc-editor.org/ и http://www.tech-nic.qc.ca/

ISC DHCP 4.4 Страницы руководства

ИМЯ
ОБЗОР
ОПИСАНИЕ
ОПЕРАЦИЯ
КОМАНДНАЯ СТРОКА
ПАРАМЕТРЫ КОМАНДНОЙ СТРОКИ
ПОРТЫ
КОНФИГУРАЦИЯ
Подсети
Длина аренды
Поддержка BOOTP
Опции
ОБЪЕКТ ОМАПИ
ОБЪЕКТ
АРЕНДА КОНТРОЛЬНАЯ СТРОКА ОБЪЕКТ
ГРУППА ОБЪЕКТ
ОБЪЕКТ 909 КОНТРОЛЬ ОБЪЕКТА 9014 -ГОСУДАРСТВЕННЫЙ ОБЪЕКТ
ФАЙЛЫ
СМОТРИ ТАКЖЕ
АВТОР

НАЗВАНИЕ

dhcpd — динамический Сервер протокола конфигурации хоста

ОБЗОР

dhcpd [ -p порт ] [ -f ] [ -d ] [ -q ] [ -t | -T ] [ -4 | -6 ] [ -4o6 порт ] [ -s сервер ] [ -cf файл конфигурации ] [ -lf файл аренды ] [ -pf файл pid ] [ —no-pid ] [ -пользователь пользователь ] [ -группа группа ] [ -корневой dir ] [ -tf файл-вывода трассировки ] [-play файл воспроизведения трассировки ] [ if0 […ifN ] ]

dhcpd — версия

ОПИСАНИЕ

Интернет DHCP-сервер системного консорциума, dhcpd, реализует Протокол динамической конфигурации хоста (DHCP) и Интернет Протокол начальной загрузки (BOOTP). DHCP позволяет хостам использовать TCP / IP сеть для запроса и назначения IP-адресов, а также для узнать информацию о сети, к которой они прилагается. BOOTP предоставляет аналогичные функции, но с некоторыми ограничения.

ЭКСПЛУАТАЦИЯ

DHCP протокол разрешает хост, который неизвестен сети администратору будет автоматически назначен новый IP-адрес из пула IP-адресов для своей сети.Для того чтобы это работает, сетевой администратор назначает адрес пулы в каждой подсети и вводит их в dhcpd.conf (5) файл.

Есть два версии протокола DHCP DHCPv4 и DHCPv6. При запуске сервер может быть запущен для одного или другого через -4 или -6 аргументов.

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

Для того, чтобы отслеживать аренду при перезагрузке системы и сервера перезапускается, dhcpd сохраняет список назначенных им аренд файл dhcpd.leases (5) файл. До того, как dhcpd передаст в аренду host, он записывает аренду в этот файл и проверяет, что содержимое файла сбрасывается на диск. Это гарантирует что даже в случае сбоя системы dhcpd не будет забудьте об аренде, которую он назначил. При запуске, после читая файл dhcpd.conf, dhcpd читает dhcpd.leases файл, чтобы обновить его память о том, какие аренды были назначен.

Новые договоры аренды добавляется в конец файла dhcpd.leases. Чтобы предотвращать случайное увеличение размера файла к моменту dhcpd создает новый dhcpd.арендует файл из своего в основной базе данных аренды. Как только этот файл был записан в disk старый файл переименовывается в dhcpd.leases ~ , а новый файл переименовывается в dhcpd.leases. Если система вылетает в середине этого процесса, в зависимости от того, какой файл dhcpd.leases остатки будут содержать всю информацию об аренде, поэтому есть нет необходимости в специальном процессе восстановления после сбоя.

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

клиентов BOOTP может также подаваться старым стандартным способом, то есть просто укажите объявление в файле dhcpd.conf для каждого BOOTP клиент, постоянно присваивающий адрес каждому клиент.

Всегда вносятся изменения в файл dhcpd.conf, dhcpd должен быть перезапущен. Чтобы перезапустить dhcpd, отправьте SIGTERM (сигнал 15) на адрес идентификатор процесса, содержащийся в RUNDIR / dhcpd.pid , и затем повторно вызовите dhcpd. Поскольку база данных DHCP-сервера не такой легкий, как база данных BOOTP, dhcpd не автоматически перезапускается, когда видит изменение в файл dhcpd.conf.

Примечание: мы получаем много жалоб по этому поводу. Мы понимаем, что это будет хорошо, если бы можно было отправить SIGHUP на сервер и получить его перезагрузить базу данных.Это не технически невозможно, но это потребует большой работы, наши ресурсы чрезвычайно ограничены, и их лучше потратить в другом месте. Так что не жалуйтесь на это в рассылке список, если вы не готовы финансировать проект реализовать эту функцию или подготовиться сделать это самостоятельно.

КОМАНДНАЯ СТРОКА

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

ПАРАМЕТРЫ КОМАНДНОЙ СТРОКИ

−4

Запуск как DHCP сервер. Это значение по умолчанию, и его нельзя комбинировать с −6 .

−6

Запуск как DHCPv6 сервер.Это не может быть объединено с −4 .

−4o6 порт

Участвовать в DHCPv4 через Протокол DHCPv6, указанный в RFC 7341. Это связывает DHCPv4 и сервер DHCPv6, чтобы сервер v4 мог получать Запросы v4, которые были инкапсулированы в пакет v6. Связь между двумя серверами осуществляется по паре Сокеты UDP привязаны к :: 1 порту и порту + 1 . Оба сервера должны быть запущены с использованием одного и того же порта аргумент.

−p порт

Номер порта UDP, на котором dhcpd стоит послушать. Если не указано , dhcpd использует порт по умолчанию 67. Это в основном полезно для отладки целей.

−s адрес

Укажите адрес или имя хоста на который dhcpd должен отправлять ответы, а не широковещательный адрес (255.255.255.255). Этот вариант только поддерживается в IPv4.

−f

Force dhcpd для запуска как процесс переднего плана, а не как демон в задний план.Это полезно при запуске dhcpd под отладчик, или при его запуске из inittab в System V системы.

-d

Отправить сообщения журнала в стандартный дескриптор ошибки. Это может быть полезно для отладки, а также на сайтах, где ведется полный журнал всех активность dhcp должна быть сохранена, но syslogd ненадежен или иначе не может быть использован. Обычно dhcpd регистрирует весь вывод с использованием функции syslog (3) с журналом средство установлено на LOG_DAEMON.Обратите внимание, что −d подразумевает -f (демон не будет разветвляться на задний план).

−q

Тихо на запускать. Это подавляет печать всего сообщение об авторских правах при запуске. Это может быть желательно при запуске dhcpd из сценария запуска системы (например, / etc / rc).

−t

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

-Т

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

−пользователь пользователь

Setuid пользователю после завершения привилегированные операции, такие как создание сокетов, которые слушают на привилегированных портах. Это также приводит к тому, что файл аренды принадлежит пользователю. Эта опция доступна, только если код был скомпилирован патчем PARANOIA (./ настроить — включить-паранойя).

−группа группа

Setgid для группы после выполнение привилегированных операций, таких как создание сокетов которые прослушивают привилегированные порты. Это также вызывает аренду файл для использования группы. Эта опция доступна, только если код был скомпилирован с помощью патча PARANOIA (./configure — включить-паранойя).

−chroot dir

Chroot в каталог. Это может происходят до или после чтения файлов конфигурации в зависимости от того, был ли скомпилирован код с Включена опция EARLY_CHROOT (./ настроить —enable-Early-chroot). Эта опция доступна, только если код был скомпилирован с помощью патча PARANOIA (./configure — включить-паранойя).

−tf файл трассировки

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

−play файл воспроизведения

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

— версия

Распечатать номер версии и Выход.

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

Путь к альтернативной конфигурации файл.

−lf арендное дело

Путь к альтернативной аренде файл.

−pf pid-файл

Путь к альтернативному файлу pid.

−-no-pid

Возможность отключить запись pid файлы. По умолчанию программа напишет файл pid. Если программа вызывается с этой опцией, она не проверяет наличие существующий серверный процесс.

ПОРТЫ

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

Обычно Сервер DHCPv4 откроет необработанный сокет UDP для приема и отправки большинство пакетов DHCPv4. Он также открывает резервный UDP-сокет для использовать при отправке одноадресных пакетов. Обычно они оба используют хорошо известный номер порта для BOOTPS.

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

Для DHCPv6 сервер открывает UDP-сокет на хорошо известном dhcpv6-сервере порт.

Сервер открывает сокет icmp для выполнения запросов ping, чтобы проверить, адреса уже используются.

Если у вас есть включил оператор omapi-port в ваш файл конфигурации тогда сервер откроет TCP-сокет на этом порту, чтобы прослушивать соединения OMPAI. Когда что-то соединяется другой порт будет использоваться для установленного подключение.

Когда DDNS включен во время компиляции (см. includes / site.h) сервер откроет UDP-сокет v4 и v6 на случайных портах, если обновления DDNS не отключены глобально, установив ddns-update-style на none в файле конфигурации.

КОНФИГУРАЦИЯ

Синтаксис файл dhcpd.conf (5) обсуждается отдельно. Эта секция следует использовать как обзор процесса настройки, и документацию dhcpd.conf (5) следует использовать для подробная справочная информация.

Подсети

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

подсеть 239.252.197.0 сетевая маска 255.255.255,0 {

диапазон 239.252.197.10 239.252.197.250;

}

Несколько диапазоны адресов можно указать так:

подсеть 239.252.197.0 сетевая маска 255.255.255.0 {

диапазон 239.252.197.10 239.252.197.107;

диапазон 239.252.197.113 239.252.197.250;

}

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

Срок аренды

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

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

Возможно чтобы указать две длины аренды: длину по умолчанию, которая будет назначается, если клиент не запрашивает каких-либо конкретных продолжительность аренды и максимальная продолжительность аренды.Эти указано как пункты к команде подсети:

подсеть 239.252.197.0 сетевая маска 255.255.255.0 {

диапазон 239.252.197.10 239.252.197.107;

время аренды по умолчанию 600;

max-lease-time 7200;

}

Это конкретное объявление подсети указывает время аренды по умолчанию 600 секунд (десять минут) и максимальное время аренды 7200 секунды (два часа).Другие общие значения будут 86400 (один день), 604800 (одна неделя) и 2592000 (30 дней).

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

Поддержка BOOTP

Каждый BOOTP Клиент должен быть явно объявлен в файле dhcpd.conf. А в очень простой декларации клиента будет указан клиент аппаратный адрес сетевого интерфейса и IP адрес для назначения этому клиенту.Если клиенту нужно быть может загрузить загрузочный файл с сервера, этот файл имя должно быть указано. Простое объявление клиента bootp может выглядеть так:

host haagen {

аппаратный Ethernet 08: 00: 2b: 4c: 59: 23;

фиксированный адрес 239.252.197.9;

имя файла «/tftpboot/haagen.boot»;

}

Опции

DHCP (а также BOOTP с расширениями поставщика) предоставляют механизм, посредством которого сервер может предоставить клиенту информацию о том, как для настройки сетевого интерфейса (например,g., маска подсети) и также как клиент может получить доступ к различным сетевым сервисам (например, DNS, IP-маршрутизаторы и т. д.).

Эти параметры можно указать для каждой подсети, а для BOOTP клиентов, в том числе для каждого клиента. В случае, если В декларации клиента BOOTP указаны параметры, которые также указано в его объявлении подсети, указанные параметры в декларации клиента имеют приоритет. Разумно полная конфигурация DHCP может выглядеть примерно так это:

подсеть 239.252.197.0 маска сети 255.255.255.0 {

диапазон 239.252.197.10 239.252.197.250;

время аренды по умолчанию 600;

max-lease-time 7200;

опция маска подсети 255.255.255.0;

опция широковещательного адреса 239.252.197.255;

дополнительные маршрутизаторы 239.252.197.1;

option domain-name-servers 239.252.197.2, 239.252.197.3;

вариант доменного имени «isc.org»;

}

Хост bootp на эта подсеть, которая должна находиться в другом домене и использовать другой сервер имен может быть объявлен следующим образом:

host haagen {

аппаратный Ethernet 08: 00: 2b: 4c: 59: 23;

фиксированный адрес 239.252.197.9;

имя файла «/tftpboot/haagen.boot»;

option domain-name-servers 192.5.5.1;

вариант доменного имени «example.com»;

}

Более полный описание синтаксиса файла dhcpd.conf приведено в dhcpd.conf (5).

OMAPI

DHCP-сервер предоставляет возможность изменять некоторые параметры своей конфигурации пока он работает, не останавливая его, изменяя его файлы базы данных и перезапустите ее.Эта возможность в настоящее время предоставляется с использованием OMAPI — API для управления удаленные объекты. Клиенты OMAPI подключаются к серверу, используя TCP / IP, аутентифицируйте и затем можете проверить текущий статус сервера и внесите в него изменения.

Вместо прямая реализация базового протокола OMAPI, пользователь программы должны использовать dhcpctl API или сам OMAPI. Dhcpctl это обертка, которая выполняет некоторые домашние дела это OMAPI не делает автоматически. Dhcpctl и OMAPI являются задокументировано в dhcpctl (3) и omapi (3) .

OMAPI экспорт объекты, которые затем можно исследовать и изменять. DHCP сервер экспортирует следующие объекты: аренда, хост, отказоустойчивое состояние и группа. Каждый объект имеет ряд предоставленные методы: поиск, создание и уничтожение. В кроме того, можно посмотреть на атрибуты, которые хранятся на объектах, а в некоторых случаях для их изменения атрибуты.

ОБЪЕКТ АРЕНДЫ

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

Аренда имеет следующие атрибуты:

состояние целое число поиск, проверка

1 = свободен
2 = активен
3 = истек
4 = освобожден
5 = заброшен
6 = сброс
7 = резервный
8 = зарезервирован
9 = bootp

ip-адрес данные поиск, проверка

IP-адрес аренда.

идентификатор-клиента dhcp данные поиск, проверка, обновление

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

имя хоста клиента данные изучить, обновить

Значение, отправленное клиентом. параметр имени хоста.

хост ручка осмотреть

объявление хоста, связанное с этим договором аренды, если таковой имеется.

подсеть ручка осмотреть

связанный объект подсети с этой арендой (объект подсети в настоящее время не поддерживается).

бассейн ручка осмотреть

объект пула, связанный с эта аренда (объект пула в настоящее время не поддерживается).

биллинг-класс ручка осмотреть

дескриптор класса для по которому в настоящее время выставляется счет за аренду, если таковая имеется (класс объект в настоящее время не поддерживается).

аппаратный адрес данные изучить, обновить

аппаратный адрес (chaddr) поле, отправленное клиентом при получении аренды.

аппаратные целое число проверить, обновить

тип сети интерфейс, о котором клиент сообщил, когда получил аренда.

концы раз осмотреть

время, когда договор аренды текущее состояние заканчивается в понимании клиента.

tstp раз осмотреть

время, когда договор аренды текущее состояние заканчивается, как понимает сервер.

цфп время исследовать

настроенное время, когда текущее состояние аренды заканчивается, как это понимается одноранговый узел отработки отказа (если однорангового узла отработки отказа нет, это значение равно undefined).Обычно это значение корректируется только для истек, освобожден или сбросить аренду, пока сервер работает в состоянии отсутствия партнера, а в остальном просто значение, предоставленное партнером.

atsfp время исследовать

фактическое значение tsfp, отправленное из сверстник. Это значение забывается, когда состояние привязки аренды внесено изменение, чтобы облегчить логику повторной передачи.

cltt раз осмотреть

Время последнего сделка с клиентом по данной аренде.

ХОЗЯЙСТВЕННЫЙ ОБЪЕКТ

Хосты могут быть создано, уничтожено, просмотрено, исследовано и изменено. Если объявление хоста создается или удаляется с помощью OMAPI, что информация будет записана в файл dhcpd.leases. это разрешено удалять объявления хоста, объявленные в файл dhcpd.conf.

Хосты имеют следующие атрибуты:

наименование данные искать, изучать, изменять

имя хоста декларация. Это имя должно быть уникальным среди всех хостов декларации.

группа ручка осмотреть, доработать

названная группа, связанная с объявление хоста, если оно есть.

аппаратный адрес данные искать, изучать, изменять

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

аппаратные целое число поиск, проверка, изменение

тип сети интерфейс, который будет использоваться для сопоставления с клиентом, если таковой имеется.Действителен, только если также присутствует аппаратный адрес.

идентификатор-клиента dhcp данные искать, изучать, изменять

идентификатор-клиента dhcp вариант, который будет использоваться для сопоставления клиента, если таковой имеется.

ip-адрес данные изучить, изменить

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

ведомости данные изменить

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

известно целое число изучить, изменить

, если не ноль, означает, что клиент, соответствующий этому объявлению хоста, будет рассматриваться как известно в списках разрешений пула. Если ноль, клиент будет не считаться известными.

ОБЪЕКТ ГРУППЫ

Именованные группы могут быть созданы, уничтожены, найдены, исследованы и изменены.Если объявление группы создается или удаляется с помощью OMAPI, эта информация будет записана в файл dhcpd.leases. Допускается удаление групповых объявлений, которые объявлен в файле dhcpd.conf.

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

Группы имеют следующие атрибуты:

наименование данные

название группы.Все группы, созданные с помощью OMAPI, должны иметь имена, а имена должны быть уникальными среди всех групп.

ведомости данные

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

ОБЪЕКТ УПРАВЛЕНИЯ

Контроль объект позволяет выключить сервер. Если сервер выполняя аварийное переключение с другим партнером, это сделает чистую перейти в состояние выключения и уведомить своего партнера, поэтому что партнер может перейти в партнерство вниз, а затем записать состояние «восстановить» в файле аренды, чтобы сервер перезагружается, он автоматически повторно синхронизируется со своим коллегой.

При выключении сервер также попытается полностью отключить все OMAPI соединения. Если эти соединения не выходят из строя чисто через пять секунд они автоматически отключаются. Оно может занимает целых 25 секунд с начала процесс выключения до того момента, когда сервер фактически выходы.

Чтобы закрыть сервер выключен, откройте его объект управления и установите состояние атрибут 2.

ОБЪЕКТ ПОВЕРХНОСТНОГО СОСТОЯНИЯ

объект состояния аварийного переключения — это объект, который отслеживает состояние протокол аварийного переключения, поскольку он управляется для данного отказоустойчивый одноранговый узел.Объект аварийного переключения имеет следующее атрибуты (см. dhcpd.conf (5) для объяснения того, что означают эти атрибуты):

наименование данные изучить

Обозначает название одноранговые отношения аварийного переключения, как описано в файл dhcpd.conf сервера.

адрес партнера данные изучить

Указывает на аварийное переключение IP-адрес партнера.

местный адрес данные изучить

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

партнерский порт данные изучить

Указывает порт TCP, на котором партнер по аварийному переключению прослушивает протокол аварийного переключения соединения.

локальный порт данные изучить

Указывает порт TCP, на котором DHCP-сервер прослушивает протокол аварийного переключения соединения для этой пары аварийного переключения.

максимальное количество выдающихся обновлений целое число изучить

Указывает количество обновлений. которые могут быть выдающимися и непризнанными в любой момент время в этих отношениях переключения при отказе.

мкТ целое число изучить

Указывает максимальное количество клиентов время выполнения этих резервных отношений.

баланс нагрузки макс. Секунды целое число изучить

Указывает максимальное значение для поле secs в запросе клиента перед балансировкой нагрузки обошел.

баланс нагрузки hba данные изучить

Указывает на балансировку нагрузки массив хэш-корзины для этого отношения отработки отказа.

местное государственное целое число изучить, изменить

Указывает текущее состояние DHCP-сервер в этом отношении переключения при отказе. Возможно значения для состояния:

1 — запуск
2 — нормальный
3 — связь прервана
4 — партнер не работает
5 — потенциальный конфликт
6 — восстановление
7 — приостановлено
8 — завершено
9 — восстановление выполнено
10 — разрешение прервано
11 — конфликт завершен
254 — восстановить подождите

(Обратите внимание, что некоторые из вышеперечисленных значений изменились с DHCP 3.0.x.)

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

государство-партнер целое число изучить

Указывает текущее состояние партнер по аварийному переключению.

местная целое число изучить

Указывает время, в которое DHCP-сервер вошел в текущее состояние в этом аварийном переключении отношения.

партнеры целое число изучить

Указывает время, в которое отказоустойчивый партнер перешел в текущее состояние.

иерархия целое число изучить

Указывает, сервер является первичным (0) или вторичным (1) в этом аварийном переключении отношения.

отправлено последнего пакета целое число изучить

Указывает время, в которое последний пакет аварийного переключения был отправлен этим DHCP-сервером на его резервный партнер.

получена последняя отметка времени целое число изучить

Указывает метку времени, был в последнем сообщении аварийного переключения, полученном от отказоустойчивый партнер.

перекос целое число изучить

Указывает на перекос между часы партнера по отработке отказа и этого DHCP-сервера часы

максимальная задержка ответа целое число изучить

Указывает время в секундах после чего, если сообщение не получено от аварийного переключения партнер, предполагается, что партнер находится вне общение.

cur-unacked-updates целое число изучить

Указывает номер обновления сообщения, полученные от партнера по отработке отказа но еще не обработано.

ФАЙЛОВ

ETCDIR / dhcpd.conf, DBDIR / dhcpd.leases, RUNDIR / dhcpd.pid, DBDIR / dhcpd.leases ~.

СМОТРИ ТАКЖЕ

dhclient (8), dhcrelay (8), dhcpd.conf (5), dhcpd.leases (5)

АВТОР

dhcpd (8) изначально был написан Тедом Лимоном по контракту с Vixie Labs. Финансирование этого проекта было предоставлено Консорциум Интернет-систем. Версия 3 DHCP-сервера финансируется Nominum, Inc. Информация об Интернете Системный консорциум доступен по адресу https: // www.isc.org/ .

Общие сведения об агентах ретрансляции DHCP | NETMANIAS

I. Обзор

Этот документ обеспечивает техническое понимание агента ретрансляции DHCP, который требуется в среде с несколькими подсетями, где DHCP-клиент и DHCP-сервер находятся в разных подсетях. В главе II объясняется, почему эти агенты ретрансляции DHCP необходимы в операциях DHCP. В главе III описаны основные принципы работы DHCP с использованием агента ретрансляции DHCP. Наконец, в Приложении будут представлены конкретные параметры сообщений, используемые агентами ретрансляции DHCP в каждой процедуре DHCP.

Перед чтением этого документа рекомендуется ознакомиться с сопутствующими документами «Основные сведения об операциях DHCP» [2] и «Общие сведения о подробных операциях DHCP» [3].

II. Зачем нужны агенты ретрансляции DHCP для операций DHCP?

Как правило, рассылаются сообщения DHCP. Таким образом, для обмена сообщениями между DHCP-клиентом (ПК) и DHCP-сервером клиент и сервер должны находиться в одной подсети.Это связано с тем, что маршрутизаторы не пересылают широковещательные IP-пакеты (т.е. пакеты с MAC-адресом назначения FF: FF: FF: FF: FF: FF и IP-адресом назначения 255.255.255.255) на другие интерфейсы. Таким образом, широковещательный пакет DHCP, отправленный DHCP-клиентом, не может быть доставлен на DHCP-сервер (-ы) в другой (-е) подсети (-ах) через маршрутизатор (показан на рисунке 1 — (a)). Это ограничение требует, чтобы все отдельные подсети имели свой собственный DHCP-сервер для работы DHCP, что практически невозможно в сетях сетевых операторов или корпоративных компьютерных сетях (в сети требуется слишком много DHCP-серверов!).

Для решения этой проблемы давно принята концепция агента ретрансляции DHCP [1]. Как показано на рис. 1 — (b), включение функции агента ретрансляции DHCP в маршрутизаторе позволяет обмениваться сообщениями DHCP между клиентом DHCP и сервером DHCP, находящимся в разных подсетях. 1 Основная функция этого агента ретрансляции DHCP — преобразовать широковещательный пакет DHCP в одноадресный и пересылать его на сервер DHCP.

Рисунок 1. Сравнение операций DHCP в сетях с агентом ретрансляции DHCP и без него

III. Основные операции агентов DHCP-ретрансляции

В этой главе описывается, как ПК (например, ПК1) в подсети «1.1.1.0/24», как показано на Рисунке 1 — (b), может связываться с DHCP-сервером, используя агент ретрансляции DHCP для всех операций DHCP, таких как IP. выделение / аренда адреса, обновление IP-адреса и освобождение IP-адреса.

3.1 Процедура выделения / аренды IP-адреса

Агент DHCP-ретрансляции расположен между ПК и DHCP-сервером, как показано на рисунке 2. Агент DHCP-ретрансляции принимает сообщения DHCP Discover и Request, транслируемые ПК, и одноадресно отправляет их непосредственно на DHCP-сервер. На этом этапе агент ретрансляции DHCP сохраняет свой IP-адрес (адрес интерфейса, по которому он получил сообщения DHCP Discover / Request) в поле «IP-адрес агента ретрансляции (= IP шлюза = giaddr)» сообщения DHCP, которое будет ретранслироваться.

DHCP-сервер одноадресно отправляет сообщение DHCP Offer / Ack с IP-адресом назначения, установленным в качестве IP-адреса агента ретрансляции, агенту ретрансляции DHCP. Агент DHCP-ретрансляции после проверки поля «Broadcast Flag» полученного сообщения заменяет IP-адрес назначения на IP-адрес ПК (Broadcast Flag = 0) или широковещательный IP-адрес (Broadcast Flag = 1) в зависимости от значение «Broadcast Flag». Он также заменяет исходный IP-адрес IP-адресом агента ретрансляции DHCP и пересылает измененное сообщение на ПК.

Рис. 2. Процедура выделения / аренды IP-адреса в сети с агентом ретрансляции DHCP

1. DHCP Discover

Как описано в справочных материалах [2], «Понимание основных операций DHCP» и [3], «Понимание подробных операций DHCP», клиент DHCP передает сообщение DHCP Discover в физическую подсеть Ethernet для обнаружения всех DHCP. серверов, доступных в подсети.После получения пакетов, для которых порт назначения UDP установлен на 67 (обнаружение / запрос DHCP), агент ретрансляции DHCP заменяет значения в полях пакетов следующим образом, а затем одноадресно отправляет измененное сообщение на сервер DHCP:

  • MAC-адрес назначения: широковещательный MAC-адрес, отправленный ПК, заменяется MAC-адресом DHCP-сервера (m5).
  • MAC-адрес источника: MAC-адрес ПК (m1) заменяется MAC-адресом восходящего канала агента ретрансляции DHCP (m3).
  • IP-адрес назначения: широковещательный IP-адрес (255.255.255.255), отправленный ПК, заменяется IP-адресом DHCP-сервера (100.1.1.1).
  • IP-адрес источника: IP-адрес, отправленный ПК (0.0.0.0), заменяется IP-адресом восходящего канала агента ретрансляции DHCP (100.1.1.254).
  • IP-адрес агента ретрансляции: IP-адрес, отправленный ПК (0.0.0.0), заменяется IP-адресом нисходящего канала агента ретрансляции DHCP (1.1.1.254), IP-адресом интерфейса агента ретрансляции, на котором отправляется сообщение DHCP Discover. был получен.

2.Предложение DHCP

DHCP-сервер, ссылаясь на IP-адрес агента ретрансляции (giaddr) в сообщении DHCP Discover, выбирает IP-адрес для выделения DHCP-клиенту из IP-пула и отправляет сообщение DHCP Offer с IP-адресом назначения, установленным как IP-адрес агента ретрансляции 2 . Агент ретрансляции DHCP при получении сообщения заменяет значения в полях пакетов следующим образом, а затем отправляет измененное сообщение клиенту DHCP (ПК):

  • MAC-адрес назначения: если поле «Broadcast Flag» сообщения DHCP Offer, отправляемого DHCP-сервером, равно 0 (ноль), агент DHCP-ретрансляции заменяет значение в этом поле MAC-адресом ПК (поле Client MAC: m1 ) и одноадресная рассылка сообщения.Однако, если значение «Broadcast Flag» равно 1 (единица), агент ретрансляции заменяет его широковещательным MAC-адресом (FF: FF: FF: FF: FF: FF) и транслирует сообщение.
  • MAC-адрес источника: MAC-адрес DHCP-сервера (m5) заменяется MAC-адресом нисходящего канала агента ретрансляции DHCP (m2).
  • IP-адрес назначения: DHCP-сервер отправляет сообщение DHCP Offer с адресом назначения, установленным в качестве IP-адреса агента ретрансляции в сообщении DHCP Discover (1.1.1.254), агенту ретрансляции DHCP.Если значение «Broadcast Flag» в сообщении равно 0, агент ретрансляции заменяет это значение IP-адресом, назначенным ПК (поле Your IP: 1.1.1.10) для одноадресной рассылки. Однако, если значение «Broadcast Flag» равно 1, агент ретрансляции заменяет его широковещательным IP-адресом (255.255.255.255) для широковещательной передачи.
  • IP-адрес источника: IP-адрес DHCP-сервера (100.1.1.1) заменяется IP-адресом нисходящего канала агента ретрансляции DHCP (1.1.1.254).

3. Запрос DHCP

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

  • MAC-адрес назначения: широковещательный MAC-адрес, отправленный ПК, заменяется MAC-адресом DHCP-сервера (m5).
  • MAC-адрес источника: MAC-адрес ПК (m1) заменяется MAC-адресом восходящего канала агента ретрансляции DHCP (m3).
  • IP-адрес назначения: широковещательный IP-адрес (255.255.255.255), отправленный ПК, заменяется IP-адресом DHCP-сервера (100.1.1.1).
  • IP-адрес источника: IP-адрес, отправленный ПК (0.0.0.0), заменяется IP-адресом восходящего канала агента ретрансляции DHCP (100.1.1.254)
  • IP-адрес агента ретрансляции: IP-адрес, отправленный ПК (0.0.0.0), заменяется IP-адресом нисходящего канала агента ретрансляции DHCP (1.1.1.254), IP-адресом интерфейса агента ретрансляции, на котором отправляется сообщение DHCP Discover. был получен.

4.DHCP Ack

Сервер DHCP отправляет сообщение DHCP Ack с IP-адресом назначения, установленным в качестве IP-адреса агента ретрансляции (giaddr) 3 . Агент ретрансляции DHCP, получив это сообщение, заменяет значения в полях пакетов следующим образом, а затем одноадресно передает сообщение DHCP-клиенту (ПК):

  • MAC-адрес назначения: если поле «Broadcast Flag» сообщения DHCP Ack, отправляемого DHCP-сервером, равно 0 (ноль), агент DHCP-ретрансляции заменяет значение в этом поле MAC-адресом ПК (поле Client MAC: m1 ) и одноадресная рассылка сообщения.Однако, если значение «Broadcast Flag» равно 1 (единица), агент ретрансляции заменяет его широковещательным MAC-адресом (FF: FF: FF: FF: FF: FF) и транслирует сообщение.
  • MAC-адрес источника: MAC-адрес DHCP-сервера (m5) заменяется MAC-адресом нисходящего канала агента ретрансляции DHCP (m2).
  • IP-адрес назначения: DHCP-сервер отправляет сообщение DHCP Ack с адресом назначения, установленным в качестве IP-адреса агента ретрансляции в сообщении запроса DHCP (1.1.1.254), агенту ретрансляции DHCP.Если значение «Broadcast Flag» в сообщении равно 0, агент ретрансляции заменяет это значение IP-адресом, назначенным ПК (поле Your IP: 1.1.1.10) для одноадресной рассылки. Однако, если значение «Broadcast Flag» равно 1, агент ретрансляции заменяет его широковещательным IP-адресом (255.255.255.255) для широковещательной передачи.
  • IP-адрес источника: IP-адрес DHCP-сервера (100.1.1.1) заменяется IP-адресом нисходящего канала агента ретрансляции DHCP (1.1.1.254).

3.2 Процедура обновления IP-адреса

Согласно ссылке [1], DHCP-клиент (ПК) сохраняет / сохраняет IP-адрес DHCP-сервера, полученный посредством сообщения DHCP Ack (в поле идентификатора DHCP-сервера) во время процедуры выделения IP-адреса.Затем, если ему необходимо использовать IP-адрес по истечении срока аренды, он отправляет сообщение DHCP-запроса на DHCP-сервер через одноадресную, а не широковещательную рассылку. И сервер DHCP, в ответ на сообщение, одноадресно отправляет сообщение DHCP Ack клиенту DHCP.

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

Рисунок 3. Процедура обновления IP-адреса в сети с помощью агента ретрансляции DHCP

1. Запрос DHCP

DHCP-клиент (ПК) одноадресно отправляет сообщение DHCP-запроса с IP-адресом назначения, установленным как IP-адрес DHCP-сервера. Таким образом, агент ретрансляции DHCP не получает это сообщение. Другими словами, ни одно поле сообщения DHCP-запроса не заменяется агентом ретрансляции DHCP во время процедуры обновления IP-адреса.

2. DHCP Ack

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

3.3 Процедура освобождения IP-адреса

Согласно ссылке [1], RFC 1542, когда IP-адрес высвобождается, DHCP-клиент (ПК) напрямую передает сообщение DHCP Release DHCP-серверу.Таким образом, агент ретрансляции DHCP не участвует в процедуре освобождения IP-адреса, как показано на рисунке 4.

Рис. 4. Процедура освобождения IP-адреса в сети с помощью агента ретрансляции DHCP

1. Версия DHCP

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

Ссылки

[1] W. Wimer, «Разъяснения и расширения для протокола начальной загрузки», RFC 1542, Standard, октябрь 1993 г.

[2] Технический документ Netmanias, «Понимание основных операций DHCP», октябрь 2013 г.

[3] Технический документ Netmanias, «Подробное понимание операций DHCP», октябрь 2013 г.

Сноски

1 Обычно маршрутизаторы и коммутаторы L3 поддерживают все функции агента ретрансляции DHCP.

2 Если IP-адрес агента DHCP-ретрансляции не установлен как «0.0.0.0», DHCP-сервер всегда одноадресно рассылает сообщение DHCP Offer агенту DHCP-ретрансляции независимо от значения флага широковещательной рассылки.

3 Если IP-адрес агента DHCP-ретрансляции не установлен как «0.0.0.0», DHCP-сервер всегда отправляет сообщение DHCP Ack агенту DHCP-ретрансляции независимо от значения флага широковещательной рассылки.

Приложение — Формат сообщений DHCP в сети с агентами ретрансляции DHCP

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

Сообщение DHCP Discover

Рисунок 5 . Сообщение DHCP Discover в процедуре выделения / аренды IP-адреса

Заголовок Ethernet

  • MAC-адрес назначения : MAC-адрес широковещательной передачи (0xFFFFFFFFFFFF) заменяется MAC-адресом DHCP-сервера (m5).