Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Подробно_маршрутизация

.pdf
Скачиваний:
30
Добавлен:
28.05.2015
Размер:
795.38 Кб
Скачать

В более сложном сценарии для объединения множества подсетей потребуется несколько маршрутизаторов. В большинстве случаев этот сценарий может быть также решен при помощи программных маршрутизаторов на базе Windows Server 2003. При этом необходимо будет использовать специализированные протоколы маршрутизации (либо, в случае статической маршрутизации, сконфигурировать на всех маршрутизаторах вручную таблицы маршрутизации).

Пример рассматриваемого сценария изображен на рис. 3. В предложенной конфигурации имеются три сети (Сети А, В, и С) и два маршрутизатора. Маршрутизатор 1 подключен к Сетям А и В, Маршрутизатор 2 — к Сетям В и С. Маршрутизатор 1 должен известить Маршрутизатор 2 о том, что Сеть А может быть достигнута через Маршрутизатор 1, а Маршрутизатор 2 должен сообщить Маршрутизатору 1, что Сеть С может быть достигнута через Маршрутизатор 2. Маршрутизаторы обменяются этой информацией автоматически, в случае, если используются протоколы маршрутизации, например RIP или OSPF. Когда пользователь в Сети А хочет установить соединение с пользователем в Сети С, компьютер пользователя в Сети А передает пакет на Маршрутизатор 1. Маршрутизатор 1 затем передает пакет Маршрутизатору 2. Тот, в свою очередь, передает пакет далее компьютеру пользователя в Сети С.

Рис. 3. Сценарий с двумя маршрутизаторами и тремя сетями

Многоадресная маршрутизация

Под многоадресной маршрутизацией понимается маршрутизация трафика группового вещания. Групповое вещание (multicasting) предполагает отправку пакетов, адресованных не одному получателю, а целой группе. Механизм многоадресной маршрутизации позволяет каждому получателю, принадлежащему к определенной группе, получить пакет группового вещания независимо от того, в какой подсети он находится. Прежде чем детально рассмотреть механизмы многоадресной маршрутизации, необходимо ознакомиться с принципами группового вещания.

Групповое вещание

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

происходит увеличение сетевого трафика, а с другой, — увеличиваются затраты вычислительных ресурсов на поддержание списка конечных точек). Использование широковещательных рассылок также не является эффективным решением, поскольку широковещательные сообщения не транслируются маршрутизаторами. В качестве альтернативы можно использовать другой метод доставки, когда получателем пакета выступает не один, а несколько получателей. Данный принцип лежит в основе группового вещания (multicasting).

Каждый хост, входящий в группу вещания, помимо уникального IP-адреса. однозначно идентифицирующего хост в пределах сети, получает также некоторый групповой IPадрес. Этот адрес идентичен для всех хостов, являющихся членами группы. Этот адрес может быть указан в качестве получателя пакета. В этом случае пакет будет получен всеми хостами, входящими в состав группы вещания. Все другие узлы просто проигнорируют данный пакет. В этом заключается существенное отличие группового вещания от широковещательных рассылок — групповой трафик не "беспокоит" хосты, не принадлежащие к группе вещания и не ожидающие группового трафика.

Групповое вещание может использоваться для следующих целей:

обнаружения ресурсов в межсетевом пространстве;

поддержки распределенных сетевых приложений;

поддержки групповых приложений мультимедиа, предполагающих передачу потоковых данных (например, цифрового аудио и видео). В качестве примера приложения, использующего групповое вещание, можно привести Microsoft Media

Services.

Вприведенном на рис. 4 примере три хоста, расположенные в разных подсетях, принадлежат к одной группе вещания. Следует обратить внимание на то, что хотя каждый хост уникально идентифицируется посредством IP-адреса, каждому из них выделен общий групповой адрес. В данном примере предполагается, что трафик группового вещания распространяется свободно в обоих подсетях. На самом деле, задача распространения трафика группового вещания (так же как и в случае одноадресной маршрутизации) в условиях межсетевого взаимодействия решается на уровне маршрутизаторов.

