Разрешение локального IP-адреса

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

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

2. Если он не найден, протокол АRР формирует запрос типа «Чей это» IР-адрес и каков Ваш адрес сетевого адаптера?», в который также включаются адреса IР и сетевого адаптера узла-отправителя. АRР-запрос посылается в широковещательном режиме, чтобы все узлы в локальной сети могли принять и обработать его.

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

4. Узел-получатель определяет, что IР-адрес в запросе совпадает с его собственным, и посылает на узел-отправитель АRР-ответ, в котором указывает свой адрес сетевого адаптера. Затем он обновляет свой АRР-кэш, занося в него соответствие IР-адреса узла-отправителя адресу его сетевого адаптера. После того как узел-отправитель получает АRР-ответ, соединение может быть установлено.

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

1. При соединении определяется, что IР-адрес узла-получателя принадлежит удаленной сети. Узел-отправитель ищет в локальной таблице маршрутизации путь к узлу-получателю или его сети. Если путь не найден в таблице, узел-отправитель определяет IР-адрес шлюза по умолчанию. Затем он ищет в кэше протокола ARP соответствующий ему адрес сетевого адаптера.

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

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

4. Когда пакет достигнет получателя и будет обработан им, все исходящие пакеты таким же образом будут доставлены обратно. Например, при выполнении команды Р1пд в ответ на эхо-запрос узел-получатель пакета формирует эхо-ответ протокола IСМР (IСМР есhо-герlу). Поскольку узел-отправитель находится в удаленной сети, в локальной таблице маршрутизации ищется адрес шлюза к сети узла-отправителя. Если поиск завершается успехом, адрес сетевого адаптера шлюза выясняется с помощью ARP.

5. Если адреса сетевого адаптера указанного шлюза нет в кэше протокола ARP, то для его определения используется широковещательный ARP-запрос. Как только адрес получен, эхо-ответ протокола IСМР посылаете; на маршрутизатор, который перенаправляет его на исходный узел-отправитель.

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

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

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

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

Служба доменных имен.

Широковещательный способ установления соответствия между символьными именами и локальными адресами хорошо работает только в небольшой локальной сети, неразделенной на подсети. В стеке ТСР/ IP применяется доменная (выделенное множество объектов) система имен, которая имеет иерархическую древовидную структуру, допускающую использование вимени произвольного качества составных частей (рис. 39).

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

Соответствие между доменными именами и IP-адресами может устанавливаться как средствами локального хоста, так и средствами централизованной службы. По мере роста Интернета файлы hosts также росли, и создание масштабируемого разрешения имен нашло свое решение в создании социальной службы – системы доменных имен (Domain Name System – DNS). DNS – это централизованная служба, основанная на распределенной базе отображений «доменное имя – IP-адрес». Служба DNS использует в своей работе протокол типа «клиент-сервер». В нем определены DNS-серверы и DNS-клиенты. DNS-серверы поддерживают

ucl

project

ucl

ftp

www

mgu

www

ftp

zil

www

mail

mmt

www

yandex

Корень

com

www

Home

Microsoft

IBM

распределенную базу отображений, а DNS-клиенты обращаются к серверам с запросами о разрешении доменного имени в IP-адрес.

В доменной системе адресации DNS каждый корреспондент получает сетевой адрес, включающий две составляющие: идентификатор пользователя (userid) и идентификатор узла (nodeid). Идентификатор «userid» является уникальным для узла сети. Идентификатор «nodeid» представляет собой текстовую строку, состоящую из доменов, разделяемых точками.

В системе DNS ключевым является понятие «полностью определенное имя домена» - это имя домена, которое включает все домены более высокого уровня и образует полное, целое имя. Структуру DNS (Domain Name System – служба доменных имен) можно представить в виде дерева, каждый узел которого имеет свое название (метку) (рис. 39). Для каждого конкретного узла «полностью определенное имя домена» будет состоять из его имени и имени всех узлов, связывающих его с корнем дерева, причем корневой домен всегда нулевой.

Существует две основные схемы разрешения DNS-имен. В первом варианте работу по поиску IP-адреса координирует DNS-клиент.

1. DNS-клиент обращается к корневому DNS-серверу с указанием полного доменного имени;

2. DNS-сервер отвечает, указывая адрес следующего DNS-сервера, обслуживающего домен верхнего уровня, заданный в старшей части запрошенного имени;

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

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

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

1. DNS-клиент запрашивает локальный DNS-сервер, то есть тот сервер, обслуживающий поддомен, к которому принадлежит имя клиента;

2. если локальный DNS-сервер знает ответ, то он сразу же возвращает его клиенту; это может соответствовать случаю, когда запрошенное имя входит в тот же поддомен, что и имя клиента, а также случаю, когда сервер уже узнавал данное соответствие для другого клиента и сохранил его в своем КЭШе;

3. если локальный сервер не знает ответ, то он выполняет итеративные запросы к корневому серверу и т.д. точно так же, как это делает клиент в первом варианте. Получив ответ, он передает его клиенту, который все это время просто ожидает его от своего локального DNS-сервера.

Итерация – процесс повторения последовательности действий.

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