Мельников Д. А. - Организация и обеспечение безопасности информационно-технологических сетей и систем - 2012

для задач отладки и тестирования и не является адресом никакой сети, а маршрутизаторы никогда не обрабатывают его.

Групповой адрес (multicast address) в отличие от широковеща­ тельного, применяется при обращении к выделенной группе 1Р-узлов (но не ко всем IP-узлам) некоторой физической сети или группы се­ тей. В этом случае используются адреса класса D (см. рис. 10.3). Групповая адресация в TCP/IP регламентируется протоколом Inter­ net Group Management Protocol (IGMP, RFC-1112), входящим состав­ ной частью в IP.

Групповой адрес может объединять IP-узлы разных физиче­ ских сетей. Это достигается путем использования специальных про­ токолов групповой маршрутизации.

Каждый IP-узел может (при определенных административных полномочиях) в любой момент подключиться к выделенной адрес­ ной группе или выйти из нее.

Групповые адреса назначаются ЦСИ и делятся на два класса: постоянные - для непрерывно существующих групп (well-known ad­ dresses, хорошо известные адреса), и временные - для организуемых на некоторое время групп (transient multicast groups).

Распространение групповых сообщений по Internet ограничи­ вается временем жизни (time live) IP-пакета.

В основном ЦСИ распределяет только адреса физических се­ тей (номер сети), оставляя функции назначения адресов IP-узлам за администрациями подсетей, подключенных к Internet. Автономные корпоративные IP-сети могут самостоятельно решать задачи адрес­ ной администрации.

10.4. Преобразование 1Ру4-адресов в физические адреса оконечных устройств

Концепция Internet-сети, объединяющей разнородные по ти­ пам аппаратно-программных средств и протоколам физические се­ ти, требует установления жесткого соответствия IP-адресов и физи­ ческим адресам оконечных устройств.

Задачу определения физического адреса IP-узла по его IPадресу решают два протокола: Address Resolution Protocol (ARP, RFC-826) и Reverse Address Resolution Protocol (RARP, RFC-903), вхо­ дящие в IP в виде составных частей.

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

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

Этот алгоритм приемлем для случая, когда узел А «знает» свой IP-адрес. В противном случае, когда узел А является, например, без­ дисковой рабочей станцией, у которой только что включили пита­ ние и она ничего не знает ни о себе, ни об окружающих и не может произвести дистанционную загрузку операционной системы, «спа­ сает» протокол RARP. Узел А широковещательно вызывает обслу­ живающий его сервер, указывая в запросе свой физический адрес (при этом узел А может даже не знать адреса сервера). В сети всегда есть по меньшей мере один обслуживающий такие запросы сервер («RARP-сервер»), который распознает запрос от рабочей станции, выбирает из некоторого списка свободный IP-адрес и передает узлу А сообщение, включающее IP-адрес, динамически выделенный узлу А, и другую необходимую информацию. При таком алгоритме вы­ ход из строя единственного в сети RARP-сервера очень «нежелате­ лен», поэтому протокол RARP поддерживает несколько серверов в сети, «подстраховывая» себя.

115

Рис. 11.2. Классификация алгоритмов маршрутизации

Блок-схема алгоритма маршрутизации пакетов в узле IP по­ казана на рис. 11.1. Центральным элементом этой схемы является маршрутизационный вычислитель. На его вход поступают пакеты от вышележащих уровней (протоколы TCP, UDP), от системы раз­ решения конфликтных ситуаций - Internet Control Message Protocol (например, контрольное сообщение о потере пакета), от нижележа­ щих уровней через канальный (физический) интерфейс.

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

Статическая маршрутизация в Internet. Статическая мар­ шрутизация (рис. 11.2) жестко определяет заданные маршрутные таблицы. Наиболее приемлема она для IP-узлов, работающих в не­ больших сетях, поскольку IP-узел не должен тратить много «сил» на задачи маршрутизации. Маршрутную таблицу в нем составля­ ют как небольшой список, включающий IP-узлы «соседи» и «мар­ шрутизатор по умолчанию» (default gateway), которому IP-узел и отдает все пакеты, маршрутизация которых вызывает у него какиелибо затруднения. Этот же «алгоритм маршрутизации на основе неполной информации» применяется при взаимодействии мар­ шрутизаторов. Маршрутизатор, обслуживающий, например, ло­ кальную сеть, обязан знать все о своей локальной сети, однако ин­ формацией о внешних сетях он может и не обладать, обращаясь при необходимости к внешним маршрутизаторам, владеющим этой информацией.

