Процедуры назначения номеров сетям и узлам сетей, входящих в составную сеть, являются централизованными и регламентируются документом «Темы для обсуждения» ‒ RFC 2050 (Request For Comments 2050). По существу, RFC 2050 является стандартом Internet.
Если подсеть является частью сети Internet и технически поддерживается установкой соответствующих маршрутизаторов, то IP-адресация обеспечивается следующим образом:
1 В небольшой автономной локальной сети без выхода в Internet уникальность IP-адресов может быть обеспечена силами сетевого администратора, поскольку совпадение IP-адресов в сетях не связанных между собой не вызывает никаких отрицательных последствий.
2 При включении локальной сети в Internet может возникнуть коллизия адресов. Чтобы этого не произошло, в стандартах Internet указаны процедуры частной адресации узлов сети для автономного использования, предусматривающие возможность в будущем включения ее в глобальную сеть Internet.
Главным органом регистрации глобальных адресов в сети Internet является неправительственная некоммерческая организация ICANN (Internet Corporation for Assigned Names and Numbers) ‒ ассоциация (корпорация) назначения имен и номеров в Internet.
Региональные органы этой организации по всему миру выделяют блоки адресов крупным поставщикам услуг Internet, которые распределяют их между более мелкими поставщиками ‒ интернет-провайдерами.
5.4.1 Основной проблемой централизованного распределения адресов является их дефицит.
В первоначальных разработках операционных систем для локальных сетей, например, NetBIOS, использовались символьные имена ПК, которые не разделялись на части, т.е. были плоскими. Для установления соответствия этих имен МАС-адресам узлов сети использовался механизм широковещательных запросов (обращение ко всем и ожидание ответа от того, кто определил обращение в свой адрес). Однако с расширением сетей такой подход оказался неэффективным, и для стека протоколов TCP/IP была применена доменная система имен, схематически представленная на рисунке 5.4.
Совокупность имен, у которых несколько старших составляющих частей имен совпадают, образуют домен (область) имен. Например, имена: si.mdu.ru; ftp.fns.ru; www2.h1.ru; http1.mdu.ru образуют «домен ru», а ответственный за назначение имен на этом уровне должен следить за тем, чтобы бы все имена имели отличающуюся, следующую по иерархии вниз, часть. В данном примере имена http1.mdu.ru и si.mdu.ru образуют поддомен mdu.ru.
Каждый домен администрирует отдельная организация, которая разбивает домен на поддомены и передает функции администрирования ими другим организациям (Рис. 5.4).
До недавнего времени было очень трудно получить адрес класса В (под номер сети отводится два байта) и практически невозможно получить адрес класса А (под номер сети отводится один байт). В настоящее время эти ограничения сняты, поскольку процедура назначения уникальных доменных имен существенно упростилась, благодаря механизму маскирования ‒ гибкой адресации.
В сети Internet для преобразования символьных адресов в цифровые IP-адреса Internet существует служба DNS (Domain Name System) ‒ система доменных имен, использующая в своей работе DNS-серверы, которые располагаются в NAP (Network Access Points) ‒ точках доступа к сетям на стороне провайдеров.
Для обращения к DNS-серверу со стороны ПК (DNS-клиента) используется система запроса о разрешении преобразования адреса. Для каждого домена имен создается свой DNS-сервер, более того, для крупных сетей устанавливается иерархия DNS-серверов, каждый из которых хранит только честь имен сети, а не все имена, что позволяет легче масштабировать сети.
Рисунок 5.4 ‒ Иерархия пространства доменных имен
5.4.2 Отображение IP-адресов на локальные адреса в сетях TCP/IP осуществляется следующим образом. При перемещении пакетов по составной сети на каждом маршрутизаторе протокол IP определяет, какому из маршрутизаторов передать пакет. В результате решения этой задачи IP-протоколу становится известен IP-адрес следующего маршрутизатора или конечного узла сети. Для того, чтобы технология локальной сети позволила доставить пакет по назначению необходимо:
1. Упаковать пакет в кадр формата, соответствующего данной технологии, например, Ethernet;
2. Снабдить данный кадр локальным адресом следующего маршрутизатора в этой сети или адресом конечного узла в этой сети, если получатель находится в ней; передать сигнал в линию.
Эта задача решается с помощью протокола разрешения адресов ARP. В результате конфигурирования сети каждый ее интерфейс имеет свой локальный и IP ‒ адрес. Для определения локального адреса узла по его IP –адресу и служит протокол ARP.
На рисунке 5.5 показан фрагмент IP ‒ сети, включающий две сети Ethernet 1 (узлы А, В, С) и Ethernet 2, состоящая из двух узлов D и E. Сети подключены к интерфейсам 1 и 2 маршрутизатора (Router) соответственно. Каждый его сетевой интерфейс имеет IP-адрес и МАС-адрес (IP1, МАС1; IP2, МАС2).
Тот факт, что программные модули узлов сети реализуют функции протокола IP, для краткости будем считать «действием» самого протокола.
Допустим, что IP-протокол узла С направляет пакет узлу D (Рис.5.5). Протокол IP узла С определил, что IP-адрес маршрутизатора ‒ это IP1.
Теперь узел С должен упаковать пакет в формат кадра Ethernet, определить МАС-адрес маршрутизатора и переслать пакет. Для этого он обращается к протоколу ARP , который поддерживает на интерфейсах сетевых адаптеров и маршрутизаторов отдельные адресные таблицы (ARP tabl). В них по мере работы сети накапливается информация о соответствии между IP-адресами и МАС-адресами других интерфейсов данной сети .
Протокол IP узла С отправляет протоколам ARP-интерфейсов узлов A, B, C, и порта 1 маршрутизатора сети запрос: «Какой МАС-адрес соответствует интерфейсу, имеющему адрес IP1?» .
В данном случае протокол ARP маршрутизатора на основании записи в своей ARP-таблице формирует ответ, в котором указывает локальный МАС-адрес своего интерфейса (МАС1) и отправляет его обратно узлу С, используя его локальный адрес ‒ MACC . В ARP-таблицах могут содержаться два типа записей: статические и динамические. Статические записи создаются вручную с помощью утилиты «arp», а динамические обновляются автоматически каждые несколько минут.
Получив адрес, узел С выставляет пакет на общую шину с вложенным в него МАС-адресом порта 1 маршрутизатора ‒ МАС1. Далее маршрутизатор, получив пакет адресованный его порту 1 и прочитав IP-адрес получателя, по аналогичной схеме пересылает пакет IP2 через порт МАС2узлу D сети Ethernet 2.
Рисунок 5.5 ‒ Схема работы протокола разрешения IP-адресов ‒ ARP
5.5 Система доменных имен ‒ DNS
В локальных сетях, состоящих из небольшого числа компьютеров, широко применялись, для удобства их идентификации пользователями, плоские символьные имена, состоящие из последовательности символов не разделенных на части, например, pklab_1. Для установления соответствия между ними и МАС-адресами узлов LAN используется механизм широковещательных запросов. Такой механизм реализован, например, в протоколе NetBIOS и поддерживается сетевой ОС Novell Net Ware. Он долгое время был одним из основных способов назначения плоских символьных имен в LAN.
В протоколе ТСР/IP нет понятия «широковещание», поскольку широковещательные пакеты адресуются только в пределах локальных сетей, и нет способа адресовать их всем пользователям глобальной сети. Поэтому в них используется система доменных имен ‒ имен, иерархически структурированных по уровням, представляющим собой некоторые области охвата пользователей, которые имеют общие признаки.
5.5.1 Схематически работа системы присвоения доменных имен в сетях TCP/IP состоит в следующем.
Ранее созданная для локальных сетей система установления соответствия между аппаратными адресами узлов и их IP-адресами, работающая под управлением протокола ARP, использует широковещательный способ назначения и не работает в крупных сетях, где этот способ рассылки пакетов не поддерживается. В таких сетях используются централизованные службы.
В частности, для преобразования символьных адресов в цифровые IP-адреса Internet существует служба DNS (Domain Name System) ‒ система доменных имен, использующая в своей работе DNS-серверы, которые располагаются в NAP (Network Access Points) ‒ точках доступа к сетям на стороне провайдеров.
Для обращения к DNS-серверу со стороны ПК (DNS-клиента) используется система запроса о разрешении преобразования адреса.
Для каждого домена имен создается свой DNS-сервер, более того, для больших сетей устанавливается иерархия DNS-серверов, каждый из которых хранит только честь имен сети, а не все имена, что позволяет легче масштабировать сети. Каждый DNS-сервер помимо таблицы отображений имен содержит ссылки (в виде IP-адресов) на DNS-серверы своих поддоменов.
Существуют рекурсивная и нерекурсивная процедуры разрешения преобразования символьных имен в цифровые.
При нерекурсивной процедуре запрос DNS-клиента последовательно передается иерархически выстроенным DNS-серверам пока не будет найден последний, в котором хранится числовой IP-адрес, соответствующий запрошенному.
В рекурсивной процедуре при обращении к DNS-серверу возможен незамедлительный ответ в случае, когда запрошенное имя входит в тот же поддомен, что и имя клиента, или когда запрашиваемое соответствие устанавливалось ранее и уже хранится в кэше (в памяти) DNS-сервера.
Если DNS-сервер поддомена при обращении к нему не находит ответ, он обращается к корневому серверу и далее запрос идет по иерархическому дереву вплоть до нужного.
Каждый DNS-сервер помимо таблицы отображений имен содержит ссылки (в виде IP-адресов) на DNS-серверы своих поддоменов.
Существует не рекурсивная процедура разрешения имен, когда запрос DNS-клиента последовательно передается иерархически выстроенным DNS-серверам пока не будет найден последний, в котором хранится соответствующий запрошенному IP-адрес.
В рекурсивной процедуре при обращении к DNS-серверу возможен незамедлительный ответ в случае, когда запрошенное имя входит в тот же поддомен, что и имя клиента, или когда запрашиваемое соответствие устанавливалось ранее и уже хранится в кэше (в памяти) DNS-сервера. Если при обращении DNS-сервер поддомена не находит ответ, он обращается к корневому серверу и далее запрос идет по иерархическому дереву вплоть до нужного.
5.5.2 Служба DNS предназначена не только для прямой операции ‒ нахождения IP-адреса по аппаратному имени ПК, но и для решения обратной задачи ‒ определение DNS-имени по его IP-адресу, например, 108.21.65.173 (IP-адрес) ÷ si.mds.ru (DNS-имя).
Многие приложения и утилиты пытаются определить аппаратный адрес узла по его IP-адресу.
Такая задача решается с помощью организации обратных зон соответствия адресов.
Обратная зона ‒ это система таблиц, в которой хранятся записи соответствия IP-адреса (известного пользователю) его DNS-имени неизвестного для пользователя.
Серверы для обратных зон используют файлы баз данных, не зависящие от файлов основных зон, в которых содержатся записи о прямом соответствии. Например, для хранения всех адресов, которые начинаются с числа 217, выделяется зона 217 со своими серверами имен.
5.5.3 Протокол DHCP (Dynamic Host Configuration Protocol) ‒ протокол динамического присвоения IP-адресов узлам сети предназначен для того, чтобы в процессе работы сети каждому сетевому интерфейсу (ПК или маршрутизатора) был назначен IP-адрес, а также другие параметры стека TCP/IP, например, маска и IP-адрес маршрутизатора по умолчанию, доменное имя ПК, IP-адрес сервера DNC и др.
Протокол DHCP используется с целью автоматизации конфигурирования хостов в составных сетях. Он гарантирует исключение возможности дублирования адресов посредством централизованного управления их распределением. Протокол работает в соответствии с моделью «клиент ‒ сервер», описанной в RFC 2131 и RFC 2132.
В ответ на широковещательный запрос клиента, направленный в сеть, откликается DHCP-сервер и посылает сообщение, которое содержит IP-адрес клиента и другие конфигурационные параметры. Сервер DHCP может работать в следующих режимах:
‒ ручного назначения статических адресов;
‒ автоматического назначения статических адресов
‒ автоматического распределения динамических адресов.
При назначении динамических адресов клиенту выдается адрес из пула наличных IP-адресов на ограниченное время, называемое «сроком аренды».
Когда компьютер, являющийся DHCP-клиентом, удаляется из подсети по истечении срока аренды, назначенный ему адрес автоматически удаляется, а при подключении к другой подсети ему назначается новый адрес.