Чтобы маршрутизатор мог выполнять пересылку трафика группового вещания (multicast forward), на нем необходимо активизировать компонент маршрутизации протокола IGMP.
Кроме того, отдельные (или все) сетевые интерфейсы маршрутизатора должны быть переведены в соответствующие режимы работы (IGMP-маршрутизатора или IGМР-посредника).
Для активизации компонента маршрутизации протокола IGMP необходимо в контекстном меню объекта General (Общие) выбрать пункт New Routing Protocol (Новый протокол маршрутизации). В открывшемся окне нужно выбрать из списка элемент IGMP Router and Proxy. Система выполнит установку всех необходимых компонентов, и в пространстве имен оснастки появится новый контейнер — IGMP.
На следующем этапе следует выбрать сетевые интерфейсы, на которых данный компонент будет активизирован, и определить режим их работы. В процессе добавления интерфейса система предложит определить параметры функционирования IGMP на уровне интерфейса (рис. 15.14). В поле Mode (Режим) необходимо выбрать режим, в котором будет функционировать интерфейс.
Все требуемое аппаратное обеспечение должно быть подключено и активизировано еще до того, как будет выполнено развертывание служб маршрутизации Windows. В зависимости от архитектуры корпоративной сети и требований к ней могут понадобиться следующие аппаратные средства:
Совместимость всех аппаратных средств компьютера, работающего под управлением Windows Server 2003, можно проверить по списку совместимости аппаратных средств (Hardware Compatibility List, HCL) в Интернете на веб-сервере Microsoft (http://www.microsoft.com.hcl).
Для принятия решения о передаче пакетов через межсетевую среду при помощи маршрутизаторов, способных передавать групповой трафик, применяются механизмы групповой маршрутизации. Основанием для принятия решения служит информация о членстве компьютеров в группах. Для обмена между маршрутизаторами информацией о членстве в группах вещания используются специальные протоколы групповой маршрутизации.
Очень легко запутаться в терминологии, применяемой при рассмотрении принципов группового вещания. Под групповой маршрутизацией (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 поддержка протоколов групповой маршрутизации не реализована.
Стандартный способ доставки (одноадресный) предполагает установку соединения "точка-точка", когда пакет доставляется одному получателю. В случае, когда один и тот же пакет должен быть доставлен нескольким получателям, установка нескольких точечных соединений оказывается неэффективным решением (с одной стороны, происходит увеличение сетевого трафика, а с другой, — увеличиваются затраты вычислительных ресурсов на поддержание списка конечных точек). Использование широковещательных рассылок также не является эффективным решением, поскольку широковещательные сообщения не транслируются маршрутизаторами. В качестве альтернативы можно использовать другой метод доставки, когда получателем пакета выступает не один, а несколько получателей. Данный принцип лежит в основе группового вещания (multicasting).
Каждый хост, входящий в группу вещания, помимо уникального IP-адреса. однозначно идентифицирующего хост в пределах сети, получает также некоторый групповой IP-адрес. Этот адрес идентичен для всех хостов, являющихся членами группы. Этот адрес может быть указан в качестве получателя пакета. В этом случае пакет будет получен всеми хостами, входящими в состав группы вещания. Все другие узлы просто проигнорируют данный пакет. В этом заключается существенное отличие группового вещания от широковещательных рассылок — групповой трафик не "беспокоит" хосты, не принадлежащие к группе вещания и не ожидающие группового трафика.
Групповое вещание может использоваться для следующих целей:
обнаружения ресурсов в межсетевом пространстве;
поддержки распределенных сетевых приложений;
поддержки групповых приложений мультимедиа, предполагающих передачу потоковых данных (например, цифрового аудио и видео). В качестве примера приложения, использующего групповое вещание, можно привести Microsoft Media Services.
В приведенном на рис. 15.4 примере три хоста, расположенные в разных подсетях, принадлежат к одной группе вещания. Следует обратить внимание на то, что хотя каждый хост уникально идентифицируется посредством IP-адреса, каждому из них выделен общий групповой адрес. В данном примере предполагается, что трафик группового вещания распространяется свободно в обоих подсетях. На самом деле, задача распространения трафика группового вещания (так же как и в случае одноадресной маршрутизации) в условиях межсетевого взаимодействия решается на уровне маршрутизаторов.
Рассматривая процесс распространения группового трафика в корпоративной сети, следует различать пересылку группового трафика (multicast forwarding) и групповую маршрутизацию (multicast routing).
Под групповой пересылкой понимается процесс перенаправления маршрутизатором трафика группового вещания в подсети, в которых присутствуют хосты, принадлежащие к требуемой группе вещания. При этом групповой трафик не передается маршрутизатором в те подсети, в которых подобные хосты отсутствуют.
Под групповой маршрутизацией понимается процесс распространения информации о составе групп вещания между маршрутизаторами. Фактически, в данном случае, речь идет о работе протоколов маршрутизации применительно к групповому вещанию.
Рассмотрим следующую ситуацию. Корпоративная сеть состоит из нескольких подсетей, соединенных между собой одним маршрутизатором, реализованным на базе Windows Server 2003.
Поскольку в данном сценарии используется всего один маршрутизатор, проблема взаимодействия маршрутизаторов, участвующих в маршрутизации группового трафика, попросту отсутствует. Как следствие, процесс группового вещания может быть реализован средствами службы маршрутизации и удаленного доступа Windows Server 2003. Групповое вещание в данном сценарии может быть реализовано путем использования механизма пересылки трафика группового вещания (multicast forwarding). Для этого все сетевые интерфейсы маршрутизатора переводятся в режим IGМР-маршрутизатора (предварительно должен быть активизирован компонент маршрутизации протокола IGMP) (рис. 15.5).
Рассмотрим процесс настройки службы маршрутизации и удаленного доступа Windows Server 2003 в качестве маршрутизатора. Прежде чем приступить непосредственно к процедуре настройки, администратор должен решить следующие вопросы:
выбрать протокол, для которого необходимо организовать маршрутизацию. Механизмы маршрутизации Windows Server 2003 позволяют организовать маршрутизацию протоколов IP и AppleTalk;
определить, какой способ построения таблиц маршрутизации будет использоваться в корпоративной сети. В небольшой, редко изменяющейся сети наиболее простым и эффективным будет использование статической маршрутизации. В больших распределенных сетях с часто меняющейся структурой, предпочтительно использовать динамическую маршрутизацию;
выбрать протоколы маршрутизации (в случае если используется динамическая маршрутизация). Данный пункт актуален для IP-трафика. Администратор может выбирать из двух протоколов маршрутизации — RIP и OSPF.
Задача поддержания таблицы групповой маршрутизации осуществляется в 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-посредника не обеспечивают выполнение всех функций, реализуемых протоколами групповой маршрутизации, которые могут потребоваться для групповой пересылки и поддержки маршрутизации в ин-трасетях с несколькими маршрутизаторами. Маршрутизатор и посредник могут обеспечить групповую пересылку в указанных условиях, однако ряд ограничений на расположение источников группового трафика не позволяет рекомендовать их использование. В большинстве случаев следует развертывать конфигурацию с применением протоколов групповой маршрутизации.
Согласно терминологии службы маршрутизации и удаленного доступа, под устройством (device) понимается аппаратное или программное обеспечение, предоставляющее порты для установки соединений "точка-точка". Протоколы РРТР или L2TP — примеры виртуальных многопортовых устройств. Чтобы служба маршрутизации и удаленного доступа могла использовать конкретное устройство (порт), нужно разрешить ее функционирование для этого устройства. Для этого необходимо вызвать окно свойств объекта Ports (Порты), расположенного в пространстве имен оснастки Routing and Remote Access. На вкладке Devices (Устройства) следует выбрать требуемое устройство с вызовом по требованию, а затем нажать кнопку Configure (Настроить).
В окне Configure Device (Настройка устройства) (рис. 15.11) необходимо установить флажок Demand-dial routing connections (inbound and outbound) (Подключения по требованию (входящие и исходящие)), а затем нажать кнопку ОК.
Служба маршрутизации и удаленного доступа (Routing and Remote Access Service, RRAS) устанавливается автоматически в процессе установки Windows Server 2003. Однако при этом она остается в неактивном состоянии. Прежде чем эта служба сможет быть использована для маршрутизации сообщений, необходимо ее активизировать и должным образом сконфигурировать. Активизация службы выполняется при помощи специального мастера Routing and Remote Access Server Setup Wizard. Этот мастер кроме собственно активизации позволяет выполнить настройку службы в соответствии со стоящими перед администратором задачами. Если служба уже была активизирована ранее (например, при развертывании сервера удаленного доступа), администратор должен выполнить ручную настройку службы.
В процессе организации межсетевого взаимодействия важное место занимает маршрутизация сообщений между отдельными подсетями. При этом под маршрутизацией понимается процесс доставки сообщения из одной подсети в другую. Данная задача может решаться различными способами. При этом, чем сложнее рассматриваемая система, чем больше подсетей ее образуют, тем более нетривиальным является решение задачи доставки сообщений. Сетевой компонент, выполняющий маршрутизацию пакетов, называется маршрутизатором (router). Маршрутизатор может быть реализован на базе компьютера с несколькими сетевыми интерфейсами, на котором установлено специальное программное обеспечение. В этом случае говорят о программном маршрутизаторе. В другом случае маршрутизатор может быть выполнен в виде отдельного сетевого устройства. Разумеется, наиболее эффективным решением является использование специальных аппаратных маршрутизаторов. В настоящее время лидером на рынке корпоративных маршрутизаторов является компания Cisco, предлагающая высокопроизводительные и надежные устройства. В небольших сетях (таких как сеть небольшого офиса или домашняя сеть), использование аппаратного маршрутизатора может быть экономически необоснованно.
Системы Windows Server 2003 включают в себя механизмы, позволяющие серверу, находящемуся под ее управлением, выступать в качестве программного маршрутизатора. Эти механизмы реализованы в составе Службы маршрутизации и удаленного доступа (Routing and Remote Access Service, RRAS). Хотя в архитектуре Windows Server 2003 основной упор делается на стек протоколов TCP/IP, в состав указанной службы также включена поддержка механизмов маршрутизации стека протоколов AppleTalk.
В рамках службы маршрутизации и удаленного доступа Windows Server 2003 реализованы механизмы, позволяющие организовать маршрутизацию трафика протокола AppleTalk. Данный протокол используется в качестве транспортного механизма в сетях, построенных на базе Apple Macintosh. Благодаря наличию механизмов маршрутизации AppleTalk-трафика компьютер, находящийся под управлением операционной системы Windows Server 2003, может выступать в качестве программного маршрутизатора в среде AppleTalk. Возможности маршрутизации AppleTalk-трафика включают в себя поддержку протокола маршрутизации Routing Table Maintenance Protocol (RTMP).
Поддержка протокола AppleTalk реализована в Windows Server 2003 с целью предоставления возможности сосуществования двух различных платформ в одной сети. Использовать стек протоколов AppleTalk в других ситуациях (например, как средство организации сетевого взаимодействия Windows-хостов) не рекомендуется. Поддержка маршрутизации AppleTalk-трафика не реализована на 64-разрядных версиях операционных систем семейства Windows Server 2003.
До этого момента при обсуждении вопросов маршрутизации сообщений мы предполагали, что все сетевые подключения маршрутизатора являются постоянными. Тем не менее, достаточно часто администраторам приходится иметь дело с коммутируемыми подключениями. В случае использования коммутируемых подключений у администратора имеется две возможности организации маршрутизации.
Рассматривать коммутируемые подключения как постоянные. Администратор устанавливает соединение с удаленным сервером и после этого оно рассматривается как постоянное (вплоть до момента его разрыва). При этом действуют все те принципы маршрутизации, что были описаны ранее. Недостатками данного способа являются высокая удельная стоимость аренды канала связи (после установки соединения канал может не использоваться в течение длительного периода времени), необходимость изменения конфигурации маршрутизаторов до и после создания подключения.
Использовать механизм маршрутизации с вызовом по требованию (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, отвечающий на звонок, должен быть в состоянии отличить клиента, работающего по коммутируемому соединению, от маршрутизатора, звонящего по данному номеру, чтобы установить соединение с вызовом по требованию. Для этого имя учетной записи, посылаемое маршрутизатором, устанавливающим соединение, в процессе аутентификации должно в точности совпадать с именем сетевого интерфейса с вызовом по требованию на маршрутизаторе, отвечающем на звонок.
В зависимости от способа формирования содержимого таблицы маршрутизации различают два вида маршрутизации.
Статическая маршрутизация. Все маршруты прописываются и изменяются администратором системы вручную. Это самый простой способ организации маршрутизации. Однако он подходит только для небольших сетей, изменения в структуре которых происходят достаточно редко. Кроме того, данный способ маршрутизации не годится в случае, когда важно обеспечить высокую надежность межсетевого взаимодействия. Если один из маршрутов окажется по каким-либо причинам недоступен, администратору необходимо будет вручную изменить таблицу маршрутизации на всех маршрутизаторах в сети. До этого момента межсетевое взаимодействие на отдельных участках сети будет невозможно.
Динамическая маршрутизация. Построение таблицы маршрутизации осуществляется посредством специальных протоколов маршрутизации. Участие администратора в этом процессе минимально и сводится к изначальной конфигурации маршрутизаторов. Два наиболее распространенных протокола IP-маршрутизации, используемых в интрасетях, — протоколы RIP (Routing Information Protocol) и OSPF (Open Shortest Path First). Посредством указанных протоколов маршрутизаторы способны информировать друг друга об изменениях в структуре сети. В случае недоступности одного из маршрутов, маршрутизаторы автоматически перестроят свои таблицы маршрутизации и, при возможности, выберут другой маршрут доставки сообщений.
Под многоадресной маршрутизацией понимается маршрутизация трафика группового вещания. Групповое вещание (multicasting) предполагает отправку пакетов, адресованных не одному получателю, а целой группе. Механизм многоадресной маршрутизации позволяет каждому получателю, принадлежащему к определенной группе, получить пакет группового вещания независимо от того, в какой подсети он находится. Прежде чем детально рассмотреть механизмы многоадресной маршрутизации, необходимо ознакомиться с принципами группового вещания.
В то время как маршрутизация с вызовом по требованию может уменьшать издержки на соединение, типичные протоколы маршрутизации полагаются на периодический процесс объявлений, которыми обмениваются маршрутизаторы извещая друг друга о содержимом собственных таблиц маршрутизации. Например, RIP для IP объявляет содержание таблицы маршрутизации каждые 30 секунд на всех интерфейсах. Такое поведение не является проблемой для постоянно подключенных каналов ЛВС или ГВС. В случае коммутируемого соединения подобные периодические объявления будут заставлять маршрутизатор вызывать другой маршрутизатор каждые 30 секунд. Такой подход может свести на нет всю выгоду от использования соединений с вызовом по требованию (поскольку приводит к нежелательному увеличению затрат на аренду коммутируемого канала связи). Выходом из сложившейся ситуации является отказ от использования протоколов маршрутизации в случае использования коммутируемых соединений.
Если для обновления таблиц маршрутизации не используются протоколы маршрутизации, то маршруты должны быть введены в маршрутизатор как статические маршруты. Статические маршруты, соответствующие подсетям, доступным через интерфейс с вызовом по требованию, могут быть созданы администратором вручную или автоматически. Автоматическое создание статических маршрутов для интерфейсов с вызовом по требованию известно как автоматическое статическое обновление (auto-static updates). Механизм автоматического статического обновления реализован в рамках службы маршрутизации и удаленного доступа Windows Server 2003. Этот механизм может использоваться совместно с протоколом маршрутизации RIP для IP, но не может быть использован совместно с OSPF.
По команде администратора маршрутизатор отправляет с интерфейса с вызовом по требованию, сконфигурированного для автоматического статического обновления, специальный запрос через активное соединение маршрутизатору, находящемуся на другой стороне. Запрос включает в себя требование предоставить информацию обо всех маршрутах, содержащихся в его таблице маршрутизации. Получив ответ на запрос, маршрутизатор извлекает из него сведения о маршрутах и автоматически обновляет таблицу маршрутизации, добавляя новые маршруты в качестве статических. Следует заметить, что статические маршруты постоянны. Это означает, что они сохраняются в таблице маршрутизации при любых обстоятельствах, даже в случае отключения интерфейса или перезапуска маршрутизатора.
Процесс автоматического статического обновления предполагает разовый и односторонний обмен информацией о маршрутах. Автоматическое статическое обновление инициируется администратором либо с помощью оснастки Routing and Remote Access, либо посредством утилиты командной строки Netsh, в тот момент, когда соединение с вызовом по требованию находится в активном состоянии. В случае установки соединения с вызовом по требованию автоматическое статическое обновление не выполняется автоматически.
Утилита командной строки Netsh может быть использована для создания пакетных файлов, автоматизирующих инициацию процесса автоматического статического обновления.
Запуск процесса автоматического статического обновления приводит к удалению существующих маршрутов, добавленных в ходе предыдущего автоматического статического обновления. Маршруты удаляются прежде, чем новая информация будет запрошена у соседних маршрутизаторов. Поэтому в ситуации, когда по каким-либо причинам маршрутизатор не получит в ответ на свой запрос новых сведений о маршрутах, маршрутизатор не сможет восстановить маршруты, которые были предварительно удалены. Это может привести к утрате возможности взаимодействия с удаленными сетями.
Рассмотрим другой сценарий. Допустим, корпоративная сеть, так же как и в предыдущем случае, состоит из нескольких подсетей, соединенных между собой одиночным маршрутизатором. При этом один из интерфейсов маршрутизатора связывает корпоративную подсеть с Интернетом (в более общем случае вместо Интернета может выступать любая внешняя сеть). В данном сценарии проблема организации группового вещания осложняется тем фактом, что источником трафика группового вещания могут выступать хосты, расположенные в Интернете. При этом встает вопрос об объявлении членства в группах вещания хостами, расположенными в корпоративной интрасети. Как маршрутизатор Интернета "узнает" об этих хостах и о том, что в корпоративную подсеть должен быть передан определенный трафик группового вещания?
В данном случае задача может быть также решена средствами службы маршрутизации и удаленного доступа Windows Server 2003. Все интерфейсы. соединяющие маршрутизатор с локатьными подсетями, должны быть переведены в режим ЮМР-маршрутизатора. Сетевой интерфейс, соединяющий корпоративный маршрутизатор с маршрутизатором интернет-провайдера, должен быть переведен в режим IGMP-посредника (IGMP-proxy) (рис. 15.6).
При этом предложенная схема работает следующим образом. Хосты объявляют о своей принадлежности к некоторой группе вещания. Эти объявления передаются IGMP-посредником маршрутизатору интернет-провайдера. Маршрутизатор использует данные объявления для построения своей таблицы групповой маршрутизации. Используя некоторый протокол групповой маршрутизации, маршрутизатор интернет-провайдера сообщает эти сведения другим маршрутизаторам. Таким образом, становится возможным передача требуемого группового трафика маршрутизатору интернет-провайдера. Маршрутизатор провайдера передает групповой трафик корпоративному маршрутизатору, который, в свою очередь, передает его хостам интрасети, принадлежащим к требуемым группам вещания.
Под одноадресной маршрутизацией понимается процесс передачи сообщений между подсетями, в котором сообщение адресовано только одному заданному получателю. Вся задача маршрутизации в этом случае сводится к доставке пакета получателю и выбору оптимального маршрута из множества возможных.
Окончательная конфигурация маршрутизируемой сети с вызовом по требованию изображена на рис. 15.8. Указаны все интерфейсы с вызовом по требованию, статические маршруты и учетные записи Windows для офисов в Москве и Санкт-Петербурге.
При помощи пересылки группового трафика маршрутизатор передает пакеты группового вещания в подсети, где имеются хосты, ожидающие групповой трафик, или в том направлении, где имеются хосты, ожидающие этот трафик. Предотвращается передача трафика группового вешания в подсети, где отсутствуют хосты, слушающие групповой трафик. Совершенно очевидно, что .пля выполнения этой операции маршрутизатор должен иметь соответствующие механизмы. Применительно к 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, нельзя рассматривать как протокол групповой маршрутизации.
Отправителя и получателя может разделять произвольное количество маршрутизаторов. При этом процесс передачи сообщения от одного маршрутизатора другому называется "прыжком" (hop). Каждый маршрутизатор обладает информацией о структуре сети на расстоянии одного прыжка. Другими словами, маршрутизатор не обладает информацией о точном местоположении требуемого хоста. В большой сети, да еще и с интенсивно меняющейся структурой (как, например, Интернет), это было бы невозможно. Вместо этого, маршрутизатор обладает информацией о соседних маршрутизаторах и о том, кому из них необходимо передать сообщение для последующей доставки в той или иной ситуации. Эта информация хранится в специальной таблице, которая носит название таблицы маршрутизации (routing table).
Таблицы маршрутизации используются для принятия решения о том, как именно будет доставлено то или иное сообщение. Наличие этих таблиц не является исключительным свойством маршрутизатора. В сети TCP/IP любой хост (даже не являющийся маршрутизатором) может также располагать таблицей маршрутизации, которая используется с целью определения оптимального маршрута передачи сообщений. Так, скажем, если в подсети имеется три маршрутизатора, хост использует таблицу маршрутизации для того, чтобы выбрать из них наиболее оптимальный для доставки сообщения.
Механизм маршрутизации с вызовом по требованию может быть использован для организации пересылки маршрутизируемого трафика через Интернет путем организации виртуальной частной сети (Virtual Private Network, VPN) между двумя абонентами. Две подсети могут организовать маршрутизацию внутреннего трафика через Интернет (в принципе — через любую открытую внешнюю сеть) по защищенному каналу, созданному посредством протоколов туннелирования L2TP или РРТР. Защищенный канал создается каждый раз автоматически, когда появляется трафик, адресованный в заданном направлении. Один из маршрутизаторов, выступающий в качестве VPN-клиента, устанавливает коммутируемое соединение, чтобы дозвониться до интернет-провайдера. После установки соединения маршрутизатор создает защищенный канал (посредством некоторого протокола туннелирования) с маршрутизатором-концентратором, имеющим постоянное соединение с Интернетом. После того как создан защищенный канал (т. е. подключение виртуальной частной сети), процесс взаимодействия двух подсетей реализуется по стандартной схеме маршрутизации с вызовом по требованию.
Пример реализации данного сценария приведен на рис. 15.9.
Рассмотрение процесса настройки маршрутизации с вызовом по требованию лучше всего проводить на примере. Обратимся к рис. 15.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.
По окончании процесса настройки механизма маршрутизации пользователь компьютера с IP-адресом 173.75.73.5 должен иметь возможность установить соединение по запросу с компьютером с IP-адресом 173.75.72.10 и наоборот.
Далее мы рассмотрим процесс ручной настройки механизма маршрутизации с вызовом по требованию. Однако настоятельно рекомендуется использовать Demand Dial Interface Wizard (Мастер интерфейса вызова по требованию), чтобы автоматизировать процесс настройки. Этот мастер выполняет все шаги конфигурации, описанные ниже, кроме создания статического маршрута.
В межсетевой среде каждая подсеть может быть соединена с произвольным количеством других подсетей посредством маршрутизаторов. Суть процесса маршрутизации сводится к тому, что два хоста, разделенных друг с другом любым произвольным количеством маршрутизаторов (другими словами, находящиеся в разных подсетях), могут взаимодействовать друг с другом. Всю организацию процесса доставки пакета от одного хоста другому берут на себя маршрутизаторы. Рассмотрим основные принципы, лежащие в основе процесса маршрутизации сообщений. Сразу оговоримся, что разговор будет идти, прежде всего, о маршрутизации IP-трафика. Подавляющее большинство сетевых служб Windows Server 2003 функционирует на базе стека протоколов TCP/IP, получившего широкое распространение именно благодаря простоте организации межсетевого взаимодействия (как известно, самое большое объединение сетей — Интернет, тоже основывается на этом стеке протоколов). Тем не менее, заметим, что в своей основе принципы маршрутизации являются общими для большинства стеков протоколов.
В зависимости от количества вовлеченных получателей стек протоколов TCP/IP поддерживает два способа маршрутизации: одноадресная и многоадресная маршрутизация. Соответственно, мы рассмотрим принципы маршрутизации применительно к каждому из способов в отдельности.
Используем описанный выше сценарий для того, чтобы рассмотреть процесс установки соединения с вызовом по требованию. Для определенности будем считать, что хост с адресом 173.75.73.5 пытается получить доступ к ресурсам хоста с адресом 173.75.72.10. При этом выполняется следующая последовательность действий:
1. Пакеты от 173.75.73.5, предназначенные для 173.75.72.10, передаются Маршрутизатору 1.
2. Маршрутизатор 1 получает пакет от 173.75.73.5 и проверяет собственную таблицу маршрутизации. Маршрут к 173.75.72.10 предписывает передавать пакеты через интерфейс DD_SPb.
3. Маршрутизатор 1 проверяет состояние интерфейса DD_SPb и обнаруживает его в разъединенном состоянии.
4. Маршрутизатор 1 извлекает информацию о конфигурации интерфейса DD_SPb с вызовом по требованию.
5. Полученная информация используется Маршрутизатором 1 для инициации соединения с вызовом по требованию. Маршрутизатор 1 использует модем, подключенный к СОМ1, чтобы набрать номер (812)765-4321.
6. Маршрутизатор 2 отвечает на входящий вызов.
7. Маршрутизатор 2 запрашивает идентификационную информацию по входящему соединению.
8. Маршрутизатор 1 посылает имя учетной записи пользователя "DD_Moscow" и соответствующий ей пароль.
9. После получения идентификационной информации Маршрутизатор 2 проверяет имя пользователя и пароль в базе данных системы безопасности Windows и определяет, что Маршрутизатор 1 имеет разрешение на установление входящего соединения.
10. Теперь Маршрутизатор 2 должен определить, является ли субъект, установивший входное соединение, сетевым клиентом или маршрутизатором, устанавливающим соединение с вызовом по требованию. Маршрутизатор 2 просматривает список интерфейсов с вызовом по требованию и ищет интерфейс, который соответствует имени пользователя, посланному Маршрутизатором 1 как часть идентификационной информации. Маршрутизатор 2 находит интерфейс с вызовом по требованию "DD_Moscow", который соответствует имени пользователя.
11. Маршрутизатор 2 переводит интерфейс с вызовом по требованию от DD_Moscow в состояние "соединен".
12. Маршрутизатор 1 передает пакет от пользователя с адресом 173.75.73.5 через соединение с вызовом по требованию на Маршрутизатор 2.
13. Маршрутизатор 2 получает пакет и пересылает его хосту с адресом 173.75.72.10.
14. Хост с адресом 173.75.72.10 отправляет на Маршрутизатор 2 ответ на запрос об установлении соединения, сделанный хостом с адресом 173.75.73.5.
15. Маршрутизатор 2 получает пакет, предназначенный для 173.73.75.5, и проверяет таблицу маршрутизации: маршрут к 173.75.73.5 найден, используется интерфейс DD_Moscow.
16. Маршрутизатор 2 проверяет состояние интерфейса DD_Moscow и определяет, что он находится в состоянии "соединен".
17. Маршрутизатор 2 передает пакет Маршрутизатору 1.
18. Маршрутизатор 1 передает пакет пользователю по адресу 173.75.73.5.
Если имя пользователя в идентификационной информации не совпадают с именем соответствующего интерфейса с вызовом по требованию, объект вызова определяется как сетевой клиент, что может привести к проблемам маршрутизации. Допустим, в рассмотренном выше примере Маршрутизатор 1 использует строку "DialUpRouterl" в качестве имени учетной записи пользователя, передаваемого в процессе аутентификации пользователя (предположим также, что DialUpRouterl реально существующая учетная запись, имеющая разрешение на установление входящего соединения). В этой ситуации Маршрутизатор 1 будет распознан как сетевой клиент, а не как маршрутизатор. Пакеты от хоста с адресом 173.75.73.5 будут отправляться хосту с адресом 173.75.72.10, так же как и было описано ранее. Однако ответные пакеты от 173.75.72.10 к 173.75.73.5 не будут доставлены, поскольку Маршрутизатор 2 после проверки таблицы маршрутизации определит, что интерфейс, который необходимо использовать, — DD_Moscow. Но DD_Moscow находится в разъединенном состоянии. В соответствии с конфигурацией для DD_Moscow должен использоваться порт COM2. Однако COM2 в настоящее время используется Маршрутизатором 2 для сетевого клиента (за который ошибочно был принят Маршрутизатор 1). Следовательно, процесс установки соединения для DD_Moscow оканчивается неудачей, и ответные пакеты от 173.75.72.10 к 173.75.73.5 теряются.
В пространстве имен оснастки Routing and Remote Access в контекстном меню объекта Static Routes (Статические маршруты) выберите пункт Show IP Routing Table (Показать таблицу IP-маршрутизации) (рис. 15.15).
В табл. 15.1 перечислены доступные в оснастке Routing and Remote Access категории просматриваемой информации, которые можно получить из контекстного меню соответствующего компонента.
Таблица 15.1. Категории просматриваемой информации