Ю.Ф.Кожанов, Колбанев М.О ИНТЕРФЕЙСЫ И ПРОТОКОЛЫ СЕТЕЙ СЛЕДУЮЩЕГО ПОКОЛЕНИЯ

______________________________________________________________________________

0хffff используется при аутентификации, при этом маршрутная этикетка принимает значение 2, а в поле подробностей маршрута помещается 16-байтный пароль.

Метрика (Metric)

Следующий переход (Next Hop)

Маска (Subnet Mask)

Сетевой адрес (IP address)

4 уровень

3 уровень

2 уровень

1 уровень

Рис. 1.43. Местоположение в стеке протоколов и формат RIP

Маршрутная этикетка (Route Tag) – длина 2 байта, используется для разделения маршрутов внутренних и внешних сетей. Для внутренних сетей принимает значение 0.

Подробности маршрута содержит сетевой адрес (IP address), маску (Subnet Mask), следующий переход (Next Hop), метрику (Metric).

Параметр следующий переход (Next Hop) используется в тех случаях, когда в сети используются шлюзы с другими протоколами маршрутизации (например, OSPF) и они не могут сообщить свои данные о маршрутах по RIP. Промежуточный шлюз, имеющий оба протокола получает информацию по OSPF и пересылает по протоколу RIP сетевой адрес (IP address), маску (Subnet Mask), метрику (Metric) известной ему сети,

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

1.10.2. Протокол динамической конфигурации оконечных устройств

Протокол динамической конфигурации оконечных устройств (Dynamic Host Configuration Protocol, DHCP) [RFC 2131, DS] решает две задачи: назначение параметров конфигурации и назначение IP-адреса оконечным устройствам (ОУ). Используется модель клиент-сервер, где под понятием клиент подразумевается узел, использующий DHCP для запроса конфигурации, а под понятием сервер – узел, возвращающий по запросу конфигурационные параметры. Основой DHCP является протокол удаленной загрузки узла (Bootstrap Protocol – BOOTP). Сервер и клиент в большинстве сетях не имеют непосредственной связи, поэтому транзитные узлы (BOOTP Relay Agent) должны уметь ретранслировать сообщения между ними. DHCPсервер конфигурируется администратором сети и ведет централизованное назначение сетевых адресов, что исключает их дублирование. DHCP использует три механизма назначения адреса. При автоматическом назначении DHCP-сервер без вмешательства оператора из пула (диапазона) разрешенных адресов возвращает один и тот же адрес без ограничения срока жизни. При динамическом назначении – DHCP-сервер возвращает один и тот же адрес в течение ограниченного времени (срока аренды), при ручном – DHCP-сервер возвращает один и тот же адрес, назначенный администратором сети. Только механизм динамического назначения адреса позволяет автоматически присваивать тот же IP-адрес другому клиенту, после того, как он оказался не нужен предыдущему клиенту. Это свойство используется для временного подключения клиентов к сети и экономии IP-адресов.

При истечении срока аренды клиент обязан пройти процедуру продления конфигурационных параметров.

66

______________________________________________________________________________

В качестве транспортного уровня DHCP использует UDP. Клиентский узел, использующий DHCP, запускает свой процесс через порт 68, а сервер – через порт 67. Местоположение и наименование полей DHCP изображено на рис. 1.44. Порядок передачи бит кадра: слева направо/снизу вверх.

Опции (Options)

. . .

Имя файла (file)

. . .

Имя сервера (sname (64))

. . .

MAC-адрес (chaddr (16))

IP-адрес шлюза (giaddr)

IP-адрес сервера (siaddr)

Предлагаемый IP-адрес (yiaddr)

IP-адрес клиента (ciaddr)

4 уровень

3 уровень

2 уровень

1 уровень

Рис. 1.44. Местоположение в стеке протоколов и формат DHCP

Код операции (op) – длина 1 байт, принимает значение 1 при запросе

(BOOTREQUEST) или 2 при ответе (BOOTREPLY).

Тип интерфейса (Hardware type, htype) – длина 1 байт, показывает технологию, используемой в локальной сети (0x0001 – технология Ethernet).

Длина МАС-адреса (Hardware Address Length, hlen) – длина МАС-адреса (0х06 – Ethernet).

Число переходов (hops) – длина 1 байт, устанавливается в “0” на клиентской стороне, увеличивается на 1 каждым промежуточным узлом и служит для контроля удаленности загружаемого узла (сообщения со значением более 3 – уничтожаются).

