Разрешение ip-адресов

На канальном и физическом уровнях модели OSI для передачи IP-пакетов они должны содержать как минимум аппаратный (MAC) адрес получателя. Для определения MAC-адреса получателя необходим механизм сопоставления IP-адресу MAC-адреса.

Разрешение (преобразование) IP-адресов в соответствующие им MAC-адреса осуществляется при помощи протокола ARP (Address Resolution Protocol). Процесс сопоставления адресов достаточно прост. Когда компьютер должен отправить пакет, ARP отправляет в локальную сеть широковещательный запрос об MAC-адресе узла с данным IP-адресом. Если узел находится в локальной сети, то он отвечает на ARP запрос и возвращает свой MAC-адрес. На этом процедура разрешения адресов заканчивается. Немного по-другому протокол ARP работает для узла-получателя в удаленной сети. Если узел находится в удаленной сети, то шлюз по умолчанию возвращает в ответ на запрос свой MAC-адрес. После этого компьютер отправитель отправляет при помощи протокола ICMP (Internet Control Message Protocol, протокол используемый IP и другими высокоуровневыми протоколами для отправки и получения сообщений о статусе передаваемой информации) эхо-запрос узлу-получателю через шлюз по умолчанию, который пытается достичь конечного узла. При этом маршрутизатор (шлюз) начинает свой собственный ARP-сеанс – и так продолжается с каждым маршрутизатором по пути следования пакета, пока очередной маршрутизатор не обнаружит, что для него узел-получатель является локальным.

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

Когда узел-получатель сообщает своему локальному маршрутизатору свой аппаратный адрес, а так же ответ на ICMP-запрос, процесс разрешения адресов для адресата в удаленной сети заканчивается. Такой процесс определения удаленного адреса называется ARP-прокси, поскольку маршрутизатор играет для запросов роль прокси-сервера.

После того как узел-отправитель выяснил MAC-адрес, соответствующий данному IP-адресу, он записывает это соответствие в ARP-кэш. Если через некоторое время происходит отправка данных той же системе, MAC-адрес берется их кэша и широковещательный запрос не производится. По умолчанию записи в ARP-кэше хранятся в течение 10 минут, и по прошествию этого времени удаляются оттуда. В некоторых реализациях протокола TCP/IP отсчет начинается с заново, если компьютер взаимодействовал с узлом, которому соответствует запись.

В большинство операционных систем включена утилита (команда) ARP, она имеет следующий синтаксис:

arp <ключ> <IP-адрес> <MAC-адрес>

Таблица 5.10 – Ключи команды ARP и их описание

Ключ	Описание
-a	Вывод записей содержащихся в ARP-кэше
-N	Вывод записей содержащихся в ARP-кэше и относящихся к определенному интерфейсу
-s	Добавление статической записи в ARP-кэш
-d	Удаление статической записи в ARP-кэш

Адреса можно вводить в ARP-кэш вручную (ключ -s), создаваемые таким образом статические записи не удаляются из кэша автоматически, однако они удаляются при перезагрузке системы или при получении широковещательного сообщения, свидетельству-ющего о неверности адреса. Если статическая запись изменяется в соответствии с широковещательным сообщением, ее тип тоже изменяется со статического на динамический и правило 10 минут вступает в силу.

Существует протокол обратного разрешения адресов RARP (Reverse Address Resolution Protocol). Его функции обратны ARP – он позволяет определить IP-адрес по данному аппаратному адресу. Этот протокол используется большей частью на бездисковых рабочих станциях (тонких клиентах), которые должны получить свой IP-адрес с сервера. Рабочая станция отправляет RARP-запрос, сервер RARP обрабатывает этот запрос и отправляет IP-адрес рабочей станции. В отличие от ARP протокол RARP требует сервера для назначения IP-адресов рабочим станциям, поэтому он используется не так широко, а после появления протокола DHCP (Dynamic Host Configuration Protocol) который мы рассмотрим позже, он стал скорее любопытной возможностью, но не функциональным протоколом.

