1.9.Протоколы управления : icmp, arp/rarp, dhcp, bootp

Управляющие протоколы Интернета Помимо протокола IP, используемого для передачи данных, в Интернете есть не- сколько управляющих протоколов, применяемых на сетевом уровне, к которым относятся ICMP, ARP, RARP, ВООТР и DHCP. В данном разделе мы рассмот- рим их все по очереди. ICMP — протокол управляющих сообщений Интернета За работой Интернета следят маршрутизаторы. Когда случается что-то неожи- данное, о происшествии сообщается по протоколу ICMP (Internet Control Message Protocol — протокол управляющих сообщений Интернета), используе- мому также для тестирования Интернета. Протоколом ICMP определено около дюжины типов сообщений. Наиболее важные из них приведены в табл. 5.8. Каж- дое ICMP-сообщение вкладывается в IP-пакет.

Сообщение АДРЕСАТ НЕДОСТУПЕН используется, когда подсеть или маршрутиза- тор не могут обнаружить пункт назначения или когда пакет с битом DF (не фраг- ментировать) не может быть доставлен, так как путь ему преграждает сеть с ма- леньким размером пакетов. Сообщение ВРЕМЯ ИСТЕКЛО посылается, когда пакет игнорируется, так как его счетчик уменьшился до нуля. Это событие является признаком того, что пакеты двигаются по замкнутым контурам, что имеется большая перегрузка или уста- новлено слишком низкое значение таймера. Сообщение ПРОБЛЕМА ПАРАМЕТРА указывает на то, что обнаружено неверное зна- чение в поле заголовка. Это является признаком наличия ошибки в программ- ном обеспечении хоста, отправившего этот пакет, или промежуточного маршру- тизатора. Сообщение ГАШЕНИЕ ИСТОЧНИКА ранее использовалось для усмирения хостов, ко- торые отправляли слишком много пакетов. Хост, получивший такое сообщение, должен был снизить обороты. В настоящее время подобное сообщение редко ис- пользуется, так как при возникновении перегрузки подобные пакеты только под- ливают масла в огонь, еще больше загружая сеть. Теперь борьба с перегрузкой в Интернете осуществляется в основном на транспортном уровне. Это будет под- робно обсуждаться в главе 6. Сообщение ПЕРЕАДРЕСОВАТЬ посылается хосту, отправившему пакет, когда мар- шрутизатор замечает, что пакет адресован неверно. Сообщения ЗАПРОС ОТКЛИКА и ОТКЛИК посылаются, чтобы определить, достижим ли и жив ли конкретный адресат. Получив сообщение ЗАПРОС ОТКЛИКА, хост дол- жен отправить обратно сообщение ОТКЛИК. Сообщения ЗАПРОС ВРЕМЕННОГО ШТАМПА и ОТКЛИК С ВРЕМЕННЫМ ШТАМПОМ имеют то же назначение, но при этом в ответе простав- ляется время получения сообщения и время отправления ответа. Это сообщение используется для измерения производительности сети. Кроме перечисленных сообщений, определены и другие. Их полный список хранится в Интернете по адресу www.iana.org/assignments/icmp-parameters. ARP — протокол разрешения адресов Хотя у каждой машины в Интернете есть один (или более) IP-адресов, они не мо- гут использоваться для отправки пакетов, так как аппаратура уровня передачи данных не понимает интернет-адресов. В настоящее время большинство хостов соединены с локальными сетями с помощью интерфейсных карт, понимающих только адреса данной локальной сети. Например, каждая когда-либо выпущен- ная сетевая карта Ethernet имеет 48-разрядный Ethernet-адрес. Производители сетевых карт Ethernet запрашивают у центра блок адресов, что гарантирует уни- кальность Ethernet-адресов (это позволяет избежать конфликтов при наличии одинаковых сетевых карт в одной ЛВС). Сетевые карты отправляют и принима- ют кадры, основываясь на 48-разрядных Ethernet-адресах. О 32-разрядных IP-ад- ресах им ничего не известно. Таким образом, возникает вопрос: как устанавливается соответствие IP-адре- сов и адресов уровня передачи данных, таких как Ethernet-адреса? Чтобы по- нять, как это работает, рассмотрим показанный на рис. 5.53 пример, в котором изображен небольшой университет с несколькими сетями класса С (ныне называ- емыми сетями класса /24). На рисунке мы видим две сети Ethernet: одна на фа- культете кибернетики с IP-адресом 192.31.65.0, а другая — с IP-адресом 192.31.63.0 на электротехническом факультете. Они соединены кольцом FDDI с IP-адресом 192.31.60.0. У каждой машины сетей Ethernet есть уникальный Ethernet-адрес (на рисунке — от Е\ до Ј6), а у каждой машины кольца FDDI есть FDDI-адрес (от Я до Щ. Рассмотрим, как пользователь хоста 1 посылает пакет пользователю хоста 2. Допустим, отправителю известно имя получателя, например, [e-mail]. Сначала надо найти IP-адрес для хоста 2, известного как eagle.cs.uni.edu. Этот поиск осуществляется службой имен доменов DNS (Domain Name System), кото- рую мы рассмотрим в главе 7. На данный момент мы просто предположим, что служба DNS возвращает IP-адрес для хоста 2 (192.31.65.5). Теперь программное обеспечение верхнего уровня хоста 1 создает пакет со значением 192.31.65.5 в поле Адрес получателя и передает его IP-программе для пересылки. Программное обеспечение протокола IP может посмотреть на адрес и увидеть, что адресат находится в его собственной сети, но ему нужно как-то определить Ethernet-адрес получателя. Одно из решений состоит в том, чтобы хранить в системе конфигурационный файл, в котором были бы перечислены соответствия всех локальных IP-адресов Ethernet-адресам. Такое решение, ко- нечно, возможно, но в организациях с тысячами машин обновление этих файлов потребует много времени и подвержено ошибкам.

Более удачное решение заключается в рассылке хостом 1 по сети Ethernet ши- роковещательного пакета с вопросом: «Кому принадлежит IP-адрес 192.31.65.5?» Этот пакет будет получен каждой машиной сети Ethernet 192.31.65.0, а хост 2 от- ветит на вопрос своим Ethernet-адресом Е2. Таким образом, хост 1 узнает, что IP-адрес 192.31.65.5 принадлежит хосту с Ethernet-адресом Е2. Протокол, кото- рый задает подобный вопрос и получает ответ на него, называется ARP (Address Resolution Protocol — протокол разрешения адресов) и описан в RFC 826. Он ра- ботает почти на каждой машине в Интернете. Преимущество протокола ARP над файлами конфигурации заключается в его простоте. Системный администратор должен всего лишь назначить каждой ма- шине IP-адрес и решить вопрос с маской подсети. Все остальное сделает прото- кол ARP. Затем программное обеспечение протокола IP хоста 1 создает Ethernet-кадр для Ј2, помещает в его поле полезной нагрузки IP-пакет, адресованный 192.31.65.5, и посылает его по сети Ethernet. Сетевая карта Ethernet хоста 2 обнаруживает кадр, замечает, что он адресован ей, считывает его и вызывает прерывание. Ethernet-драйвер извлекает IP-пакет из поля полезной нагрузки и передает его IP-программе, которая, видя, что пакет адресован правильно, обрабатывает его. Существуют различные методы повышения эффективности протокола ARP. Во-первых, машина, на которой работает протокол ARP, может запоминать ре- зультат преобразования адреса на случай, если ей придется снова связываться с той же машиной. В следующий раз она найдет нужный адрес в своем кэше, сэко- номив, таким образом, на рассылке широковещательного пакета. Скорее всего, хосту 2 понадобится отослать ответ на пакет, что также потребует от него обра- щения к ARP для определения адреса отправителя. Этого обращения можно из- бежать, если отправитель включит в ARP-пакет свои IP- и Ethernet-адреса. Ко- гда широковещательный ARP-пакет прибудет на хост 2, пара (192.31.65.7, Ј1) будет сохранена хостом 2 в ARP-кэше для будущего использования. Более того, эту пару адресов могут сохранить у себя все машины сети Ethernet. Кроме того, каждая машина может рассылать свою пару адресов во время за- грузки. Обычно эта широковещательная рассылка производится в виде ARP-na- кета, запрашивающего свой собственный IP-адрес. Ответа на такой запрос быть не должно, но все машины могут запомнить эту пару адресов. Если ответ все же придет, это будет означать, что двум машинам назначен один и тот же IP-адрес. При этом вторая машина должна проинформировать системного администрато- ра и прекратить загрузку. Чтобы разрешить изменение соответствий адресов, например, при поломке и замене сетевой карты на новую (с новым Ethernet-адресом), записи в ARP-кэше должны устаревать за несколько минут. Посмотрим снова на рис. 5.53. На этот раз хост 1 хочет послать пакет хосту 4 (192.31.63.8). Обращение к ARP не даст результата, так как хост 4 не увидит ши- роковещательного пакета (маршрутизаторы не переправляют широковещатель- ные пакеты Ethernet-уровня). Есть два решения данной проблемы. Во-первых, маршрутизатор факультета кибернетики можно настроить так, чтобы он отвечал на ARP-запросы к сети 192.31.63.0 (а также к другим местным сетям). В таком случае хост 1 добавит в свой ARP-кэш строку (192.31.63.8, ЕЗ) и будет счастлив посылать весь трафик для хоста 4 локальному маршрутизатору. Такой метод на- зывается ARP-прокси. Второе решение состоит в том, чтобы хост 1 сразу выяв- лял нахождение адресата в удаленной сети и посылал весь внешний трафик по Ethernet-адресу, обрабатывающему все пакеты для удаленных адресатов, то есть по адресу маршрутизатора Ј3. В этом случае маршрутизатору факультета кибер- нетики не нужно знать, какую именно удаленную сеть он обслуживает. В любом случае хост 1 помещает IP-пакет в поле полезной нагрузки Ethernet- кадра, адресованного маршрутизатору Ј3. Получив Ethernet-кадр, маршрутизатор факультета кибернетики извлекает из поля полезной нагрузки IP-пакет и ищет его IP-адрес в своих таблицах. Он обнаруживает, что пакеты, адресованные сети 192.31.63.0, должны пересылаться маршрутизатору 192.31.60.7. Если ему еще не известен FDDI-адрес маршрутизатора 192.31.60.7, то он посылает по кольцу ши- роковещательный ARP-пакет и узнает, что нужный ему адрес F3. Затем он поме- щает IP-пакет в поле полезной нагрузки FDDI-кадра, адресованного маршрути- затору F3, и отправляет его по кольцу. Когда кадр попадает на маршрутизатор факультета электротехники, FDDI- драйвер извлекает из поля полезной нагрузки IP-пакет и передает его IP-про- грамме, которая понимает, что этот пакет следует переслать 192.31.63.8. Если та-кого IP-адреса еще нет в ARP-кэше, маршрутизатор посылает широковещатель- ный ARP-запрос по сети Ethernet факультета электротехники и узнает, что нужный ему адрес принадлежит хосту Ј6, поэтому он создает Ethernet-кадр, ад- ресованный хосту Ј6, помещает IP-пакет в поле полезной нагрузки и передает его по сети Ethernet. Получив Ethernet-кадр, хост 4 извлекает из поля полезной нагрузки IP-пакет и передает его IP-программе для обработки. Пересылка хостом 1 пакетов в удаленную сеть по глобальной сети работает аналогично, с той разницей, что на этот раз маршрутизатор факультета киберне- тики узнает из своих таблиц, что пакет следует переслать маршрутизатору гло- бальной сети, чей FDDI-адрес равен F2.

Протоколы RARP, ВООТР и DHCP

Протокол ARP решает проблему определения по заданному IP-адресу Ethernet- адреса хоста. Иногда бывает необходимо решить обратную задачу, то есть по за- данному Ethernet-адресу определить IP-адрес. В частности, эта проблема возни- кает при загрузке бездисковой рабочей станции. Обычно такая машина получает двоичный образ своей операционной системы от удаленного файлового сервера. Но как ей узнать его IP-адрес? Первым для решения проблемы был разработан протокол RARP (Reverse Address Resolution Protocol — протокол обратного определения адреса), описан- ный в RFC 903. Этот протокол позволяет только что загрузившейся рабочей стан- ции разослать всем свой Ethernet-адрес и сказать: «Мой 48-разрядный Ethernet- адрес — 14.04.05.18.01.25. Знает ли кто-нибудь мой IP-адрес?» RARP-сервер ви- дит этот запрос, ищет Ethernet-адрес в своих файлах конфигурации и посылает обратно соответствующий IP-адрес. Использование протокола RARP лучше внедрения IP-адреса в образ загру- жаемой памяти, так как это позволяет использовать данный образ памяти для разных машин. Если бы IP-адреса хранились бы где-то в глубине образа памяти, каждой машине понадобился бы свой отдельный образ. Недостаток протокола RARP заключается в том, что в нем для обращения к RARP-серверу используется адрес, состоящий из одних единиц (ограниченное широковещание). Однако эти широковещательные запросы не переправляются маршрутизаторами в другие сети, поэтому в каждой сети требуется свой RARP- сервер. Для решения данной проблемы был разработан альтернативный загру- зочный протокол ВООТР. В отличие от RARP, он использует UDP-сообщения, пересылаемые маршрутизаторами в другие сети. Он также снабжает бездиско- вые рабочие станции дополнительной информацией, включающей IP-адрес фай- лового сервера, содержащего образ памяти, IP-адрес маршрутизатора по умолча- нию, а также маску подсети. Протокол ВООТР описан в документах RFC 951, 1048 и 1084. Серьезной проблемой, связанной с применением ВООТР, является то, что таблицы соответствия адресов приходится настраивать вручную. Когда к ЛВС подключается новый хост, протокол ВООТР невозможно использовать до тех пор, пока администратор сети не присвоит ему IP-адрес и не пропишет вручную в конфигурационных таблицах пару (Ethernet-адрес, IP-адрес). Для устранения влияния этого фактора протокол ВООТР был изменен и получил новое имя: DHCP (Dynamic Host Configuration Protocol — протокол динамической настрой- ки хостов). DHCP позволяет настраивать таблицы соответствия адресов как вручную, так и автоматически. Этот протокол описан в RFC 2131,и 2132. В боль- шинстве систем он уже практически заменил RARP и ВООТР. Подобно RARP и ВООТР, DHCP основан на идее специализированного сер- вера, присваивающего IP-адреса хостам, которые их запрашивают. Такой сервер не обязательно должен быть подключен к той же ЛВС, что и запрашивающий хост. Поскольку сервер DHCP может быть недоступен с помощью широковеща- тельной рассылки, в каждой ЛВС должен присутствовать агент ретрансляции, как показано на рис. 5.54.

Для отыскания своего IP-адреса загружаемая машина широковещательным способом распространяет специальный пакет DISCOVER (Поиск). Агент ретрансля- ции DHCP перехватывает все широковещательные пакеты, относящиеся к прото- колу DHCP. Обнаружив пакет DISCOVER, он превращает его из широковещатель- ного в одноадресный и доставляет DHCP-серверу, который может находиться и в другой ЛВС. Агенту ретрансляции необходимо знать всего одну деталь: IP-ад- рес DHCP-сервера. Встает вопрос: на какое время можно выдавать в автоматическом режиме IP- адреса из пула? Если хост покинет сеть и не освободит захваченный адрес, этот адрес будет навсегда утерян. С течением времени будет теряться все больше ад- ресов. Для предотвращения этих неприятностей нужно выдавать IP-адреса не на- всегда, а на определенное время. Такая технология называется лизингом. Перед окончанием срока действия лизинга хост должен послать на DHCP-сервер за- прос о продлении срока пользования IP-адресом. Если такой запрос не был сде- лан или в просьбе было отказано, хост не имеет права продолжать использова- ние выданного ранее адреса.