Идентификатор операции (xid) – случайное число, генерируемое клиентом, используется для идентификации диалога обеими сторонами, длина 4 байта.

Секунды (secs) – заполняется клиентом и указывает время в секундах, после которого клиент начал использовать загрузочные параметры, длина 2 байта.

Флаги (flags) – содержит указание на возможность приема дейтаграмм без конфигурирования загруженного программного обеспечения , длина 2 байта.

IP-адрес клиента (ciaddr) – ранее назначенный IP-адрес клиента, применяется в сообщениях при продлении срока аренды имеющегося IP-адреса, длина 4 байта.

Предлагаемый IP-адрес (yiaddr) – указывает IP-адрес, предлагаемый сервером, в ответ на запрос назначения от клиента, длина 4 байта.

IP-адрес сервера (siaddr) – указывает IP-адрес сервера, используемого для последующей загрузки параметров, длина 4 байта.

IP-адрес шлюза (giaddr) – указывает IP-адрес транзитного узла, через который производится загрузка, длина 4 байта.

67

Ю.Ф.Кожанов, Колбанев М.О ИНТЕРФЕЙСЫ И ПРОТОКОЛЫ СЕТЕЙ СЛЕДУЮЩЕГО ПОКОЛЕНИЯ

______________________________________________________________________________

MAC-адрес (chaddr) – МАС-адрес клиента, используется сервером для поиска в своей таблице типа возвращаемого IP-адреса: статистического или динамического, длина 16 байт.

Имя сервера (sname) – имя загрузочного сервера, параметр опциональный, длина 64 байта, неиспользуемые конечные символы заполняются “0”.

Имя файла (file) – имя загрузочного файла, параметр опциональный, длина 128 байт, неиспользуемые конечные символы заполняются “0”.

Опции (Options) – опциональная часть переменной длины, содержащая лист запрашиваемых параметров конфигурации.

В сети может одновременно функционировать несколько DHCP-серверов, поэтому процесс назначения IP адреса состоит из нескольких этапов:

–поиска клиентом работоспособного DHCP-сервера (передача клиентом широковещательного сообщения DHCPDISCOVER);

–рассмотрения поступивших от серверов предложений (передача каждым сервером широковещательного сообщения DHCPOFFER);

–выбора клиентом приемлемого предложения (передача клиентом широковещательного сообщения DHCPREQUEST с конкретным адресом выбранного сервера);

–регистрации клиента (передача сервером сообщения DHCPACK).

Для корректной раздачи загрузочных параметров в DHCP-сервере на каждого клиента заводится таблица соответствия ключевых слов и механизма назначения адреса. В качестве ключевого слова используется уникальное сочетание номера подсети и МАС-адреса или номера подсети и имени компьютера.

Рассмотрим пример назначения IP-адреса в виде ниже приведенной табл. 1.19.

Табл. 1.19

1. Оконечное устройство высылает серверу широковещательный запрос поиска сервера (DHCPDISCOVER) в котором:

op=1 (BOOTREQUEST), htype=1 (Ethernet), hlen=6 (Ethernet), hops=0, xid=12789 (случайное число), secs=0, flag=0, ciaddr=0, yiaddr=0, siaddr=0, giaddr=0, chaddr=MAC-

адрес клиента, sname=0(любой сервер), file=0(по умолчанию), опции – маска сети, доменное имя, IP-адреса маршрутизатора, DNS и желаемый IP-адрес.

68

______________________________________________________________________________

Запускается таймер ожидания предложений от серверов со значением 4 секунды, при истечении которого запрос возобновляется с постоянным увеличением значения таймера: 8, 16, 32, 64 секунды.

2.Каждый сервер, получив запрос, просматривает свою таблицу ключевых слов и определяет механизм присвоения IP-адреса, проверяя уникальность предлагаемого IPадреса предварительным ICMP-эхо запросом. Сообщение DHCPOFFER содержит:

op=2 (BOOTREPLY), htype=1 (Ethernet), hlen=6 (Ethernet), hops=0, xid=12789 (то же самое случайное число), secs=0, flag=1(широковещательный), ciaddr=0, yiaddr=предлагаемый клиенту IP-адрес, siaddr=IP-адрес сервера, giaddr=0, chaddr=MAC-

адрес клиента, опции – маска сети, доменное имя, IP-адрес маршрутизатора, IP-адрес DNS сервера, IP-адрес DHCP сервера, время аренды IP-адреса.

3.Выбранному серверу высылается запрос о закреплении IP-адреса

(DHCPREQUEST):