Рис. 4. Групповое вещание

Рассматривая процесс распространения группового трафика в корпоративной сети, следует различать пересылку группового трафика (multicast forwarding) и групповую маршрутизацию (multicast routing).

Под групповой пересылкой понимается процесс перенаправления маршрутизатором

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

Под групповой маршрутизацией понимается процесс распространения информации о составе групп вещания между маршрутизаторами. Фактически, в данном случае, речь идет о работе протоколов маршрутизации применительно к групповому вещанию.

Пересылка группового трафика

При помощи пересылки группового трафика маршрутизатор передает пакеты группового вещания в подсети, где имеются хосты, ожидающие групповой трафик, или в том направлении, где имеются хосты, ожидающие этот трафик. Предотвращается передача трафика группового вешания в подсети, где отсутствуют хосты, слушающие групповой трафик. Совершенно очевидно, что .пля выполнения этой операции маршрутизатор должен иметь соответствующие механизмы. Применительно к Windows Server 2003 поддержка операции пересылки группового трафика реализуется как на уровне сетевых интерфейсов, так и на уровне службы маршрутизации.

На уровне сетевых интерфейсов поддержка группового вещания реализуется в рамках стека протоколов TCP/IP. Процесс передачи группового трафика регламентируется специальным протоколом, являющимся частью данного стека — Internet Group Management Protocol (JGMP, Межсетевой протокол управления группой). В целом, компоненты стека протоколов TCP/IP реализуют следующие функции групповой пересылки:

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

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

Приложения на компьютере, работающем под управлением Windows Server 2003, генерирующие групповой трафик, должны создавать IP-пакеты с соответствующим групповым IP-адресом, таким же, как IP-адрес получателя. Соответственно, приложения, получающие групповой трафик, должны сообщить модулю протокола TCP/IP, что они слушают весь трафик в ожидании указанного группового IP-адреса.

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

Для работы механизма пересылки группового трафика маршрутизатор должен отвечать следующим требованиям:

прослушивать весь групповой трафик во всех подсетях. Применительно к маршрутизатору под управлением Windows Server 2003 соблюдение этого требования реализуется на уровне сетевых интерфейсов. Принятие решения о

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

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

прослушивать все подсети в ожидании специальных сообщений IGMP Host Membership Report (сообщение о членстве). Эти сообщения рассылаются членами групп вещания, объявляющими используемые ими групповые адреса. Маршрутизатор должен отслеживать групповые адреса, которые прослушиваются в прилегающих подсетях, и обновлять таблицу групповой маршрутизации;

использовать специальный протокол групповой маршрутизации, чтобы извещать другие маршрутизаторы об обнаруженных членах групп вещания. Служба маршрутизации и удаленного доступа Windows Server 2003 не включает в себя реализации протокола групповой маршрутизации. Тем не менее, независимые фирмы-разработчики могут поставлять собственные реализации протокола маршрутизации, используя имеющийся API службы маршрутизации и удаленного доступа.

Применительно к Windows Server 2003 задача пересылки группового трафика решается посредством специального компонента маршрутизации протокола IGMP. Этот компонент реализован в рамках службы маршрутизации и удаленного доступа (Routing and Remote Access Service) и отвечает за отслеживание членства хостов в группе многоадресного вещания. Компонент маршрутизации IGMP прослушивает трафик в ожидании сообщений IGMP о членстве в локальных подсетях и собирает информацию в виде списка адресатов, идентификаторов сети и соответствующих групп. Чтобы убедиться в том, что компьютеры прослушивают свой зарегистрированный групповой адрес, маршрутизатор периодически посылает запрос в каждую подсеть — ответом на запрос являются сообщения о членстве в группах. Если в одной сети находится несколько маршрутизаторов, то один маршрутизатор выбирается (методом "голосования") среди них для периодической рассылки всех запросов.

Примечание

