Отображение IP-адресов на локальные адреса

Одной из главных задач, которая ставилась при создании протокола IP, являлось обеспе­чение совместной согласованной работы в сети, состоящей из подсетей, в общем случае использующих разные сетевые технологии. Взаимодействие технологии TCP/IP с локаль­ными технологиями подсетей происходит многократно при перемещении IP-пакета по составной сети. На каждом маршрутизаторе протокол IP определяет, какому следующему маршрутизатору в этой сети надо направить пакет. В результате решения этой задачи про­токолу IP становится известен IP-адрес интерфейса следующего маршрутизатора (или конечного узла, если эта сеть является сетью назначения). Чтобы локальная технология сети смогла доставить пакет на следующий маршрутизатор, необходимо:

§ упаковать пакет в кадр соответствующего для данной сети формата (например, Ethernet);

§ снабдить данный кадр локальным адресам следующего маршрутизатора.

Решением этих задач, как уже отмечалось¹, занимается уровень сетевых интерфейсов стека TCP/IP.

Протокол разрешения адресов

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

Для определения локального адреса по IP-адресу используется протокол разрешения адресов (Address Resolution Protocol, ARP). Протокол разрешения адресов реализуется различным образом в зависимости от того, работает ли в данной сети протокол локальной сети (Ethernet, Token Ring, FDDI) с возможностью широковещания или же какой-либо из протоколов глобальной сети (Frame Relay, ATM), которые, как правило, не поддерживают широковещательный доступ.

Рассмотрим работу протокола ARP в локальных сетях с широковещанием.

На рис. 15.6 показан фрагмент IP-сети, включающий две сети — Ethernet1 (из трех конеч­ных узлов А, В и С) и Ethernet2 (из двух конечных узлов D и E). Сети подключены соответ­ственно к интерфейсам 1 и 2 маршрутизатора. Каждый сетевой интерфейс имеет IP-адрес и MAC-адрес. Пусть в какой-то момент IP-модуль узла С направляет пакет узлу D. Протокол IP узла С определил IP-адрес интерфейса следующего маршрутизатора — это IP₁. Теперь, прежде чем упаковать пакет в кадр Ethernet и направить его маршрутизатору, необходимо определить соответствующий МАС-адрес. Для решения этой задачи протокол IP обращает­ся к протоколу ARP. Протокол ARP поддерживает на каждом интерфейсе сетевого адаптера или маршрутизатора отдельную ARP-таблицу, в которой в ходе функционирования сети накапливается информация о соответствии между IP-адресами и МАС-адресами других интерфейсов данной сети. Первоначально, при включении компьютера или маршрутиза­тора в сеть все его ARP-таблицы пусты.

1. На первом шаге происходит передача от протокола IP протоколу ARP примерно такого сообщения: «Какой МАС-адрес имеет интерфейс с адресом IP₁»

2. Работа протокола ARP начинается с просмотра собственной ARP-таблицы. Предполо­жим, что среди содержащихся в ней записей отсутствует запрашиваемый IP-адрес.

3. В этом случае исходящий IP-пакет, для которого оказалось невозможным определить локальный адрес из ARP-таблицы, запоминается в буфере, а протокол ARP формирует ARP-запрос, вкладывает его в кадр протокола Ethernet и широковещательно рас­сылает.

4. Все интерфейсы сети Ethernet1 получают ARP-запрос и направляют его «своему» про­токолу ARP. ARP сравнивает указанный в запросе адрес IP₁ с IP-адресом интерфейса, на который поступил этот запрос. Протокол ARP, который констатировал совпадение (в данном случае это ARP маршрутизатора 1), формирует ARP-ответ.

В ARP-ответе маршрутизатор указывает локальный адрес MAС₁ своего интерфейса и от­правляет его запрашивающему узлу (в данном примере узлу С), используя его локальный адрес. Широковещательный ответ в этом случае не требуется, так как формат ARP-запроса предусматривает поля локального и сетевого адресов отправителя. Заметим, что зона распространения ARP-запросов ограничивается сетью Ethernet1, так как на пути широко­вещательных кадров барьером стоит маршрутизатор.

Рис. 15.6. Схема работы протокола ARP

 

На рис. 15.7 показан кадр Ethernet с вложенным в него ARP-сообщением. ARP-запросы и ARP-ответы имеют один и тот же формат. В табл. 15.2 в качестве примера приведены значения полей реального ARP-запроса, переданного по сети Ethernet^[49].