op=1 (BOOTREQUEST), htype=1 (Ethernet), hlen=6 (Ethernet), hops=0, xid=12789 (то же случайное число), secs=0, flag=1(широковещательный), ciaddr=0, yiaddr=0, siaddr=0, giaddr=0, chaddr=MAC-адрес клиента, опции – маска сети, доменное имя, IPадреса маршрутизатора, DNS и желаемый IP-адрес.

4.Сервер подтверждает назначение IP-адреса (DHCPACK):

op=2 (BOOTREPLY), htype=1 (Ethernet), hlen=6 (Ethernet), hops=0, xid=12789 (то же случайное число), secs=0, flag=1(широковещательный), ciaddr=0, yiaddr=предлагаемый клиенту IP-адрес, siaddr=IP-адрес сервера, giaddr=0, chaddr=MAC-

адрес клиента, опции – маска сети, доменное имя, IP-адрес маршрутизатора, IP-адрес DNS сервера, IP-адрес DHCP сервера, время аренды IP-адреса.

Существует еще несколько типов сообщений.

DHCPNAK – высылается от сервера к клиенту при отказе назначения (например, при запросе адреса не из пула разрешенных адресов или при истечении срока аренды).

DHCPDECLINE – высылается от клиента к серверу для уведомления о том, что предлагаемый адрес уже назначен (при проверочном ARP-запросе своего IP-адреса).

DHCPRELEASE – высылается от клиента к серверу для уведомления об отказе от дальнейшей аренды сетевого адреса.

DHCPINFORM – высылается от клиента к серверу для уведомления о том, что сетевой адрес уже имеется (установлен вручную администратором сети) и требуются только локальные параметры.

1.10.3. Протокол разрешения доменных имен

Для установления соответствия между символическими именами пользователей и их сетевыми адресами в Интернет используется система доменных имен (Domain Name System, DNS) [RFC 1034, RFC 1035, STD 13]. Доменное имя представляет собой конечную последовательность из N этикеток, разделенных точкой, вида <этикетка N>.<этикетка N-1>.<…>.<этикетка 1.>.< . >. Каждая этикетка может состоять из букв, цифр или тире 7-разрядного кода ASCII, причем

нет различия между заглавными и прописными буквами; этикетка всегда начинается с буквы, а заканчиваться буквой или цифрой;

длина этикетки не должна превышать 63 октетов (символов), а общая длина доменного имени – не более 255 октетов,

последняя этикетка не имеет имени и обозначается “точкой”.

Доменное имя – это перечень этикеток от узла к корню. Домен с этикеткой <N> является частью домена (поддоменом) по отношению к домену с этикеткой <N-1> и носит название зоны. Архитектура системы доменных имен имеет древовидную структуру, аналогичную системе каталогов в компьютере (рис. 1.45).

69

Ю.Ф.Кожанов, Колбанев М.О ИНТЕРФЕЙСЫ И ПРОТОКОЛЫ СЕТЕЙ СЛЕДУЮЩЕГО ПОКОЛЕНИЯ

______________________________________________________________________________

Для каждой зоны на сети создается хотя бы один первичный (master) DNS-сервер, хранящий таблицу соответствия “доменное имя – описание ресурса”. Он имеет составленную администратором базу данных зоны, которая представляет собой таблицу соответствия доменных имен и сетевых ресурсов собственной зоны, а также таблицу соответствия символьных имен и сетевых ресурсов некоторых других зон. Данные о собственной зоне являются авторитетными и хранятся на локальном диске в собственном DNS-сервере в виде мастер файла (Master file). Для обеспечения надежности и снижения нагрузки на первичный сервер может дополнительно существовать несколько вторичных DNS-серверов, которые периодически копируют данные из первичного сервера.

Рис. 1.45. Пример архитектуры системы DNS

База данных хранит архитектуру зоны и IP-адреса сетевых элементов в виде записи о ресурсе (Resource Records), каждая из которых состоит из полей, указанных ниже.

Имя (NAME) – доменное имя ресурса, к которому относятся данные, поле опциональной длины, формат записи – <байт длины этикетки + имя этикетки> <байт длины этикетки + ...

Класс (CLASS) – определяет класс адреса, длина 2 байта. Класс IN определяет принадлежность системы адресации сети Интернет.