Динамическая маршрутизация в Internet. Сущность этого вида маршрутизации заключается в обновлении и корректировке информации в маршрутных таблицах конкретного IP-узла (или маршрутизатора) на основе обмена служебной информацией со смежными узлами. Реализует алгоритмы динамической маршрути­ зации программа «routed» - так называемый маршрутизационный системный процесс (в ОС UNIX такой процесс называют «демоном», запускаемый при загрузке ядра ОС и работающий в фоновом ре­ жиме вплоть до выключения машины).

Решение задачи маршрутизации как поиска оптимального пу­ ти доставки информации весьма непростое ввиду деления маршру­ тизаторов на базовые (core gateways), подключаемые непосредст­ венно к высокоскоростным магистральным каналам, и прочие, об­ служивающие произвольным образом соединенные подсети, так на­ зываемые автономные системы (autonomous systems). Эта задача ус­ ложняется и тем, что маршрутизация в сетях IP осуществляется в условиях некоторой априорной неопределенности (на основе не­ полной информации, так как нельзя внести в таблицу маршрутиза­

ции всю информацию о сети из-за глобальности последней), а по­ тому достижимость (reachability) некоторого узла «не очевидна». За­ дачи распространения информации о достижимости узлов сети (устранение неопределенности) решают два протокола: Exterior Ga­ teway Protocol (EGP, RFC-904) и пришедший ему на смену Border Ga­ teway Protocol (BGP, RFC-1771).

При выборе маршрута помимо получения информации о дос­ тижимости узла необходимо оптимизировать путь к нему. Задачу оптимизации в Internet решает ряд протоколов динамической мар­ шрутизации, которые можно разделить на два основных класса: ос­ нованные на подсчете промежуточных ретрансляций (hop count) и основанные на знании полной топологии сети (SPF-протоколы, Shortest Path First).

Протоколы на основе подсчета промежуточных ретрансляций (первый класс) вычисляют наиболее короткие пути распростране­ ния, определяя число промежуточных маршрутизаторов на пути передачи пакета от данного маршрутизатора до получателя. Это решение традиционно было первым, но оно не оптимально, так как не учитывает реальную пропускную способность линий связи. На основе подсчета числа ретрансляций работают такие распростра­ ненные протоколы динамической маршрутизации, как Gateway Ga­ teway Protocol (GGP, RFC-823), обеспечивающий обмен информаци­ ей между высокопроизводительными базовыми (внешними) мар­ шрутизаторами (core, exterior gateways), подключаемыми непосред­ ственно к высокоскоростным магистральным каналам сетей (back­ bones), и Routing Information Protocol (RIP, RFC-1058), решающий ту же задачу для менее значимых маршрутизаторов (interior gateways).

К протоколам второго типа (второй класс) относится протокол HELLO, вычисляющий оптимальный путь на основе измерения ми­ нимального времени задержки передачи пакетов, а также усовер­ шенствованный протокол OSPF (Open SPF, RFC-1583), который пре­ дусматривает ряд дополнительных возможностей:

овычисление оптимальных маршрутов для конкретных видов обслуживания;

«аутентификацию маршрутизаторов, распространяющих мар­ шрутную информацию;

овыравнивание нагрузки сети (load balancing);

омаршрутизацию в подсетях;

®минимизацию времени поиска информации при широкове­ щательных вызовах;

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

11.2. Протокол обмена маршрутной информацией (RIP)

Этот протокол маршрутизации (RFC-1058, RIP версия 1 - RIPvl) предназначен для сравнительно небольших и преимущественно од­ нородных сетей (алгоритм Беллмана-Форда). Протокол разработан в университете Калифорнии (Беркли), базируется на разработках фир­ мы Ксерокс (Xerox) и реализует те же принципы (распределенная адаптивная маршрутизация, см. п. 3.2), что и программа маршрутиза­ ции, используемая в четвёртой версии ОС «BSD UNIX». Маршрут в данном протоколе характеризуется «вектором расстояния» до 1Р-узла назначения. Предполагается, что каждый маршрутизатор является от­ правной точкой нескольких маршрутов до сетей, с которыми он свя­ зан. Описания этих маршрутов хранится в маршрутной таблице. Таб­ лица маршрутизации RIPvl-протокола содержит по одной записи на каждый маршрут. Запись должна включать в себя следующие поля:

оIP-адрес места назначения;

ометрика маршрута (от 1 до 15; число ретрансляционных уча­ стков до места назначения);

•IP-адрес ближайшего маршрутизатора (шлюза, gateway) по маршруту к месту назначения;