I

- 66 - - 67 -

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

Для устранения подобной проблемы была предложена система именования, получившая название системы доменных имен DNS (Domain Name System). Имена узлов, используемые в рамках данной системы, получили название FQDN (Fully Qualified Domain Name).

Имена узлов удобны еще и потому, что они позволяют организовать идентификацию узла безотносительно его физического расположения или IP-адреса. Действительно, IP-адрес узла соответствует его физическому расположению в сети. Если узел переносится из одной сети в другую, его IP-адрес должен быть изменен. Использование же имени узла для идентификации системы делает смену IP-адреса прозрачной для конечного пользователя. Существуют определенные ограничения на вид используемых имен узлов, описанные в RFC 1123. Имя узла может содержать до 255 символов, включая a-z, A-Z, 0-9 и знак дефиса. Использование специальных символов, таких как !, %, * не допускается, имя узла не может состоять только из цифр. Согласно новому RFC 1033 допускается начинать имена с цифр и использовать в именах символы подчеркивания.

Файл HOSTS может поддерживаться пользователем компьютера или же находится на сервере и копироваться на каждую машину при ее загрузке. Однако этот файл должен обновляться каждый раз, когда IP-адрес какого-либо указанного в нем узла изменяется. В каждой строке файла HOSTS содержится в начале IP-адрес, за которым следует по крайней мере один пробел и соответствующие этому IP-адресу имена узлов или FQDN. Ни в одной строке не может содержаться несколько IP-адресов, хотя несколько имен узлов или FQDN в одной строке допустимы. Если компьютер настроен на использование файла HOSTS, то этот файл читается строка за строкой каждый раз, когда требуется определить имя узла. Чтобы ускорить определение имен, имеет смысл поместить часто используемые записи в начало файла.

При определении имен TCP/IP в первую очередь определяет, не содержится ли IP-адрес в его собственном кэше имен (рис. 5.8). Производится сравнение имени узла, с которым должно быть установлено соединение, с именем локального узла, заданным при настройке TCP/IP. Если имена совпадают, компьютер просто открывает TCP/IP соединение с самим собой по нужному порту. Если имена не совпадают, то производится поиск IP-адреса, соответствующего имени узла, в файле HOSTS. Если IP-адрес, соответствующий данному имени узла, не обнаружен в этом файле, то TCP/IP обращается к серверу DNS (DNS подробно обсуждается в разделе «DNS», ниже в этом разделе). Если запрос не дал результатов TCP/IP может производить некоторые дополнительные запросы зависящие от особенностей реализации конкретной операционной системы. В случае если один из описанных методов определения имени возвращает IP-адрес, то процесс останавливается, даже если полученный IP-адрес недопустим. Если ни один из методов не позволяет найти нужное соответствие имя-адрес, единственный способ установить соединение с удаленным узлом – использовать его IP-адрес вместо имени.

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

Система доменов сети Internet представляет собой иерархическую структуру, администрируемую организацией InterNIC. Часто используется термин «пространство имен доменов» который обозначает структуру и данные, созданные распределенной службой формирования имен узлов в сети Internet. Эта иерархия имеет много уровней, и множество различных компьютеров отвечают за поддержку различных ее частей.

В корне иерархии находятся корневые серверы имен поддерживаемые InterNIC. На следующем уровне расположены домены верхнего уровня: .com, .net, .org, .edu и ряд других суффиксов, обозначающих названия стран или типы поддоменов в домене.

Независимо от длины имени, узел находится в иерархической структуре доменной системы имен FQDN.

О

- 68 - - 69 -

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

• Основной сервер имен отвечает за часть пространства имен доменов, называемого зоной. Информация, образующая зону, содержится в файле зоны.

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

• Мастер-сервер имен – любой сервер имен, передающий информацию о зоне дополнительному серверу имен.

• Кэширующий сервер – кэширует запросы на определенное имя. Назначение такого сервера состоит в увеличении эффективности процесса определения имен.

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