Тип (TYPE) – тип записи, длина 2 байта. Тип А означает наличие в поле RDATA IP-адреса узла; тип NS – наличие в поле RDATA имени DNS-сервера; CNAME – наличие в поле RDATA канонического имени узла (некоторые узлы могут иметь несколько символических имен, одно из которых является основным – каноническим, остальные – псевдонимами); SOA – признак зоны авторизации, содержит параметры описания зоны в первичном DNS-сервере (SERIAL – условный номер версии в первичном сервере, значение которого увеличивается при внесении администратором изменений, используется нижележащими и вторичными серверами для обнаружения изменений путем сравнения текущего и предыдущего значений при запросе; REFRESH

– время в секундах для периодического чтения актуального значения SERIAL из первичного DNS-сервера; RETRY – время в секундах для повторного чтения значения SERIAL при неудачной предыдущей попытке; EXPIRE – время в секундах истечения действия записей во вторичных серверах; PTR – указатель на ресурс поля RDATA, которому принадлежит IP-адрес в поле имя; MX – наличие в поле RDATA доменного имени электронной почты (e-mail), к которому приписан узел ...

70

______________________________________________________________________________

Время жизни (TTL) – определяет время хранения информации в кэш-памяти (в секундах), длина 32 бита. Назначается администратором, типовое значение – несколько дней.

Описание ресурса (RDATA) – поле переменной длины, зависящее от типа и класса адреса.

Рассмотрим пример записей (рис. 1.46) базы данных зоны DNS-сервера с доменным именем ISI.EDU, изображенный на рис. 1.45.

Рис. 1.46. Пример записи данных зоны ISI.EDU

Первая запись (SOA) указывает, что ответственным (первичным) за конфигурацию домена (зоны) ISI.EDU, является сервер NS.ISI.EDU. В записи содержится серийный номер 870611, задается время (1800 секунд) периодического чтения данных из первичного сервера, задается время (300 секунд) для повторного чтения данных при неудачной предыдущей попытке, задается время (604800 секунд) истечения действия записей.

Во второй записи указывается, что домен (зону) ISI.EDU обслуживает сервер

NS.ISI.EDU, который имеет IP-адрес 128.9.128.127.

Третья и четвертая записи содержат сведения о зонах, которые являются “подзонами” зоны ISI.EDU. Они необходимы для определения ресурсов, когда запрос двигается в направлении “сверху вниз”. Зона A.ISI.EDU обслуживается сервером PR.A.ISI.EDU c сетевым адресом 26.3.0.103, в котором имеется почтовый ящик с тем же именем. Зона С.ISI.EDU обслуживается сервером PR.С.ISI.EDU c сетевыми адресами 26.0.0.73 и 10.0.0.51. Сервер, обслуживающий зону C.ISI.EDU имеет два имени, одно из них (PR.C.ISI.EDU) является каноническим, а второе (SEC.C.ISI.EDU) – псевдонимом.

Перечисленные записи выделены жирным шрифтом и являются авторитетными (authoritative). Сроки их действия наследуются из первой записи.

71

Ю.Ф.Кожанов, Колбанев М.О ИНТЕРФЕЙСЫ И ПРОТОКОЛЫ СЕТЕЙ СЛЕДУЮЩЕГО ПОКОЛЕНИЯ

______________________________________________________________________________

Следующие две записи являются неавторитетными, поскольку ответственными за них являются сервера зон EDU и MIL. Эти записи необходимы для запроса ресурсов других доменов, когда запрос двигается в направлении “снизу вверх”. В корневых серверах, в том числе EDU и MIL, имеются сведения обо всех доменах верхнего уровня. Сведения о ресурсах домена EDU можно поучить в сервере NS.EDU, а о ресурсах домена MIL– в сервере PRIM.MIL.

В конце базы данных содержатся записи обратных зон, устанавливающих соответствие между IP-адресом и доменным именем.

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

Рис. 1.47. Архитектура службы доменных имен

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

Предположим для нашего случая, что серверу зоны ISI.EDU требуются данные о хосте в зоне ACC.ARPA. В случае рекурсивной процедуры сервер зоны ISI.EDU обратится к серверу зоны (домена) EDU (запрос двигается в направлении “снизу вверх”). Сервер зоны EDU найдет в своих записях о ресурсах адрес сервера домена ARPA и перешлет запрос ему. Сервер зоны ARPA найдет в своих записях о ресурсах адрес сервера зоны ACC.ARPA и перешлет запрос ему (теперь запрос двигается в направлении “сверху вниз”). Сервер ACC.ARPA вернет сведения о запрошенных ресурсах, который будет двигаться по проложенной цепочке в обратном направлении. В данном случае местный сервер производит один единственный запрос, а ответ будет авторитетный, т.к. получен от первоисточника ресурсов.

При использовании не рекурсивной процедуры на запрос сервера зоны ISI.EDU сервер зоны EDU вернет адрес следующего сервера, куда следует обратиться, т.е. адрес сервера домена ARPA. Сервер домена ARPA на второй запрос вернет серверу зоны ISI.EDU адрес сервера ACC.ARPA и только на третий запрос от сервера зоны ACC.ARPA будут получены требуемые данные.

Может случиться так, что при обращении к серверу домена ARPA у него сохранилась в кэш-памяти требуемая информация от предыдущего запроса. В этом случае он не станет делать запрос серверу зоны ACC.ARPA, а перешлет эти данные из

72

______________________________________________________________________________

кэш-памяти. Но в этом случае ответ будет содержать флаг неавторитетного ответа, т.е. запрошенная информация взята из кэш-памяти.

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

Additional – дополнение (из записи о ресурсе)

Authority – указатель авторизации (из записи о ресурсе)

Answer – ответ (из записи о ресурсе)

Question – вопрос DNS-серверу

Header – заголовок

4 уровень

3 уровень

2 уровень

1 уровень

Рис. 1.48. Местоположение и формат протокола DNS

Заголовок (Header) – имеет следующий формат (табл. 1.20):

Табл. 1. 20

ID

QDCOUNT

ANCOUNT

NSCOUNT

ARCOUNT

где ID – 16-битовый идентификатор, генерируется узлом, инициирующим запрос. Ответ возвращается с тем же идентификатором.

QR – бит определяющий запрос (QR=0) или ответ (QR=1).

OPCODE – 4-битовое поле типа запроса (SQUERY=0 – стандартный запрос, IQUERY=1 – инверсный запрос, QUERY=2 – запрос состояния сервера).

AA– бит авторизации ответа, устанавливается в “1” первоисточником ответа, “0”

–ответ, найденный в кэш-памяти).