Компонент маршрутизации протокола IGMP, реализованный в рамках службы маршрутизации и удаленного доступа Windows Server 2003, нельзя рассматривать как протокол групповой маршрутизации.

Компонент маршрутизации протокола IGMP

Задача поддержания таблицы групповой маршрутизации осуществляется в Windows Server 2003 посредством специального компонента маршрутизации протокола IGMP, который реализован в рамках службы маршрутизации и удаленного доступа. С точки зрения протокола 1GMP каждый сетевой интерфейс, для которого активизирован этот компонент, может функционировать в одном из двух режимов:

режим IGMP-маршрутизатора (IGMP router mode). В режиме IGMPмаршрутизатора сетевой интерфейс способен прослушивать подсети в ожидании специальных объявлений хостов об их членствах в группах вещания (IGMP Host

Membership Report);

режим IGMP-посредника (IGMP proxy mode). Сетевой интерфейс, находящийся в режиме IGMP-посредника, осуществляет ретрансляцию сообщений о членстве (IGMP Host Membership Report), приходящих на другие интерфейсы системы, находящиеся в режиме IGMP-маршрутизатора. Вышестоящий маршрутизатор, находящийся в подсети, в которой расположен IGMP-proxy, получает сообщения о членстве хостов в различных группах вещания от IGMP-proxy и добавляет его к собственным таблицам групп. Таким образом, вышестоящий маршрутизатор получает информацию о том, что пакеты, адресованные определенным группам вещания, необходимо передавать через IGMP-proxy.

Внимание

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

Групповая маршрутизация

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

Внимание

Очень легко запутаться в терминологии, применяемой при рассмотрении принципов группового вещания. Под групповой маршрутизацией (multicast routing) понимается процесс взаимодействия маршрутизаторов, в результате которого происходит обмен информацией о хостах, принадлежащих к различным группам вещания. В результате этого обмена каждый маршрутизатор обладает информацией о распределении в рамках корпоративной сети хостов, принадлежащих к некоторой группе вещания. Благодаря этому маршрутизатор может отправлять пакеты группового вещания в направлении, в котором находятся хосты, принадлежащие к требуемой группе (даже если прилегающая подсеть непосредственно этих хостов не содержит).

Примеры протоколов групповой маршрутизации — Distance Vector Multicast Routing Protocol (Групповой протокол маршрутизации на основе вектора расстояния, DVMRP),

Multicast Extensions to OSPF (Групповые расширения к OSPF, MOSPF), Protocol

Independent Multicast-Spare Mode (Разреженный режим группового вещания, не зависящего от протокола, PIM-SM), Protocol Independent Multicast-Dense Mode (Плотный режим группового вещания, не зависящего от протокола, PIM-DM).

В среде Windows Server 2003 поддержка протоколов групповой маршрутизации не реализована.

Сценарии развертывания многоадресной маршрутизации

Хотя, как уже неоднократно упоминалось, в Windows Server 2003 отсутствует реализация протоколов групповой маршрутизации, в определенных ситуациях средств операционной системы (компонент маршрутизации протокола IGMP) может быть достаточно для развертывания в сети механизма группового вещания. При этом возможны следующие сценарии:

интрасеть с одним маршрутизатором;

интрасеть и Интернет.

Далее мы рассмотрим эти сценарии более подробно.

Интрасеть с одним маршрутизатором

Рассмотрим следующую ситуацию. Корпоративная сеть состоит из нескольких подсетей, соединенных между собой одним маршрутизатором, реализованным на базе Windows

Server 2003.

Рис. 5. Организация группового вещания в сценарии "интрасеть с одним маршрутизатором"

Поскольку в данном сценарии используется всего один маршрутизатор, проблема взаимодействия маршрутизаторов, участвующих в маршрутизации группового трафика, попросту отсутствует. Как следствие, процесс группового вещания может быть реализован средствами службы маршрутизации и удаленного доступа Windows Server 2003. Групповое вещание в данном сценарии может быть реализовано путем использования механизма пересылки трафика группового вещания (multicast forwarding). Для этого все сетевые интерфейсы маршрутизатора переводятся в режим IGМРмаршрутизатора (предварительно должен быть активизирован компонент маршрутизации протокола IGMP) (рис. 5).