Рис. 15.7. Инкапсуляция ARP-сообщений в кадр Ethernet

 

В поле типа сети для сетей Ethernet указывается значение 1. Поле типа протокола по­зволяет использовать протокол ARP не только с протоколом IP, но и с другими сетевыми протоколами. Для IP значение этого поля равно 0x0800. Длина локального адреса для протокола Ethernet равна 6 байт, а длина IP-адреса — 4 байта. В поле операции для ARP- запросов указывается Значение 1, для ARP-ответов — значение 2.

Из этого запроса видно, что в сети Ethernet узел с IP-адресом 194.85.135.75 пытается определить, какой МАС-адрес имеет другой узел той же сети, сетевой адрес которого 194.85.135.65. Поле искомого локального адреса заполнено нулями.

Таблица 15.2. Пример ARP-запроса

Поле	Значение
Тип сети	1(0x1)
Тип протокола	2048(0x800)
Длина локального адреса	6(0x6)
Длина сетевого адреса	4(0x4)
Операция	1 (0x1)
Локальный адрес отправителя	008048ЕВ7Е60
Сетевой адрес отправителя	194.85.135 75
Локальный (искомый) адрес получателя
Сетевой адрес получателя	194.85.135.65

 

Ответ присылает узел, опознавший свой IP-адрес. Если в сети нет машины с искомым IP- адресом, то ARP-ответа не будет. Протокол IP уничтожает IP-пакеты, направляемые по этому адресу. В табл. 15.3 показаны значения полей ARP-ответа, который мог бы поступить на приведенный в табл. 15.2 ARP-запрос.

Таблица 15.3. Пример ARP-ответа

Поле	Значение
Тип сети	1(0x1)
Тип протокола	2048(0x800)
Длина локального адреса	6(0x6)
Длина сетевого адреса	4(0x4)
Операция	2(0x1)
Локальный адрес отправителя	00E0F77F1920
Сетевой адрес отправителя	194.85.135.65
Локальный (искомый) адрес получателя	008048ЕВ7Е60
Сетевой адрес получателя	194.85.135.75

 

В результате обмена ARP-сообщениями модуль IP, пославший запрос с интерфейса, имею­щего адрес 194.85.135.75, определил, что IP-адресу 194.85.135.65 соответствует МАС-адрес 00EOF77F1920. Этот адрес затем помещается в заголовок кадра Ethernet, ожидавшего от­правления IP-пакета.

Чтобы уменьшить число ARP-обращений в сети, найденное соответствие между IP-адресом и МАС-адресом сохраняется в ARP-таблице соответствующего интерфейса, в данном случае — это запись:

194.85.135.65 - 00E0F77F1920

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

ARP-таблица пополняется не только за счет поступающих на данный интерфейс ARP- ответов, но и в результате извлечения полезной информации из широковещательных ARP-запросов. Действительно, в каждом запросе, как это видно из табл. 15.2 и 15.3, содер­жатся IP-адрес и МАС-адрес отправителя. Все интерфейсы, получившие этот запрос, могут поместить информацию о соответствии локального и сетевого адресов отправителя в соб­ственную ARP-таблицу. В частности, все узлы, получившие ARP-запрос (см. табл. 15.2), могут пополнить свою ARP-таблицу записью:

194.85.135.75 - 008048ЕВ7Е60

Таким образом, вид ARP-таблицы, в которую в ходе работы сети были добавлены две упо­мянутые нами записи, иллюстрирует табл. 15.4.

Таблица 15.4. Пример ARP-таблицы

IP-адрес	МАС-адрес	Тип записи
194.85.135.65	00E0F77F1920	Динамический
194.85.135.75	008048ЕВ7Е60	Динамический
194.85.60.21	008048ЕВ7567	Статический

 

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

ПРИМЕЧАНИЕ

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

Совсем другой способ разрешения адресов используется в глобальных сетях, в которых не поддерживается широковещательная рассылка. Здесь администратору сети чаще всего при­ходится вручную формировать и помещать на какой-либо сервер ARP-таблицы, в которых он задает, например, соответствие IP-адресов адресам Х.25, имеющих для протокола IP смысл локальных адресов. В то же время сегодня наметилась тенденция автоматизации работы протокола ARP и в глобальных сетях. Для этой цели среди всех маршрутизаторов, подключенных к какой-либо глобальной сети, выделяется специальный маршрутизатор, который ведет ARP-таблицу для всех остальных узлов и маршрутизаторов этой сети.

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