TC – бит, указывающий на то, что сообщение урезано из-за недопустимо большой длины и содержит только 512 первых байт информации (следует вместо UDP следует использовать TCP).

RD – бит указания серверу об использовании рекурсивной процедуры и возвращения окончательного ответа.

RA – бит ответа сервера о возможности использования рекурсивной процедуры. Z – резерв (3 бита).

RCODE – 4-битовоый код возврата ответа (0 – без ошибок, 1 – ошибка в формате, 2 – сервер недоступен, 3 – ошибка в имени сервера, 4 – отсутствие поддержки запроса сервером, 5 – отказ сервера от запроса).

QDCOUNT – 16-битовый счетчик числа вопросов в запросе. ANCOUNT– 16-битовый счетчик числа ответов.

NSCOUNT– 16-битовый счетчик числа авторизированных ответов в записи о ресурсах.

ARCOUNT– 16-битовый счетчик числа дополнительных ответов в записи о ресурсах.

73

Ю.Ф.Кожанов, Колбанев М.О ИНТЕРФЕЙСЫ И ПРОТОКОЛЫ СЕТЕЙ СЛЕДУЮЩЕГО ПОКОЛЕНИЯ

______________________________________________________________________________

Вопрос DNS-серверу (Question) – содержит запрашиваемое доменное имя

(QNAME), тип (QTYPE) и класс (QCLASS).

Ответ (Answer), указатель авторизации (Authority) и дополнение (Additional)

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

На рис. 1.49 представлены некоторые типовые сценарии функционирования протокола.

Рис. 1.49. Функционирование протокола DNS при а)прямом и б)инверсном запросах

ВОПРОСЫ К РАЗДЕЛУ 1.10

1.Какой транспортный протокол и номер порта использует RIP? Ответ. Протокол не надежной доставки UDP, порт 520.

2.Чем достигается надежность рассылки RIP-сообщений? Ответ. Периодической (через 30 секунд) рассылкой.

3.Какое DHCP-сообщение является первым и почему?

Ответ. Первое сообщение DHCPDISCOVER требуется для обнаружения DHCPсервера.

4.Какие значения принимают MAC-адрес назначения, IP-адрес источника и тип протокола в сообщении DHCPDISCOVER?

Ответ. MAC-адрес=ff:ff:ff:ff:ff:ff, IP-адрес=0.0.0.0, тип протокола 0х0800.

5.Какую основную информацию хранит DNS-сервер?

Ответ. Таблицу соответствия доменных (символьных) имен IP-адресу пункта назначения.

6. Может ли администратор домена def.abc создать учетную запись hh.def.abc и hh.abc?

Ответ. Первую – да, вторую – нет, поскольку администратор домена def.abc не ответственен за домен abc.

74