Одиночная интрасеть и Интернет

Рассмотрим другой сценарий. Допустим, корпоративная сеть, так же как и в предыдущем

случае, состоит из нескольких подсетей, соединенных между собой одиночным маршрутизатором. При этом один из интерфейсов маршрутизатора связывает корпоративную подсеть с Интернетом (в более общем случае вместо Интернета может выступать любая внешняя сеть). В данном сценарии проблема организации группового вещания осложняется тем фактом, что источником трафика группового вещания могут выступать хосты, расположенные в Интернете. При этом встает вопрос об объявлении членства в группах вещания хостами, расположенными в корпоративной интрасети. Как маршрутизатор Интернета "узнает" об этих хостах и о том, что в корпоративную подсеть должен быть передан определенный трафик группового вещания?

В данном случае задача может быть также решена средствами службы маршрутизации и удаленного доступа Windows Server 2003. Все интерфейсы. соединяющие маршрутизатор с локатьными подсетями, должны быть переведены в режим ЮМР-маршрутизатора. Сетевой интерфейс, соединяющий корпоративный маршрутизатор с маршрутизатором интернет-провайдера, должен быть переведен в режим IGMP-посредника (IGMP-proxy)

(рис. 6).

При этом предложенная схема работает следующим образом. Хосты объявляют о своей принадлежности к некоторой группе вещания. Эти объявления передаются IGMPпосредником маршрутизатору интернет-провайдера. Маршрутизатор использует данные объявления для построения своей таблицы групповой маршрутизации. Используя некоторый протокол групповой маршрутизации, маршрутизатор интернет-провайдера сообщает эти сведения другим маршрутизаторам. Таким образом, становится возможным передача требуемого группового трафика маршрутизатору интернет-провайдера. Маршрутизатор провайдера передает групповой трафик корпоративному маршрутизатору, который, в свою очередь, передает его хостам интрасети, принадлежащим к требуемым группам вещания.

Рис. 6. Организация группового вещания в сценарии "интрасеть и Интернет"

Маршрутизация с вызовом по требованию

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

Рассматривать коммутируемые подключения как постоянные. Администратор устанавливает соединение с удаленным сервером и после этого оно рассматривается как постоянное (вплоть до момента его разрыва). При этом действуют все те принципы маршрутизации, что были описаны ранее. Недостатками данного способа являются высокая удельная стоимость аренды канала связи (после установки соединения канал может не использоваться в течение длительного периода времени), необходимость изменения конфигурации маршрутизаторов до и после создания подключения.

Использовать механизм маршрутизации с вызовом по требованию (demand-dial routing, dial-on-demand routing). Этот механизм реализован в рамках службы маршрутизации и удаленного доступа Windows Server 2003. Данный механизм позволяет осуществлять маршрутизацию сообщений через интерфейс с вызовом по требованию (demand-dial interface). Использование механизма маршрутизации с вызовом по требованию позволяет существенно снизить затраты на аренду

коммутируемых канатов связи и упростить процесс маршрутизации сообщений через коммутируемые соединения.

Рассмотрим более подробно принципы, лежащие в основе данного механизма. Подключение с вызовом по требованию (demand-dial connection) устанавливается в ситуации, когда на интерфейс приходит пакет, предназначенный хосту, находящемуся в удаленной подсети (к которой этот интерфейс подключен). Если в течение определенного времени других данных для передачи удаленному хосту не поступает, соединение прерывается. Соединение с вызовом по требованию позволяет эффективно использовать коммутируемые телефонные линии.

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

Фильтры вызова по требованию (demand-dial filters). При помощи фильтров вызова по требованию администратор определяет тип трафика, который может инициировать соединение. Фильтры вызова по требованию отделены от фильтров IP-пакетов, которые используются для определения того, какой трафик может исходить из интерфейса и поступать на него только после того, как соединение установлено.

