Сети ЭВМ и телекоммуникации DHCP DHCP (Dynamic Host Configuration Protocol — протокол динамической конфигурации узла) — это сетевой протокол, позволяющий компьютерам автоматически получать IP-адрес и другие параметры, необходимые для работы в сети TCP/IP. • Данный протокол работает по модели «клиент-сервер». Для автоматической конфигурации компьютер-клиент на этапе конфигурации сетевого устройства обращается к серверу DHCP, и получает от него нужные параметры. • Сетевой администратор может задать диапазон адресов, распределяемых сервером среди компьютеров. • Протокол позволяет избежать ручной настройки компьютеров сети и уменьшает количество ошибок. • DHCP используется в большинстве крупных (и не очень) сетей TCP/IP. История DHCP Стандарт протокола DHCP был принят в октябре 1993 года. Действующая версия протокола (март 1997 года) описана в RFC 2131. Новая версия DHCP, предназначенная для использования в среде IPv6, носит название DHCPv6 и определена в RFC 3315 (июль 2003 года). Распределение IP-адресов • Протокол DHCP предоставляет три способа распределения IP-адресов: – Ручное распределение – администратор сопоставляет аппаратному адресу (для Ethernet сетей это MAC-адрес) каждого клиентского компьютера определённый IP-адрес. – Автоматическое распределение – каждому компьютеру на постоянное использование выделяется произвольный свободный. IP-адрес из определённого администратором диапазона. – Динамическое распределение – способ аналогичен автоматическому распределению, за исключением того, что адрес выдаётся компьютеру не на постоянное пользование, а на определённый срок. Это называется арендой адреса. По истечении срока аренды IP-адрес вновь считается свободным. • Некоторые реализации службы DHCP способны автоматически обновлять записи DNS, соответствующие клиентским компьютерам, при выделении им новых адресов. Опции DHCP • Помимо IP-адреса, DHCP также может сообщать клиенту дополнительные параметры, необходимые для нормальной работы в сети. • Список стандартных опций можно найти в RFC 2132. • Наиболее часто используемые опции: – – – – – IP-адрес хоста клиента; IP-адрес маршрутизатора по умолчанию; маска подсети; адреса серверов DNS; имя домена DNS. • Некоторые поставщики программного обеспечения могут определять собственные, дополнительные опции DHCP. Описание протокола • Протокол DHCP является клиентсерверным, то есть в его работе участвуют клиент DHCP и сервер DHCP. • Передача данных производится при помощи протокола UDP, при этом сервер принимает сообщения от клиентов на порт 67 и отправляет сообщения клиентам на порт 68. Структура сообщений DHCP • Сообщение протокола DHCP разбивается на поля, каждое из которых содержит определённую информацию. • Все поля, кроме последнего (поля опций DHCP), имеют фиксированную длину. Поля опций DHCP Поле op htype hlen hops xid secs flags ciaddr yiaddr siaddr giaddr chaddr sname file options Описание Длина (в байтах) Тип сообщения. Может принимать два значения: BOOTREQUEST (1 - запрос от клиента к серверу) 1 и BOOTREPLY (2 - ответ от сервера к клиенту). Тип аппаратного адреса. Допустимые значения этого поля определены в RFC «Assigned 1 Numbers». Например, для MAC-адреса Ethernet 10 Мбит/с это поле принимает значение 1. Длина аппаратного адреса в байтах. Для MAC-адреса Ethernet — 6. 1 Количество промежуточных маршрутизаторов (так называемых агентов ретрансляции DHCP), 1 через которые прошло сообщение. Клиент устанавливает это поле в 0. Уникальный идентификатор транзакции, генерируемый клиентом в начале процесса получения 4 адреса. Время в секундах с момента начала процесса получения адреса. Может не использоваться (в 2 этом случае оно устанавливается в 0). Поле для флагов — специальных параметров протокола DHCP. 2 IP-адрес клиента. Заполняется только в том случае, если клиент уже имеет собственный IP-адрес и способен отвечать на запросы ARP (это возможно, если клиент выполняет процедуру 4 обновления адреса по истечении срока аренды). Новый IP-адрес клиента, предложенный сервером. 4 IP-адрес сервера. Возвращается в предложении DHCP. 4 IP-адрес агента ретрансляции, если таковой участвовал в процессе доставки сообщения DHCP до 4 сервера. Аппаратный адрес (обычно MAC-адрес) клиента. 16 Необязательное имя сервера в виде нуль-терминированной строки. 64 Необязательное имя файла на сервере, используемое бездисковыми рабочими станциями при 128 удалённой загрузке. Как и sname, представлено в виде нуль-терминированной строки. Поле опций DHCP. Здесь указываются различные дополнительные параметры конфигурации. В начале этого поля указываются четыре особых байта со значениями 99, 130, 83, 99 («волшебные числа»), позволяющие серверу определить наличие этого поля. Поле имеет переменную длину, переменная однако DHCP-клиент должен быть готов принять DHCP-сообщение длиной в 576 байт (в этом сообщении поле options имеет длину 340 байт). Пример процесса получения адреса • Предположим, клиент ещё не имеет собственного IP-адреса, но ему известен его предыдущий адрес — 192.168.1.100. • Процесс состоит из четырёх этапов: – Обнаружение DHCP; – Предложение DHCP; – Запрос DHCP; – Подтверждение DHCP. Обнаружение DHCP • Вначале клиент выполняет широковещательный запрос по всей физической сети с целью обнаружить доступные DHCP-серверы. Он отправляет сообщение типа DHCPDISCOVER, при этом в качестве IPадреса источника указывается 0.0.0.0 (так как компьютер ещё не имеет собственного IP-адреса), а в качестве адреса назначения — широковещательный адрес 255.255.255.255. • Клиент заполняет несколько полей сообщения начальными значениями: – В поле xid помещается уникальный идентификатор транзакции, который позволяет отличать данный процесс получения IP-адреса от других, протекающих в то же время. – В поле chaddr помещается аппаратный адрес (MAC-адрес) клиента. – В поле опций указывается последний известный клиенту IP-адрес. В данном примере это 192.168.1.100. Это необязательно и может быть проигнорировано сервером. • Сообщение DHCPDISCOVER может быть распространено за пределы локальной физической сети при помощи специально настроенных агентов ретрансляции DHCP, перенаправляющих поступающие от клиентов сообщения DHCP серверам в других подсетях. Предложение DHCP • Получив сообщение от клиента, сервер определяет требуемую конфигурацию клиента в соответствии с указанными сетевым администратором настройками. • В данном случае DHCP-сервер согласен с запрошенным клиентом адресом 192.168.1.100. Сервер отправляет ему ответ (DHCPOFFER), в котором предлагает конфигурацию. • Предлагаемый клиенту IP-адрес указывается в поле yiaddr. • Прочие параметры (такие, как адреса маршрутизаторов и DNSсерверов) указываются в виде опций в соответствующем поле. • Это сообщение DHCP-сервер отправляет хосту, пославшему DHCPDISCOVER, на его MAC. • Клиент может получить несколько различных предложений DHCP от разных серверов; из них он должен выбрать то, которое его «устраивает». Запрос DHCP • Выбрав одну из конфигураций, предложенных DHCP-серверами, клиент отправляет запрос DHCP (DHCPREQUEST). • Запрос рассылается широковещательно, при этом к опциям, указанным клиентом в сообщении DHCPDISCOVER, добавляется специальная опция: • идентификатор сервера — указывающая адрес DHCPсервера, выбранного клиентом (в данном случае — 192.168.1.1). Подтверждение DHCP • Сервер подтверждает запрос и направляет это подтверждение (DHCPACK) клиенту. • После этого клиент должен настроить свой сетевой интерфейс, используя предоставленные опции. Прочие сообщения DHCP • • • • Отказ DHCP Если после получения подтверждения (DHCPACK) от сервера клиент обнаруживает, что указанный сервером адрес уже используется в сети, он рассылает широковещательное сообщение отказа DHCP (DHCPDECLINE), после чего процедура получения IP-адреса повторяется. Использование IP-адреса другим клиентом можно обнаружить, выполнив запрос ARP. Отмена DHCP Если по каким-то причинам сервер не может предоставить клиенту запрошенный IP-адрес, или если аренда адреса удаляется администратором, сервер рассылает широковещательное сообщение отмены DHCP (DHCPNAK). При получении такого сообщения соответствующий клиент должен повторить процедуру получения адреса. Освобождение DHCP Клиент может явным образом прекратить аренду IP-адреса. Для этого он отправляет сообщение освобождения DHCP (DHCPRELEASE) тому серверу, который предоставил ему адрес в аренду. В отличие от других сообщений DHCP, DHCPRELEASE не рассылается широковещательно. Информация DHCP Сообщение информации DHCP (DHCPINFORM) предназначено для определения дополнительных параметров TCP/IP (например, адреса маршрутизатора по умолчанию, DNS-серверов и т. п.) теми клиентами, которым не нужен динамический IP-адрес (то есть адрес которых настроен вручную). Серверы отвечают на такой запрос сообщением подтверждения (DHCPACK) без выделения IP-адреса. ARP • ARP (Address Resolution Protocol — протокол определения адреса) — протокол предназначен для определения адреса канального уровня по известному адресу сетевого уровня. • Протокол низкого уровня. • Наибольшее распространение этот протокол получил благодаря повсеместности сетей IP, построенных поверх Ethernet, поскольку практически в 100 % случаев при таком сочетании используется ARP. Описание ARP • Описание протокола было опубликовано в ноябре 1982 года в RFC 826. • ARP был спроектирован для случая передачи IP-пакетов через сегмент Ethernet. Общий принцип, предложенный для ARP, был использован для сетей других типов. • Существуют следующие типы сообщений ARP: – запрос ARP (ARP request) – ответ ARP (ARP reply). • Перед тем как передать пакет сетевого уровня через сегмент Ethernet, сетевой стек проверяет кэш ARP, чтобы выяснить, не зарегистрирована ли в нём уже нужная информация об узле-получателе. Если такой записи в кэше ARP нет, то выполняется широковещательный запрос ARP. • Записи в кэше ARP могут быть статическими и динамическими. • Пример добавления статической записи: • arp -s <IP-адрес> <MAC-адрес> Записи в таблице ARP, созданные динамически, остаются в кэше в течение 2-х минут. Если в течение этих двух минут произошла повторная передача данных по этому адресу, то время хранения записи в кэше продлевается ещё на 2 минуты. Эта процедура может повторяться до тех пор, пока запись в кэше просуществует до 10 минут. После этого запись будет удалена из кэша, и будет отправлен повторный запрос ARP. Принцип работы • Узел, которому нужно выполнить отображение IPадреса на локальный адрес, формирует ARP запрос, вкладывает его в кадр протокола канального уровня, указывая в нем известный IP-адрес, и рассылает запрос широковещательно. • Все узлы локальной сети получают ARP запрос и сравнивают указанный там IP-адрес с собственным. • В случае их совпадения узел формирует ARP-ответ, в котором указывает свой IP-адрес и свой локальный адрес и отправляет его уже направленно, так как в ARP запросе отправитель указывает свой локальный адрес. Структура пакета • Hardware type (HTYPE) Каждый транспортный протокол передачи данных имеет свой номер, который хранится в этом поле. Например, Ethernet имеет номер 0x0001. • Protocol type (PTYPE) Код протокола. Например, для IPv4 будет записано 0x0800. • Hardware length (HLEN) Длина физического адреса в байтах. Ethernet адреса имеют длину 6 байт. • Protocol length (PLEN) Длина логического адреса в байтах. IPv4 адреса имеют длину 4 байта. • Operation Код операции отправителя: 1 в случае запроса и 2 в случае ответа. • Sender hardware address (SHA) Физический адрес отправителя. • Sender protocol address (SPA) Логический адрес отправителя. • Target hardware address (THA) Физический адрес получателя. Поле пусто при запросе. • Target protocol address (TPA) Логический адрес получателя. Пример + 0 32 Bits 0 — 7 8 — 15 16 — 31 Hardware type = 0x0001 Hardware length = 6 64 Protocol type = 0x0800 Protocol length = 4 Operation = 1 SHA (first 32 bits) = 0x000958D8 96 SHA (last 16 bits) = 0x1122 SPA (first 16 bits) = 0x0A0A 128 SPA (last 16 bits) = 0x0A7B THA (first 16 bits) = 0x0000 160 THA (last 32 bits) = 0x00000000 192 TPA = 0x0A0A0A8C + 0 32 64 Bits 0 — 7 8 — 15 16 — 31 Hardware type = 0x0001 Hardware length = 6 Protocol type = 0x0800 Protocol length = 4 Operation = 2 SHA (first 32 bits) = 0x000958D8 96 SHA (last 16 bits) = 0x33AA SPA (first 16 bits) = 0x0A0A 128 SPA (last 16 bits) = 0x0A8C THA (first 16 bits) = 0x0009 160 THA (last 32 bits) = 0x58D81122 192 TPA = 0x0A0A0A7B RARP • RARP (Reverse Address Resolution Protocol — Обратный протокол преобразования адресов) — протокол сетевого уровня, выполняет обратное отображение адресов, то есть преобразует аппаратный адрес в IP-адрес. • Протокол применяется во время загрузки узла . • Например: – компьютер при инициализации интерфейса посылает групповое сообщение-запрос со своим физическим адресом. – Сервер принимает это сообщение и просматривает свои таблицы в поисках соответствующего физическому, IP-адреса. – После обнаружения найденный адрес отсылается обратно на запросивший его узел. – Другие станции также могут «слышать» этот диалог и локально сохранить эту информацию в своих ARP-таблицах. • RARP позволяет разделять IP-адреса между не часто используемыми хост-узлами. После использования каким либо узлом IP-адреса он может быть освобождён и выдан другому узлу. • RARP является дополнением к ARP, и описан в RFC 903. ICMP • ICMP (Internet Control Message Protocol — протокол межсетевых управляющих сообщений) — сетевой протокол, входящий в стек протоколов TCP/IP. • ICMP используется для передачи сообщений об ошибках и других исключительных ситуациях, возникших при передаче данных. • Например, запрашиваемая услуга недоступна, или хост, или маршрутизатор не отвечают. • Также на ICMP возлагаются некоторые сервисные функции. ICMP • Протокол ICMP описан в RFC 792 и RFC 950, является стандартом Интернета. • Формально ICMP использует IP (ICMP-пакеты инкапсулируются в IP пакеты), и является неотъемлемой частью IP, следовательно обязателен при реализации стека TCP/IP. • Текущая версия ICMP для IPv4 называется ICMPv4. В IPv6 существует аналогичный протокол ICMPv6. • ICMP-сообщение строится из IP-пакетов, сгенерировавших ICMP-ответ. • Каждое ICMP-сообщение инкапсулируется непосредственно в пределах одного IP-пакета, и, таким образом, как и UDP, ICMP является ненадежным. • ICMP не используется непосредственно в приложениях пользователей сети. Использование ICMP-сообщений • ICMP-сообщения (тип 12) генерируются при нахождении ошибок в заголовке IP-пакета (за исключением самих ICMP-пакетов, чтобы не привести к бесконечно растущему потоку ICMP-сообщений об ICMPсообщениях). • ICMP-сообщения (тип 3) генерируются маршрутизатором при отсутствии маршрута к адресату. • Утилита Ping, служащая для проверки возможности доставки IP-пакетов использует ICMP-сообщения с типом 8 (эхо-запрос) и 0 (эхо-ответ). • Утилита Traceroute, отображающая путь следования IP-пакетов, использует ICMP-сообщения с типом 11. • ICMP-сообщения (тип 5) используются маршрутизаторами для обновления записей в таблице маршрутизации отправителя. • ICMP-сообщения (тип 4) используются получателем (или маршрутизатором) для управления скоростью отправки сообщений отправителем. Формат пакета ICMP Бит 0—7 8—15 16—31 0 Тип Код Контрольная сумма 32 Содержание сообщения (зависит от значений полей «Код» и «Тип») Типы пакетов ICMP • • • • • 0 — Эхо-ответ 1 — Зарезервировано 2 — Зарезервировано 3 — Адресат недоступен – код 0 — Сеть недостижима код 1 — Узел недостижим код 2 — Протокол недостижим код 3 — Порт недостижим код 4 — Необходима фрагментация, но установлен флаг ее запрета (DF) код 5 — Неверный маршрут от источника код 6 — Сеть назначения неизвестна код 7 — Узел назначения неизвестен код 8 — Узел источник изолирован код 9 — Сеть административно запрещена код 10 — Узел административно запрещен код 11 — Сеть недоступна для ToS код 12 — Узел недоступен для ToS код 13 — Коммуникации административно запрещены код 14 — Нарушение порядка предпочтения узлов код 15 — Активно отсечение порядка предпочтения 4 — Сдерживание источника (отключение источника при переполнении очереди) • 5 — Перенаправление – код 0 — Перенаправление пакетов в сеть Код 1 — Перенаправление пакетов к узлу Код 2 — Перенаправление для каждого типа обслуживания (TOS) Код 3 — Перенаправление пакета к узлу для каждого типа обслуживания • • • • 6 — Альтернативный адрес узла 7 — Зарезервировано 8 — Эхо-запрос 9 — Объявление маршрутизатора (RFC-1256) – код 0 — Нормальное объявление маршрутизатора код 16 — Не маршрутизировать обычный трафик • • 10 — Запрос маршрутизатора (RFC-1256) 11 — Превышение временного интервала (для дейтаграммы время жизни истекло) – код 0 — Время жизни пакета (TTL) истекло при транспортировке код 1 — Время жизни пакета (время сборки фрагментов) истекло при дефрагментации Типы пакетов ICMP • • • • • • • • • • • • • • • 12 — Неверный параметр (проблема с параметрами • дейтаграммы: ошибка в IP-заголовке или отсутствует необходимая опция) • – код 0 — Указатель говорит об ошибке код 1 — Отсутствует требуемая опция • код 2 — Некорректная длина • 13 — Запрос метки времени • 14 — Ответ с меткой времени 15 — Информационный запрос 16 — Информационный ответ 17 — Запрос адресной маски (RFC-950) 18 — Отклик на запрос адресной маски (RFC-950) 19 — Зарезервировано (для обеспечения безопасности) 20-29 — Зарезервировано (для экспериментов на устойчивость к ошибкам) 30 — Трассировка маршрута (RFC-1393) 31 — Ошибка преобразования дейтаграммы (RFC1475) 32 — Перенаправление для мобильного узла 33 — IPv6 Where-Are-You (где вы находитесь) • 34 — IPv6 I-Am-Here (я здесь) 35 — Запрос перенаправления для мобильного узла 36 — Отклик на запрос перенаправления для мобильного узла 37 — Запрос доменного имени (Domain Name Request) 38 — Ответ на запрос доменного имени (Domain Name Reply) 39 — SKIP 40 — Photuris – код 0 — Зарезервировано код 1 — Неизвестный индекс параметров безопасности (Unkown Security Parameters Index) код 2 — Параметры безопасности верны, но произошла ошибка аутентификации (Valid Security Parameters, but Authentication Failed) код 3 — Параметры безопасности верны, но произошел сбой при расшифровке (Valid Security Parameters, but Decryption Failed) код 4 — Требуется проверка подлинности (Need Authentication) код 5 — Требуется авторизация (Need Authorization) 41-255 — Зарезервировано Пример • Эхо сообщение о недостижимости адресата содержит следующие поля: – Заголовок (4 байта): тип – 3; возможные коды – [0,15]; контрольная сумма ; – Пустое поле 32 бита; – Данные исходной диаграммы (первые 64 бита). Сообщение о перенаправлении дейтаграммы • Сообщение посылается шлюзом, при условии существования более короткого маршрута. • Формат сообщения: – Заголовок (4 байта): тип – 5; возможные коды – [0,5]; контрольная сумма; – Адрес более выгодного шлюза (4 байта); – Данные исходной дейтограммы (первые 64 бита). При муршрутизации от источника данное сообщение никогда не высылается. Сообщение эхо-запрос и эхо-ответ • Используется для тестирования соединения между узлами сети. • Сообщение запроса и ответа имеют одинаковый формат дейтограммы: – Заголовок (4 байта): • Тип (Эхо-запрос – 8, Эхо-ответ – 0); • Код не используется; • Контрольная сумма; – Идентификатор; – Последовательный номер; – Данные – имеет переменную длину. • Идентификатор и последовательный номер используются для определения соответствия эхо-запросов в эхо-ответы. Обмен информацией о маршрутах • Такие пакеты используются маршрутизаторами (один раз в 10 мин), передаются широковещательно. • Формат сообщения объявление маршрутизатора: – Заголовок (4 байта): Тип – 9; Код; Контрольная сумма; – Число адресов – количество адресов машрутизатора, указанных в сообщении (байт); – Длина адреса – число 32-битных слов, необходимых для указания записи каждого маршрутизатора (байт); – Время жизни – максимальное время выраженное в секундах, в течении которого адреса маршрутизатора могут считываться (2 байта); – Адрес маршрутизатора – ip-адрес интерфейса маршрутизатора (4 байта для ipv4); – Уровень приоритета – предпочтительность для каждого маршрута (4 байта для ipv4). ICMP-сообщение «запрос-маршрутизатора» • Передается при включении маршрутизатора и необходимости немедленного получения информации о соседних маршрутизаторах. • Формат сообщения: – Заголовок: Тип – 10; Код; Контрольная сумма; – 32 бита нулей.