В некоторых случаях возникает обратная задача — нахождение IP-адреса по известному локальному адресу. Тогда в действие вступает реверсивный протокол разрешения адресов (Reverse Address Resolution Protocol, RARP). Этот протокол используется, например, при старте бездисковых станций, не знающих в начальный момент времени своего IP-адреса, но знающих МАС-адрес своего сетевого адаптера.

Протокол Proxy-ARP

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

На рис. 15.8 показана сеть, один из конечных узлов которой (компьютер D) работает в режиме удаленного узла. Подробнее об этом режиме рассказывается в главе 22, а сейчас достаточно знать, что конечный узел в таком режиме обладает всеми возможностями компьютеров, работающих в основной части сети Ethernet, в частности он имеет IP-адрес (IP_D), относящийся к той же сети. Для всех конечных узлов сети Ethernet особенности подключения удаленного узла (наличие модемов, коммутируемая связь, протокол PPP) абсолютно прозрачны — они взаимодействуют с ним обычным образом. Чтобы такой режим взаимодействия стал возможным, среди прочего, необходим протокол Proxy-ARP Поскольку удаленный узел подключен к сети по протоколу PPP, то он, очевидно, не имеет МАС-адреса.

 

Рис. 15.8. Схема работы протокола Proxy-ARP

Пусть приложение, работающее, например, на компьютере С, решает послать пакет ком­пьютеру D. Ему известен IP-адрес узла назначения (IP_D), однако, как мы уже не раз от­мечали, для передачи пакета по сети Ethernet его необходимо упаковать в кадр Ethernet и снабдить МАС-адресом. Для определения МАС-адреса IP-протокол узла С обращается к протоколу ARP, который посылает широковещательное сообщение с ARP-запросом. Если бы в этой сети на маршрутизаторе не был установлен протокол Proxy- ARP, на этот запрос не откликнулся бы ни один узел.

Однако протокол Proxy-ARP установлен на маршрутизаторе и работает следующим об­разом. При подключении к сети удаленного узла D в таблицу ARP-маршрутизатора за­носится запись

IP_D — MAC₁ — int2,

которая означает, что:

§ при поступлении ARP-запроса на маршрутизатор относительно адреса IP D) в ARP- ответ будет помещен аппаратный адрес MAC₁, соответствующий аппаратному адресу интерфейса 1 маршрутизатора;

§ узел, имеющий адрес IP_D, подключен к интерфейсу 2 маршрутизатора.

В ответ на посланный узлом С широковещательный ARP-запрос откликается маршру­тизатор с установленным протоколом Proxy-ARP. Он посылает «ложный» ARP-ответ, в котором на место аппаратного адреса компьютера D помещает собственный адрес MAC₁. Узел С, не подозревая «подвоха», посылает кадр с IP-пакетом по адресу MAC₁. Получив кадр, маршрутизатор с установленным протоколом Proxy-ARP «понимает», что он на­правлен не ему (в пакете указан чужой IP-адрес) и, следовательно, надо искать адресата в ARP-таблице. Из таблицы видно, что кадр надо направить узлу, подключенному ко второму интерфейсу

Мы рассмотрели простейшую схему применения протокола Proxy-ARP, которая тем не менее достаточно полно отражает логику его работы.

Система DNS

Плоские символьные имена

В операционных системах, которые первоначально разрабатывались для локальных сетей, таких как Novell NetWare, Microsoft Windows или IBM OS/2, пользователи всегда работали с символьными именами компьютеров. Так как локальные сети состояли из небольшого числа компьютеров, применялись так называемые плоские имена, состоящие из последо­вательности символов, не разделенных на части. Примерами таких имен являются: NW1_1, mail2, MOSCOW_SALES_2. Для установления соответствия между символьными именами и MAC-адресами в этих операционных системах применялся механизм широковещательных запросов, подобный механизму запросов протокола ARP. Так, широковещательный способ разрешения имен реализован в протоколе NetBIOS, на котором были построены многие локальные ОС. Так называемые NetBIOS-имена стали на долгие годы одним из основных типов плоских имен в локальных сетях.

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