Разрешенное время вызова (dial-out hours). Установка времени входящих звонков позволяет определить промежуток времени, в течение которого маршрутизатору разрешается устанавливать соединение с вызовом по требованию. Например, администратор может разрешить установку соединения исключительно в ночное время, когда стоимость аренды линий минимальна. В это время планировщики задач могут запускать процедуру синхронизации реплик баз данных.

Концепция маршрутизации с вызовом по требованию проста и очевидна. Однако настройка механизма маршрутизации с вызовом по требованию представляет собой сложную задачу. В процессе настройки администратору необходимо решить следующие вопросы:

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

аутентификация и авторизация вызывающей стороны. Любой вызывающий маршрутизатор должен быть аутентифицирован. Процесс аутентификации предполагает передачу вызывающей стороной совокупности идентифицирующей информации (в данном случае сведения об учетной записи Windows) непосредственно в течение процесса установки соединения. Эта информация проверяется отвечающим маршрутизатором. Процесс авторизации предполагает проверку полномочий на подключение к вызываемому серверу у пользователя, в контексте которого происходит подключение;

конфигурирование каждой стороны. Администратор должен выполнить соответствующее конфигурирование каждой из сторон соединения, даже если всегда осуществлять вызов будет только один из них. Конфигурирование только одной стороны соединения приведет к тому, что пакеты могут успешно передаваться только в одном направлении. Нормальная связь требует, чтобы информация передавалась в обоих направлениях;

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

статические маршруты. Эта операция может быть выполнена как вручную, так и при помощи автоматического статического обновления.

Примечание

Механизмы маршрутизации и механизмы удаленного доступа совмещены в рамках одной службы Windows Server 2003. И клиент удаленного доступа, работающий по коммутируемому соединению, и маршрутизатор могут вызывать один и тот же телефонный номер. Маршрутизатор, находящийся под управлением Windows Server 2003, отвечающий на звонок, должен быть в состоянии отличить клиента, работающего по коммутируемому соединению, от маршрутизатора, звонящего по данному номеру, чтобы установить соединение с вызовом по требованию. Для этого имя учетной записи, посылаемое маршрутизатором, устанавливающим соединение, в процессе аутентификации должно в точности совпадать с именем сетевого интерфейса с вызовом по требованию на маршрутизаторе, отвечающем на звонок.

Пример настройки маршрутизации с вызовом по требованию

Рассмотрение процесса настройки маршрутизации с вызовом по требованию лучше всего проводить на примере. Обратимся к рис. 7, на котором изображена конфигурация гипотетической маршрутизируемой сети.

Рис. 7. Пример маршрутизации с вызовом по требованию

Вмосковском офисе установлен компьютер, работающий под управлением Windows Server 2003. Этот компьютер сконфигурирован в качестве сервера удаленного доступа и маршрутизатора с вызовом по требованию. Все компьютеры в московском офисе находятся в подсети 173.75.73.0 (маска подсети 255.255.255.0). К маршрутизатору в Москве (далее называемому Маршрутизатором 1) через СОМ 1-порт подключен модем, доступ к которому осуществляется по телефону (095)123-4567.

Всанкт-петербургском офисе также установлен компьютер, находящийся под управлением Windows Server 2003 и функционирующий в качестве сервера удаленного доступа и маршрутизатора с вызовом по требованию. Все компьютеры в санктпетербургском офисе находятся в подсети 173.75.72.0 (маска подсети 255.255.255.0). Через СОМ2-порт к санкт-петербургскому маршрутизатору (далее называемому Маршрутизатором 2) подключен модем, использующий номер телефона (812)765-4321 begin_of_the_skype_highlighting (812)765-4321 end_of_the_skype_highlighting.

По окончании процесса настройки механизма маршрутизации пользователь компьютера с IP-адресом 173.75.73.5 должен иметь возможность установить соединение по запросу с компьютером с IP-адресом 173.75.72.10 и наоборот.