отаймеры маршрута.

Первые два поля образуют вектор расстояния (место назначе­ ние - направление; метрика - модуль вектора). С периодичностью в 30 сек, каждый маршрутизатор в широковещательном режиме пе­ редает копию своей маршрутной таблицы всем соседним (ближай­ шим) маршрутизаторам, с которыми связан непосредственно. Мар­ шрутизатор/ получатель просматривает таблицу, и если в таблице присутствует новый путь или сообщение о более коротком маршру­ те, или произошли изменения длин пути, эти изменения фиксиру­ ются получателем в своей маршрутной таблице. RIPvl-протокол не способен решать следующие проблемы маршрутизации:

1.Петлевые маршруты. Так как в RIP-протоколе не реализованы способы выявления замкнутых (петлевых) маршрутов, необхо­ димо, либо «слепо» верить ближайшим маршрутизаторам («соседям»), либо принимать меры для блокировки возникно­ вения таких маршрутов.

2.Возникновение перегрузок в сети. Решение этой проблемы возлагается на системного администратора.

3.Медленное распространение маршрутной информации по сети создает проблемы при динамичном изменении загрузки сети («система не успевает» за изменениями). Малое предельное зна­ чение метрики улучшает сходимость, но не устраняет проблему.

4.«1Ру4-адрес» («IP address») - 32-битовое поле, содержащее IPv4адрес получателя;

5.«Метрика» («metric») - 32-битовое поле, содержащее значение метрики от 1 до 15 (включительно).

Рис. 11.3. Формат RIPvl-сообщения

Водном RIPvl-сообщении может присутствовать информация

о25 маршрутах (25 1Ру4-адресов). RIPvl-протокол достаточно прост, однако имеет ряд существенных недостатков:

а) не работает с адресами подсетей; б) требует много времени для восстановления связи после сбоя в

маршрутизаторе (несколько минут); в) число ретрансляционных участков важный, но не единствен­

ный параметр маршрута, а максимальное значение метрики 15 шагов - не предел для современных сетей.

RIPv2-пpoтoкoл (RFC-1388) является новой версией RIPпротокола, которая в дополнение к широковещательному режиму передачи сообщений поддерживает режим групповой адресации, что позволяет работать с масками подсетей. На рис. 11.4 представлен формат Р1Ру2-сообщения, который содержит следующие поля:

«М етри ках > [4 б ай та]

Рис. 11.4. Формат К1Ру2-сообщения

о«Команда» («command») - 8-битовый определитель, который идентифицирует тип команды. Имеет кодировку, как и в формате RIPvl-сообщения;

о«Версия» («version») - 8-битовое поле, которое идентифициру­ ет версию RIPv2-npoTOKona (для ШРу2-протокола - «2»);

о«Номер прикладного процесса маршрутизации» («Routing Domain») - 16-битовое поле, идентифицирующее прикладной процесс маршрутизации, для которого предназначено данной RIPv2-coo6ni;eHHe;

о«Идентификатор семейства адресов» («address family identifier») - 16-битовое поле, идентифицирующее систему ад­ ресации. Для сетей Internet это поле содержит значение «2»;

о«Маршрутный ярлык» («Route Tag») - 16-битовое поле, содер­ жащее кодовую последовательность, которая используется EGP-протоколом (Exterior Gateway Protocol, RFC-904);

о«1Ру4-адрес» («IP address») - 32-битовое поле, содержащее IPv4адрес получателя;

в«Маска подсети» («Subnet Mask») - 32-битовое поле, содержа­ щее маску подсети, в которой присутствует сетевой объект с указанным 1Ру4-адресом;

о«Следующий ближайший 1Ру4-адрес» («Next Нор») - 32-битовое поле, содержащее 1Ру4-адрес конечного получателя этого Р1Ру2-сообщения;

©«Метрика» («metric») - 32-битовое поле, содержащее значение метрики от 1 до 15 (включительно).

I_____________________________

Рис. 11.5. Формат К1Ру2-сообщения для аутентификации

В RIPv2-npoTOKone также предусмотрена защита от несанк­ ционированного доступа, для чего вводится специальный формат К1Ру2-сообщения для аутентификации (рис.11.5), в котором исполь­ зуется следующая кодировка:

о«Идентификатор сообщения» («OxFFFF») - 16-битовый опре­ делитель, который идентифицирует Р1Ру2-сообщение для ау­ тентификации;

о«Тип аутентификации» («Authentication Туре») - 16-битовое поле, которое идентифицирует тип аутентификации. В на-