В процессе организации межсетевого взаимодействия важное место занимает маршрутизация сообщений между отдельными подсетями. При этом под маршрутизацией понимается процесс доставки сообщения из одной подсети в другую. Данная задача может решаться различными способами. При этом, чем сложнее рассматриваемая система, чем больше подсетей ее образуют, тем более нетривиальным является решение задачи доставки сообщений. Сетевой компонент, выполняющий маршрутизацию пакетов, называется маршрутизатором (router). Маршрутизатор может быть реализован на базе компьютера с несколькими сетевыми интерфейсами, на котором установлено специальное программное обеспечение. В этом случае говорят о программном маршрутизаторе. В другом случае маршрутизатор может быть выполнен в виде отдельного сетевого устройства. Разумеется, наиболее эффективным решением является использование специальных аппаратных маршрутизаторов. В настоящее время лидером на рынке корпоративных маршрутизаторов является компания Cisco, предлагающая высокопроизводительные и надежные устройства. В небольших сетях (таких как сеть небольшого офиса или домашняя сеть), использование аппаратного маршрутизатора может быть экономически необоснованно.
Системы Windows Server 2003 включают в себя механизмы, позволяющие серверу, находящемуся под ее управлением, выступать в качестве программного маршрутизатора. Эти механизмы реализованы в составе Службы маршрутизации и удаленного доступа (Routing and Remote Access Service, RRAS). Хотя в архитектуре Windows Server 2003 основной упор делается на стек протоколов TCP/IP, в состав указанной службы также включена поддержка механизмов маршрутизации стека протоколов AppleTalk.
Реализованный в Windows Server 2003 механизм маршрутизации может с успехом использоваться для организации межсетевого взаимодействия в вычислительных сетях любого масштаба (в том числе и для интеграции корпоративной сети в Интернет), а также для организации виртуальных частных сетей (Virtual Private Network, VPN). Рассмотрим функциональные возможности, характерные для службы маршрутизации, реализованной в Windows Server 2003.
Многопротокольная маршрутизация для IP и AppleTalk. Необходимо обратить особое внимание на то, что в отличие от предыдущих версий Windows, маршрутизация для IPX-трафика больше не поддерживается.
В межсетевой среде каждая подсеть может быть соединена с произвольным количеством других подсетей посредством маршрутизаторов. Суть процесса маршрутизации сводится к тому, что два хоста, разделенных друг с другом любым произвольным количеством маршрутизаторов (другими словами, находящиеся в разных подсетях), могут взаимодействовать друг с другом. Всю организацию процесса доставки пакета от одного хоста другому берут на себя маршрутизаторы. Рассмотрим основные принципы, лежащие в основе процесса маршрутизации сообщений. Сразу оговоримся, что разговор будет идти, прежде всего, о маршрутизации IP-трафика. Подавляющее большинство сетевых служб Windows Server 2003 функционирует на базе стека протоколов TCP/IP, получившего широкое распространение именно благодаря простоте организации межсетевого взаимодействия (как известно, самое большое объединение сетей — Интернет, тоже основывается на этом стеке протоколов). Тем не менее, заметим, что в своей основе принципы маршрутизации являются общими для большинства стеков протоколов.
В зависимости от количества вовлеченных получателей стек протоколов TCP/IP поддерживает два способа маршрутизации: одноадресная и многоадресная маршрутизация. Соответственно, мы рассмотрим принципы маршрутизации применительно к каждому из способов в отдельности.
Под одноадресной маршрутизацией понимается процесс передачи сообщений между подсетями, в котором сообщение адресовано только одному заданному получателю. Вся задача маршрутизации в этом случае сводится к доставке пакета получателю и выбору оптимального маршрута из множества возможных.
Отправителя и получателя может разделять произвольное количество маршрутизаторов. При этом процесс передачи сообщения от одного маршрутизатора другому называется "прыжком" (hop). Каждый маршрутизатор обладает информацией о структуре сети на расстоянии одного прыжка. Другими словами, маршрутизатор не обладает информацией о точном местоположении требуемого хоста. В большой сети, да еще и с интенсивно меняющейся структурой (как, например, Интернет), это было бы невозможно. Вместо этого, маршрутизатор обладает информацией о соседних маршрутизаторах и о том, кому из них необходимо передать сообщение для последующей доставки в той или иной ситуации. Эта информация хранится в специальной таблице, которая носит название таблицы маршрутизации (routing table).
Таблицы маршрутизации используются для принятия решения о том, как именно будет доставлено то или иное сообщение. Наличие этих таблиц не является исключительным свойством маршрутизатора. В сети TCP/IP любой хост (даже не являющийся маршрутизатором) может также располагать таблицей маршрутизации, которая используется с целью определения оптимального маршрута передачи сообщений. Так, скажем, если в подсети имеется три маршрутизатора, хост использует таблицу маршрутизации для того, чтобы выбрать из них наиболее оптимальный для доставки сообщения.
Записи в таблице маршрутизации называются маршрутами. При этом существует три типа маршрутов.
Маршрут к хосту, или узловой маршрут (Host Route). Этот тип маршрута определяет путь доставки пакета, адресованного хосту с конкретным сетевым адресом. Маршруты к хостам обычно используются для создания настраиваемых маршрутов к определенным компьютерам, а также для управления или оптимизации сетевого трафика.
Маршрут к сети, или сетевой маршрут (Network Route). Данный тип маршрута используется для определения способа доставки пакета в подсеть с определенным адресом. Большую часть содержимого таблицы маршрутизации представляют собой маршруты данного типа.
Маршрут по умолчанию (Default Route). Маршрут по умолчанию используется, когда не найдены никакие другие маршруты в таблице маршрутизации. Маршрут по умолчанию используется в ситуации, когда в таблице маршрутизации отсутствует соответствующий маршрут по идентификатору сети или маршрут к хосту по адресу получателя. Маршрут по умолчанию упрощает конфигурацию компьютеров. Вместо конфигурирования компьютера и настройки маршрутов для всех идентификаторов сетей в межсетевой среде используется одиночный маршрут по умолчанию для пересылки всех пакетов в сеть получателя или по адресу в межсетевой среде, который не был найден в таблице маршрутизации.
Рассмотрим структуру таблицы маршрутизации на следующем примере:
Сеть назначения |
Маска подсети |
Шлюз |
Интерфейс |
Метрика |
0.0.0.0 |
0.0.0.0 |
0.0.0.0 |
fffffffff |
1 |
10.0.0.0 |
255.255.255.0 |
10.0.0.1 |
10.0.0.1 |
30 |
10.0.0.1 |
255.255.255.255 |
127.0.0.1 |
127.0.0.1 |
30 |
10.255.255.255 |
255.255.255.255 |
10.0.0.1 |
10.0.0.1 |
30 |
127.0.0.0 |
255.0.0.0 |
127.0.0.1 |
127.0.0.1 |
1 |
224.0.0.0 |
240.0.0.0 |
10.0.0.1 |
10.0.0.1 |
30 |
255.255.255.255 |
255.255.255.255 |
10.0.0.1 |
10.0.0.1 |
1 |
Каждая запись в таблице маршрутизации (представляющая собой информацию о маршруте) состоит из информационных полей, перечисленных ниже.
Сеть назначения (Network Destination). Данное поле содержит сведения об адресе хоста-получателя пакета или сети, в которой этот хост располагается. Принимая решение о маршрутизации пакета, система просматривает именно это поле. Если в данном поле не будет найдено записи о конкретном адресе сети или хоста, маршрутизатором будет использован маршрут по умолчанию.
Маска подсети (Netmask). Это поле в сочетании с предыдущим полем используется для вычисления идентификатора IP-сети.
Шлюз (Gateway). В этом поле указывается адрес, по которому
будет должен быть передан согласно данному маршруту. Адрес пересылки может быть аппаратным адресом или адресом в межсетевой среде. В большинстве случаев в этом поле указывается следующий в цепочке маршрутизатор, который должен будет принять решение о дальнейшей маршрутизации сообщения.
Интерфейс (Interface). В этом поле указывается сетевой интерфейс, с которого будет осуществляться передача сообщения согласно данному маршруту. Данное поле необходимо в ситуации, когда маршрутизатор имеет множество сетевых интерфейсов, подключенных к разным подсетям. Фактически данное поле указывает, в какую именно подсеть необходимо передать сообщение.
Метрика (Metric). Стоимость маршрута, характеризующая меру его предпочтения. Из множества альтернативных маршрутов будет выбран тот, что обладает наименьшей стоимостью (т. е. меньшим значением метрики). Некоторые алгоритмы маршрутизации сохраняют только один маршрут для любого идентификатора сети в таблице маршрутизации, даже когда существует несколько маршрутов. В этом случае метрика используется маршрутизатором, чтобы определить какой именно маршрут необходимо сохранить в таблице маршрутизации.
В зависимости от способа формирования содержимого таблицы маршрутизации различают два вида маршрутизации.
Статическая маршрутизация. Все маршруты прописываются и изменяются администратором системы вручную. Это самый простой способ организации маршрутизации. Однако он подходит только для небольших сетей, изменения в структуре которых происходят достаточно редко. Кроме того, данный способ маршрутизации не годится в случае, когда важно обеспечить высокую надежность межсетевого взаимодействия. Если один из маршрутов окажется по каким-либо причинам недоступен, администратору необходимо будет вручную изменить таблицу маршрутизации на всех маршрутизаторах в сети. До этого момента межсетевое взаимодействие на отдельных участках сети будет невозможно.
Динамическая маршрутизация. Построение таблицы маршрутизации осуществляется посредством специальных протоколов маршрутизации. Участие администратора в этом процессе минимально и сводится к изначальной конфигурации маршрутизаторов. Два наиболее распространенных протокола IP-маршрутизации, используемых в интрасетях, — протоколы RIP (Routing Information Protocol) и OSPF (Open Shortest Path First). Посредством указанных протоколов маршрутизаторы способны информировать друг друга об изменениях в структуре сети. В случае недоступности одного из маршрутов, маршрутизаторы автоматически перестроят свои таблицы маршрутизации и, при возможности, выберут другой маршрут доставки сообщений.
Статическая маршрутизируемая IP-сеть не использует протоколы маршрутизации, поскольку вся информация о маршрутизации хранится в статической таблице на каждом маршрутизаторе. Чтобы любые два произвольных хоста в сети могли взаимодействовать между собой, каждый маршрутизатор должен иметь такую таблицу маршрутов.
Статическая маршрутизируемая IP-среда лучше всего подходит для небольшой сети с редко изменяющейся структурой, в которой отсутствуют альтернативные маршруты. Статическая маршрутизируемая среда может применяться для:
сети малого предприятия;
сети домашнего офиса;
филиала с одной сетью.
Вместо реализации протокола маршрутизации через узкополосный канал связи, одиночный маршрут по умолчанию на маршрутизаторе филиала гарантирует, что весь трафик, не предназначенный для компьютера в сети филиала, будет направлен в основной офис.
Недостатки статической маршрутизации:
Отсутствие отказоустойчивости. Если в силу каких-либо причин один из маршрутизаторов выходит из строя или становится недоступным коммуникационный канал, статический маршрутизатор не сможет как-то отреагировать на неисправность. Более того, другие маршрутизаторы в сети не будут знать о неисправности и будут продолжать передавать данные по недоступному маршруту. В сетях малого офиса (например, с двумя маршрутизаторами и тремя сетями, соединенными в ЛВС) подобные ситуации могут решаться администратором оперативно. В крупных сетях более предпочтительным оказывается использование специальных протоколов маршрутизации;
Непроизводительные административные затраты. Если добавляется новая подсеть или удаляется из межсетевой среды существующая, маршруты к ней должны быть вручную добавлены или удалены. Если добавляется новый маршрутизатор, то он должен быть правильно сконфигурирован для маршрутизации в межсетевой среде.
Среди существующего многообразия протоколов маршрутизации Windows Server 2003 поддерживает только два:
протокол RIP версии 1 и 2;
протокол OSPF.
Рассмотрим эти протоколы более подробно.
Протокол обмена информацией о маршрутизации (Routing Information Protocol, RIP) разрабатывался как механизм, посредством которого маршрутизаторы могут обмениваться информацией об обновлениях таблиц маршрутизации. Этот механизм изначально предполагался для использования в сетях относительно небольшого размера (это верно для RIP версии 1).
Протокол RIP использует следующую схему построения таблицы маршрутизации. Первоначально таблица маршрутизации каждого маршрутизатора включает в себя маршруты только для тех подсетей, что физически подсоединены к маршрутизатору. Используя протокол RIP, маршрутизатор периодически отправляет другим маршрутизаторам объявления, содержащие информацию о содержимом собственной таблицы маршрутизации. RIP версии 1 использует для передачи объявлений широковещательные IP-пакеты. RIP версии 2 позволяет использовать для объявлений также пакеты группового вещания. Каждый маршрутизатор рассылает подобные объявления периодически с интервалом в 30 секунд.
Маршрутизаторы, использующие протокол RIP, могут также сообщать информацию о маршрутизации при помощи триггерных обновлений. Триггер-ные обновления инициируются, когда происходит изменение топологии сети и посылается обновленная информация о маршрутизации, которая отражает эти изменения. Триггерные обновления происходят немедленно, следовательно, информация о маршрутизации обновится раньше, чем произойдет следующее периодическое объявление. Например, когда маршрутизатор обнаруживает установление соединения или отказ соседнего маршрутизатора, он модифицирует собственную таблицу маршрутизации и рассылает обновленные маршруты. Каждый маршрутизатор, получающий триггерное обновление, изменяет собственную таблицу маршрутизации и распространяет изменение.
Основное преимущество R1P заключается в простоте развертывания и конфигурирования. В качестве недостатка RIP версии 1 можно отметить наличие жесткого ограничения на размер сети. Протокол R1P может быть использован в сети, в которой два хоста разделены не более чем 15 маршрутизаторами. Другими словами, маршрутизатор, использующий протокол RIP для построения таблицы маршрутизации, "знает" только о тех подсетях, что расположены на расстоянии не более 15 переходов. Подсети, расположенные на расстоянии 16 или более пересылок, считаются недостижимыми.
Поскольку глобальные IP-сети становятся все больше и больше, периодические RIP-объявления каждого маршрутизатора могут вызывать чрезмерный трафик. В качестве другого недостатка протокола RIP можно отметить высокое время восстановления. В ситуации, когда в структуре сети происходят изменения, может пройти несколько минут прежде, чем все корпоративные
маршрутизаторы получат информацию о произошедшем изменении и переконфигурируют собственные таблицы маршрутизации. За то время как происходит реконфигурирование маршрутизаторов, могут образоваться циклы маршрутизации, приводящие к потере или невозможности доставки данных. В условиях повышенных требований к надежности канала данных существующих возможностей протокола RIP может быть недостаточно.
Службы маршрутизации и удаленного доступа Windows Server 2003 могут работать с протоколом RIP версий 1 и 2. RIP версии 2 поддерживает объявления, рассылаемые при помощи групповых рассылок, простую аутентификацию при помощи пароля, а также дает возможность гибкой настройки при работе в средах с подсетями и в CIDR-средах (Classless InterDomain Routing, Бесклассовая междоменная маршрутизация).
Реализация протокола RIP в Windows Server 2003 характеризуется следующими функциональными возможностями:
выбор версии R1P, которая будет выполняться на каждом интерфейсе для входящих и исходящих пакетов;
алгоритмы "split horizon", "poison reverse" и триггерных обновлений, которые используются для корректного отображения изменений топологии сети;
фильтры маршрутов для выбора тех сетей, которые необходимо объявлять или принимать от них обновления;
фильтры источников для выбора маршрутизаторов, от которых будут приниматься объявления;
конфигурируемые объявления и таймеры старения маршрута;
поддержка простого удостоверения подлинности при помощи пароля;
возможность отключения суммирования подсетей.
Использование в сети протокола маршрутизации RIP оправданно в случае небольшой сети с динамически меняющейся структурой, имеющей несколько возможных маршрутов. Маршрутизируемая среда на базе протокола RIP может потребоваться для:
предприятия среднего размера;
большого офиса филиала или дополнительного офиса со множественными сетями.
Протокол OSPF (Open Shortest Path First) разрабатывался как механизм, посредством которого маршрутизаторы могут обмениваться информацией о содержимом таблиц маршрутизации в большой межсетевой среде. Протокол OSPF является протоколом маршрутизации с объявлением состояния канала
связи. В основе функционирования протокола OSPF лежит алгоритм "первоочередного обнаружения кратчайшего пути" (Shortest Path First, SPF), который используется для вычисления маршрутов в таблице маршрутизации. Используя алгоритм SPF, маршрутизатор вычисляет кратчайший (т. е. обладающий наименьшей стоимостью) путь ко всем подсетям в межсетевой среде. В маршрутах, рассчитанных при помощи алгоритма SPF, всегда отсутствуют циклы.
В отличие от протокола RIP, протокол OSPF поддерживает "карту" корпоративной сети. Эта карта модифицируется каждый раз, когда происходит какое-либо изменение в структуре сети. Эта карта, называемая базой данных состоянии связей (link state database), синхронизирована для всех OSPF-маршрутизаторов и используется, чтобы вычислить маршруты в таблице маршрутизации. Изменения в структуре сети приводят к немедленному распространению сведений об этих изменениях на все маршрутизаторы, которые, в свою очередь, обновляют собственный экземпляр базы данных состояния связей. Обновление базы данных состояний связей приводит к повторному пересчету таблицы маршрутизации.
Начиная свою работу, каждый маршрутизатор извещает другие маршрутизаторы о своем существовании, отправляя специальное сообщение во все доступные подсети. Другие маршрутизаторы получают это сообщение и обновляют свой экземпляр базы данных о состоянии связей. Фактически указанная база данных и формируется на основании этих сообщений.
Поскольку размер базы данных состояний связей растет, требования к объему памяти и время на вычисление маршрута увеличиваются. Чтобы решить эту проблему, OSPF рассматривает межсетевую среду как совокупность областей (под областью в данном случае понимается совокупность непрерывных сетей), соединенных друг с другом через некоторую базовую область (backbone area). Все маршрутизаторы, принадлежащие к одной области, обладают идентичными репликами базы данных состояния связей.
С целью идентификации областей каждой из них выделяется специальный идентификатор (area ID), представляющий собой 32-разрядное число. Этот идентификатор записывается так же как и IP-адрес — в десятично-точечном формате (т. е. в виде четырех однобайтовых чисел, разделенных точками). Идентификатор области никак не связан с IP-адресацией. Администратор может присваивать идентификаторы областям по своему усмотрению, не оглядываясь на используемые в сети IP-адреса. При этом одна область OSPF может включать в свой состав неограниченное количество подсетей (размер области ограничивается исключительно размером базы данных состояния связей).
Каждый маршрутизатор хранит базу данных состояний связей только для тех областей, которые подсоединены к маршрутизатору непосредственно. Маршрутизаторы, соединяющие базовую область с другими областями, называются пограничными маршрутизаторами областей (Area Border Router, ABR). Пограничные маршрутизаторы накапливают изменения, полученные от остальных маршрутизаторов области, и передают их разом маршрутизаторам, расположенным в других областях.
На рис. 15.1 показан пример разделения сети на области в случае использования протокола OSPF.
Рис. 15.1. Сеть с использованием протокола OSPF
Самое большое преимущество протокола OSPF заключается в том, что он является высокопроизводительным протоколом и приводит к незначительным издержкам даже в очень больших межсетевых конфигурациях. В качестве недостатка протокола OSPF можно отметить определенную сложность его развертывания и конфигурирования.
По сравнению с протоколом RIP протокол маршрутизации OSPF обладает следующими преимуществами:
алгоритм, лежащий в основе протокола OSPF, позволяет избежать петель маршрутизации;
в процессе своего функционирования протокол OSPF генерирует значительно меньший сетевой трафик, чем протокол RIP. Как следствие, переход с RIP на OSPF позволит снизить нагрузку на сеть;
протокол OSPF для рассылки служебных сообщений использует только групповое вещание (в отличие от протокола R1P версии 1);
протокол OSPF предусматривает возможность разбиения корпоративной сети на области. Области могут, с одной стороны, рассматриваться как домены маршрутизации, с другой стороны, облегчают процесс администрирования подсистемы маршрутизации;
протокол OSPF не имеет ограничений на количество переходов между маршрутизаторами, что позволяет его использовать в корпоративных сетях любого масштаба;
реконфигурация таблиц маршрутизации, вызванная изменениями в структуре сети, происходит за очень короткий период (значительно быстрее, нежели в случае использования протокола RIP).
Реализация протокола OSPF, предложенная в рамках Windows Server 2003, обладает следующими функциональными возможностями:
фильтр маршрутов для управления взаимодействием с другими протоколами маршрутизации;
динамическая реконфигурация всех установок OSPF;
сосуществование с RIP;
динамическое добавление и удаление сетевых интерфейсов маршрутизатора.
Маршрутизируемая OSPF-среда лучше всего подходит для крупных межсетевых сред (насчитывающих более 50 подсетей) с динамически изменяемой структурой, имеющих несколько путей доставки пакетов, передаваемых между любыми двумя конечными точками межсетевой среды.
Ниже перечислены сетевые конфигурации, для которых необходима маршрутизируемая OSPF-среда:
корпоративная или сеть университетского городка (campus);
международная корпоративная или университетская межсетевая среда.
Протокол маршрутизации OSPF на 64-разрядных версиях операционных систем семейства Windows Server 2003 не поддерживается.
В рамках службы маршрутизации и удаленного доступа 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.
В качестве примера рассмотрим два типичных сценария организации процесса маршрутизации:
простой сценарий маршрутизации;
сценарий с несколькими маршрутизаторами.
В самом, простом сценарии две или несколько подсетей могут быть соединены между собой при помощи одного маршрутизатора. Для решения этой задачи вполне можно использовать маршрутизатор на базе Windows Server 2003. На рис. 15.2 показана простая конфигурация сети с маршрутизатором Windows, соединяющим два сегмента ЛВС (Сети А и В). В данном сценарии используется только один маршрутизатор. Как следствие, отсутствует проблема обмена информацией о маршрутах между маршрутизаторами. Поэтому не требуется развертывание протоколов маршрутизации.
Рис. 15.2. Простой сценарий маршрутизации
В более сложном сценарии для объединения множества подсетей потребуется несколько маршрутизаторов. В большинстве случаев этот сценарий может быть также решен при помощи программных маршрутизаторов на базе
Windows Server 2003. При этом необходимо будет использовать специализированные протоколы маршрутизации (либо, в случае статической маршрутизации, сконфигурировать на всех маршрутизаторах вручную таблицы маршрутизации).
Пример рассматриваемого сценария изображен на рис. 15.3. В предложенной конфигурации имеются три сети (Сети А, В, и С) и два маршрутизатора. Маршрутизатор 1 подключен к Сетям А и В, Маршрутизатор 2 — к Сетям В и С. Маршрутизатор 1 должен известить Маршрутизатор 2 о том, что Сеть А может быть достигнута через Маршрутизатор 1, а Маршрутизатор 2 должен сообщить Маршрутизатору 1, что Сеть С может быть достигнута через Маршрутизатор 2. Маршрутизаторы обменяются этой информацией автоматически, в случае, если используются протоколы маршрутизации, например RIP или OSPF. Когда пользователь в Сети А хочет установить соединение с пользователем в Сети С, компьютер пользователя в Сети А передает пакет на Маршрутизатор 1. Маршрутизатор 1 затем передает пакет Маршрутизатору 2. Тот, в свою очередь, передает пакет далее компьютеру пользователя в Сети С.
Рис. 15.3. Сценарий с двумя маршрутизаторами и тремя сетями
Под многоадресной маршрутизацией понимается маршрутизация трафика группового вещания. Групповое вещание (multicasting) предполагает отправку пакетов, адресованных не одному получателю, а целой группе. Механизм многоадресной маршрутизации позволяет каждому получателю, принадлежащему к определенной группе, получить пакет группового вещания независимо от того, в какой подсети он находится. Прежде чем детально рассмотреть механизмы многоадресной маршрутизации, необходимо ознакомиться с принципами группового вещания.
Стандартный способ доставки (одноадресный) предполагает установку соединения "точка-точка", когда пакет доставляется одному получателю. В случае, когда один и тот же пакет должен быть доставлен нескольким получателям, установка нескольких точечных соединений оказывается неэффективным решением (с одной стороны, происходит увеличение сетевого трафика, а с другой, — увеличиваются затраты вычислительных ресурсов на поддержание списка конечных точек). Использование широковещательных рассылок также не является эффективным решением, поскольку широковещательные сообщения не транслируются маршрутизаторами. В качестве альтернативы можно использовать другой метод доставки, когда получателем пакета выступает не один, а несколько получателей. Данный принцип лежит в основе группового вещания (multicasting).
Каждый хост, входящий в группу вещания, помимо уникального IP-адреса. однозначно идентифицирующего хост в пределах сети, получает также некоторый групповой IP-адрес. Этот адрес идентичен для всех хостов, являющихся членами группы. Этот адрес может быть указан в качестве получателя пакета. В этом случае пакет будет получен всеми хостами, входящими в состав группы вещания. Все другие узлы просто проигнорируют данный пакет. В этом заключается существенное отличие группового вещания от широковещательных рассылок — групповой трафик не "беспокоит" хосты, не принадлежащие к группе вещания и не ожидающие группового трафика.
Групповое вещание может использоваться для следующих целей:
обнаружения ресурсов в межсетевом пространстве;
поддержки распределенных сетевых приложений;
поддержки групповых приложений мультимедиа, предполагающих передачу потоковых данных (например, цифрового аудио и видео). В качестве примера приложения, использующего групповое вещание, можно привести Microsoft Media Services.
В приведенном на рис. 15.4 примере три хоста, расположенные в разных подсетях, принадлежат к одной группе вещания. Следует обратить внимание на то, что хотя каждый хост уникально идентифицируется посредством IP-адреса, каждому из них выделен общий групповой адрес. В данном примере предполагается, что трафик группового вещания распространяется свободно в обоих подсетях. На самом деле, задача распространения трафика группового вещания (так же как и в случае одноадресной маршрутизации) в условиях межсетевого взаимодействия решается на уровне маршрутизаторов.
Рис. 15.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, нельзя рассматривать как протокол групповой маршрутизации.
Задача поддержания таблицы групповой маршрутизации осуществляется в 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.
Рис. 15.5. Организация группового вещания в сценарии "интрасеть с одним маршрутизатором"
Поскольку в данном сценарии используется всего один маршрутизатор, проблема взаимодействия маршрутизаторов, участвующих в маршрутизации группового трафика, попросту отсутствует. Как следствие, процесс группового вещания может быть реализован средствами службы маршрутизации и удаленного доступа Windows Server 2003. Групповое вещание в данном сценарии может быть реализовано путем использования механизма пересылки трафика группового вещания (multicast forwarding). Для этого все сетевые интерфейсы маршрутизатора переводятся в режим IGМР-маршрутизатора (предварительно должен быть активизирован компонент маршрутизации протокола IGMP) (рис. 15.5).
Рассмотрим другой сценарий. Допустим, корпоративная сеть, так же как и в предыдущем случае, состоит из нескольких подсетей, соединенных между собой одиночным маршрутизатором. При этом один из интерфейсов маршрутизатора связывает корпоративную подсеть с Интернетом (в более общем случае вместо Интернета может выступать любая внешняя сеть). В данном сценарии проблема организации группового вещания осложняется тем фактом, что источником трафика группового вещания могут выступать хосты, расположенные в Интернете. При этом встает вопрос об объявлении членства в группах вещания хостами, расположенными в корпоративной интрасети. Как маршрутизатор Интернета "узнает" об этих хостах и о том, что в корпоративную подсеть должен быть передан определенный трафик группового вещания?
В данном случае задача может быть также решена средствами службы маршрутизации и удаленного доступа Windows Server 2003. Все интерфейсы. соединяющие маршрутизатор с локатьными подсетями, должны быть переведены в режим ЮМР-маршрутизатора. Сетевой интерфейс, соединяющий корпоративный маршрутизатор с маршрутизатором интернет-провайдера, должен быть переведен в режим IGMP-посредника (IGMP-proxy) (рис. 15.6).
При этом предложенная схема работает следующим образом. Хосты объявляют о своей принадлежности к некоторой группе вещания. Эти объявления передаются IGMP-посредником маршрутизатору интернет-провайдера. Маршрутизатор использует данные объявления для построения своей таблицы групповой маршрутизации. Используя некоторый протокол групповой маршрутизации, маршрутизатор интернет-провайдера сообщает эти сведения другим маршрутизаторам. Таким образом, становится возможным передача требуемого группового трафика маршрутизатору интернет-провайдера. Маршрутизатор провайдера передает групповой трафик корпоративному маршрутизатору, который, в свою очередь, передает его хостам интрасети, принадлежащим к требуемым группам вещания.
Рис. 15.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, отвечающий на звонок, должен быть в состоянии отличить клиента, работающего по коммутируемому соединению, от маршрутизатора, звонящего по данному номеру, чтобы установить соединение с вызовом по требованию. Для этого имя учетной записи, посылаемое маршрутизатором, устанавливающим соединение, в процессе аутентификации должно в точности совпадать с именем сетевого интерфейса с вызовом по требованию на маршрутизаторе, отвечающем на звонок.
Рассмотрение процесса настройки маршрутизации с вызовом по требованию лучше всего проводить на примере. Обратимся к рис. 15.7, на котором изображена конфигурация гипотетической маршрутизируемой сети.
Рис. 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 (Мастер интерфейса вызова по требованию), чтобы автоматизировать процесс настройки. Этот мастер выполняет все шаги конфигурации, описанные ниже, кроме создания статического маршрута.
Настройка маршрутизации с вызовом по требованию на Маршрутизаторе 1 состоит из следующих трех шагов:
1. Создать интерфейс с вызовом по требованию.
2. Создать статический маршрут.
3. Создать учетную запись Windows, которая может использоваться Маршрутизатором 2 для установки соединения с Маршрутизатором 1.
Создание интерфейса с вызовом по требованию
При помощи оснастки Routing and Remote Access (Маршрутизация и удаленный доступ) администратор на Маршрутизаторе 1 создает интерфейс (с именем DD_SPb) с вызовом по требованию со следующей конфигурацией:
оборудование: модем на СОМ1;
номер телефона: (812)765-4321;
протоколы: TCP/IP;
идентификационная информация (для исходящих соединений): DD_Moscow и пароль.
Создание статического маршрута
На следующем этапе администратор на Маршрутизаторе 1 создает статический IP-маршрут, обладающий следующей конфигурацией:
получатель: 173.75.72.0;
маска сети: 255.255.255.0;
шлюз: 10.0.0.1;
метрика: 1;
интерфейс: DD_SPb.
Поскольку соединение с вызовом по требованию — двухточечное, IP-адрес шлюза игнорируется в течение процесса маршрутизации. В поле шлюза (Gateway) может быть введен любой IP-адрес. В данном примере IP-адрес шлюза по умолчанию (10.0.0.1) выбран произвольно.
Создание учетной записи Windows
Используя оснастку Active Directory Users and Groups (Active Directory — пользователи и компьютеры), администратор на Маршрутизаторе 1 создает учетную запись пользователя Windows со следующими параметрами:
имя учетной записи: DD_SPb;
установки учетной записи: сбросить флажок User must change password at next logon (Сменить пароль при следующем входе в систему) и установить флажок
Password never expires (Срок действия пароля не ограничен).
Посредством механизма политик удаленного доступа (Remote Access Policies) администратор на Маршрутизаторе 1 должен предоставить учетной записи DD_SPb разрешение на удаленный доступ.
Настройка маршрутизации с вызовом по требованию на Маршрутизаторе 2 производится аналогично. Интерфейс с вызовом по требованию на данном маршрутизаторе имеет имя DD_Moscow и обладает следующей конфигурацией:
оборудование: модем на COM2;
номер телефона: (095)123-4567;
протоколы: TCP/IP;
идентификационная информация (для исходящих соединений): DD_SPb и пароль.
На Маршрутизаторе 2 определяется следующий статический маршрут:
получатель: 173.75.73.0;
маска сети: 255.255.255.0;
шлюз: 10.0.0.1;
метрика: 1;
интерфейс: DD_Moscow.
Дополнительно создается следующая учетная запись (для входящих соединений):
учетная запись: DD_Moscow;
установки учетной записи: флажок User must change password at next logon (Сменить пароль при следующем входе в систему) — сброшен. Флажок
Password never expires (Срок действия пароля не ограничен) — установлен.
В рамках политики удаленного доступа на Маршрутизаторе 2 учетной записи DD_Moscow предоставлено разрешение на удаленный доступ.
Окончательная конфигурация маршрутизируемой сети с вызовом по требованию изображена на рис. 15.8. Указаны все интерфейсы с вызовом по требованию, статические маршруты и учетные записи Windows для офисов в Москве и Санкт-Петербурге.
Рис. 15.8. Результирующая конфигурация
Используем описанный выше сценарий для того, чтобы рассмотреть процесс установки соединения с вызовом по требованию. Для определенности будем считать, что хост с адресом 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 теряются.
В то время как маршрутизация с вызовом по требованию может уменьшать издержки на соединение, типичные протоколы маршрутизации полагаются на периодический процесс объявлений, которыми обмениваются маршрутизаторы извещая друг друга о содержимом собственных таблиц маршрутизации. Например, RIP для IP объявляет содержание таблицы маршрутизации каждые 30 секунд на всех интерфейсах. Такое поведение не является проблемой для постоянно подключенных каналов ЛВС или ГВС. В случае коммутируемого соединения подобные периодические объявления будут заставлять маршрутизатор вызывать другой маршрутизатор каждые 30 секунд. Такой подход может свести на нет всю выгоду от использования соединений с вызовом по требованию (поскольку приводит к нежелательному увеличению затрат на аренду коммутируемого канала связи). Выходом из сложившейся ситуации является отказ от использования протоколов маршрутизации в случае использования коммутируемых соединений.
Если для обновления таблиц маршрутизации не используются протоколы маршрутизации, то маршруты должны быть введены в маршрутизатор как статические маршруты. Статические маршруты, соответствующие подсетям, доступным через интерфейс с вызовом по требованию, могут быть созданы администратором вручную или автоматически. Автоматическое создание статических маршрутов для интерфейсов с вызовом по требованию известно как автоматическое статическое обновление (auto-static updates). Механизм автоматического статического обновления реализован в рамках службы маршрутизации и удаленного доступа Windows Server 2003. Этот механизм может использоваться совместно с протоколом маршрутизации RIP для IP, но не может быть использован совместно с OSPF.
По команде администратора маршрутизатор отправляет с интерфейса с вызовом по требованию, сконфигурированного для автоматического статического обновления, специальный запрос через активное соединение маршрутизатору, находящемуся на другой стороне. Запрос включает в себя требование предоставить информацию обо всех маршрутах, содержащихся в его таблице маршрутизации. Получив ответ на запрос, маршрутизатор извлекает из него сведения о маршрутах и автоматически обновляет таблицу маршрутизации, добавляя новые маршруты в качестве статических. Следует заметить, что статические маршруты постоянны. Это означает, что они сохраняются в таблице маршрутизации при любых обстоятельствах, даже в случае отключения интерфейса или перезапуска маршрутизатора.
Процесс автоматического статического обновления предполагает разовый и односторонний обмен информацией о маршрутах. Автоматическое статическое обновление инициируется администратором либо с помощью оснастки Routing and Remote Access, либо посредством утилиты командной строки Netsh, в тот момент, когда соединение с вызовом по требованию находится в активном состоянии. В случае установки соединения с вызовом по требованию автоматическое статическое обновление не выполняется автоматически.
Утилита командной строки Netsh может быть использована для создания пакетных файлов, автоматизирующих инициацию процесса автоматического статического обновления.
Запуск процесса автоматического статического обновления приводит к удалению существующих маршрутов, добавленных в ходе предыдущего автоматического статического обновления. Маршруты удаляются прежде, чем новая информация будет запрошена у соседних маршрутизаторов. Поэтому в ситуации, когда по каким-либо причинам маршрутизатор не получит в ответ на свой запрос новых сведений о маршрутах, маршрутизатор не сможет восстановить маршруты, которые были предварительно удалены. Это может привести к утрате возможности взаимодействия с удаленными сетями.
Механизм маршрутизации с вызовом по требованию может быть использован для организации пересылки маршрутизируемого трафика через Интернет путем организации виртуальной частной сети (Virtual Private
Network, VPN) между двумя абонентами. Две подсети могут организовать маршрутизацию внутреннего трафика через Интернет (в принципе — через любую открытую внешнюю сеть) по защищенному каналу, созданному посредством протоколов туннелирования L2TP или РРТР. Защищенный канал создается каждый раз автоматически, когда появляется трафик, адресованный в заданном направлении. Один из маршрутизаторов, выступающий в качестве VPN-клиента, устанавливает коммутируемое соединение, чтобы дозвониться до интернет-провайдера. После установки соединения маршрутизатор создает защищенный канал (посредством некоторого протокола туннелирования) с маршрутизатором-концентратором, имеющим постоянное соединение с Интернетом. После того как создан защищенный канал (т. е. подключение виртуальной частной сети), процесс взаимодействия двух подсетей реализуется по стандартной схеме маршрутизации с вызовом по требованию.
Пример реализации данного сценария приведен на рис. 15.9.
Рис. 15.9. Организация виртуальной частной сети при помощи механизма маршрутизации с вызовом по требованию
Рассмотрим процесс настройки службы маршрутизации и удаленного доступа Windows Server 2003 в качестве маршрутизатора. Прежде чем приступить
непосредственно к процедуре настройки, администратор должен решить следующие вопросы:
выбрать протокол, для которого необходимо организовать маршрутизацию. Механизмы маршрутизации Windows Server 2003 позволяют организовать маршрутизацию протоколов IP и AppleTalk;
определить, какой способ построения таблиц маршрутизации будет использоваться в корпоративной сети. В небольшой, редко изменяющейся сети наиболее простым и эффективным будет использование статической маршрутизации. В больших распределенных сетях с часто меняющейся структурой, предпочтительно использовать динамическую маршрутизацию;
выбрать протоколы маршрутизации (в случае если используется динамическая маршрутизация). Данный пункт актуален для IP-трафика. Администратор может выбирать из двух протоколов маршрутизации — RIP и OSPF.
Все требуемое аппаратное обеспечение должно быть подключено и активизировано еще до того, как будет выполнено развертывание служб маршрутизации Windows. В зависимости от архитектуры корпоративной сети и требований к ней могут понадобиться следующие аппаратные средства:
сетевой адаптер с сертифицированным NDIS-драйвером (Спецификация интерфейса сетевого драйвера, Network Driver Interface Specification);
один или несколько совместимых модемов и доступный СОМ-порт;
многопортовый адаптер для повышения производительности при наличии нескольких одновременных удаленных соединений;
интеллектуальная плата Х.25 (для сетей Х.25);
ISDN-адаптер или модем (для линий ISDN).
Совместимость всех аппаратных средств компьютера, работающего под управлением Windows Server 2003, можно проверить по списку совместимости аппаратных средств (Hardware Compatibility List, HCL) в Интернете на веб-сервере Microsoft (http://www.microsoft.com.hcl).
Служба маршрутизации и удаленного доступа (Routing and Remote Access Service, RRAS) устанавливается автоматически в процессе установки Windows Server 2003. Однако при этом она остается в неактивном состоянии. Прежде чем эта служба сможет быть использована для маршрутизации
сообщений, необходимо ее активизировать и должным образом сконфигурировать. Активизация службы выполняется при помощи специального мастера Routing and Remote Access Server Setup Wizard. Этот мастер кроме собственно активизации позволяет выполнить настройку службы в соответствии со стоящими перед администратором задачами. Если служба уже была активизирована ранее (например, при развертывании сервера удаленного доступа), администратор должен выполнить ручную настройку службы.
Для запуска мастера необходимо в пространстве имен оснастки Routing and Remote Access вызвать контекстное меню объекта, ассоциированного с сервером, и выбрать в нем пункт
Configure and Enable Routing and Remote Access (Конфигурировать и разрешить маршрутизацию и удаленный доступ). На странице Custom Configuration (Конфигурирование) мастера необходимо выбрать переключатель
Custom configuration (Заказная конфигурация). В следующем окне мастера (рис. 15.10) необходимо установить флажки напротив тех компонентов, которые должны быть активизированы на конфигурируемом сервере.
Рис. 15.10. Выбор режимов работы службы маршрутизации и удаленного доступа
По окончании своей работы мастер автоматически запустит на сервере службу маршрутизации и удаленного доступа.
Если на компьютере имеются входящие подключения (incoming connections), мастер Routing and Remote Access Server Setup Wizard запустить невозможно. Нужно сначала удалить их, а затем запустить мастер снова.
Согласно терминологии службы маршрутизации и удаленного доступа, под устройством (device) понимается аппаратное или программное обеспечение, предоставляющее порты для установки соединений "точка-точка". Протоколы РРТР или L2TP — примеры виртуальных многопортовых устройств. Чтобы служба маршрутизации и удаленного доступа могла использовать конкретное устройство (порт), нужно разрешить ее функционирование для этого устройства. Для этого необходимо вызвать окно свойств объекта Ports (Порты), расположенного в пространстве имен оснастки
Routing and Remote Access. На вкладке Devices (Устройства) следует выбрать требуемое устройство с вызовом по требованию, а затем нажать кнопку
Configure (Настроить).
В окне Configure Device (Настройка устройства) (рис. 15.11) необходимо установить флажок Demand-dial routing connections (inbound and outbound)
(Подключения по требованию (входящие и исходящие)), а затем нажать кнопку ОК.
Рис. 15.11. Разрешение использования устройства для организации маршрутизации с вызовом по требованию
У администратора имеется две возможности для создания статических маршрутов:
при помощи утилиты командной строки Route.exe;
используя графический интерфейс оснастки Routing and Remote Access. В контекстном меню объекта
Static Route (Статический маршрут) необходимо выбрать пункт New Static Route (Создать статический маршрут). В открывшемся окне требуется определить обязательные параметры маршрута (рис. 15.12).
Если создается маршрут для интерфейса с вызовом по требованию, поле Gateway (Шлюз по умолчанию) окажется недоступным.
Рис. 15.12. Создание статического маршрута
Протокол маршрутизации RIP используется для динамического распространения среди маршрутизаторов информации о существующих маршрутах. Правильно реализованная среда с RIP автоматически добавляет и удаляет маршруты, как только сети добавляются и удаляются из межсетевой среды. Необходимо убедиться, что каждый маршрутизатор правильно сконфигурирован — так, чтобы объявления о маршрутах протокола RIP были бы посланы и получены всеми RIP-маршрутизаторами в сети.
Для установки на маршрутизаторе протокола RIP необходимо в контекстном меню объекта
General (Общие) выбрать пункт New Routing Protocol (Новый протокол маршрутизации). В открывшемся окне следует выбрать из списка элемент
RIP Version 2 for Internet Protocol. Система выполнит установку всех необходимых компонентов. В пространстве имен оснастки появится новый контейнер — RIP.
После того как протокол установлен на маршрутизаторе, необходимо определить сетевые интерфейсы, для которых он будет активизирован. В процессе добавления интерфейса (команда New Interface в контекстном меню протокола), система предложит определить конфигурацию протокола RIP для этого интерфейса. В подавляющем большинстве случаев администратор может использовать значения, предлагаемые по умолчанию.
Маршрутизируемая межсетевая OSPF-среда использует протокол маршрутизации OSPF, чтобы динамически пересылать информацию о маршрутизации между маршрутизаторами. Правильно развернутая OSPF-среда автоматически добавляет и удаляет маршруты, когда из межсетевой среды добавляются или удаляются сети. Необходимо, чтобы каждый маршрутизатор был правильно настроен: OSPF-объявления маршрутов должны распространяться между OSPF-маршрутизаторами в межсетевой среде.
Рис. 15.13. Определение конфигурации протокола OSPF для выбранного сетевого интерфейса
Для установки на маршрутизаторе протокола OSPF следует в контекстном меню объекта
General (Общие) выбрать пункт New Routing Protocol (Новый протокол маршрутизации). В открывшемся окне необходимо выбрать из списка элемент
Open Shortest Path First (OSPF). Система выполнит установку всех необходимых компонентов. В пространстве имен оснастки появится новый контейнер — OSPF.
После того как протокол установлен на маршрутизаторе, нужно определить сетевые интерфейсы, для которых он будет активизирован. В процессе добавления интерфейса система предложит определить конфигурацию протокола OSPF для этого интерфейса (рис. 15.13). В поле Area ID администратору необходимо выбрать область OSPF, к которой будет отнесен данный маршрутизатор.
Чтобы маршрутизатор мог выполнять пересылку трафика группового вещания (multicast forward), на нем необходимо активизировать компонент маршрутизации протокола IGMP.
Рис. 15.14. Выбор режима функционирования интерфейса при пересылке трафика группового трафика
Кроме того, отдельные (или все) сетевые интерфейсы маршрутизатора должны быть переведены в соответствующие режимы работы (IGMP-маршрутизатора или
IGМР-посредника).
Для активизации компонента маршрутизации протокола IGMP необходимо в контекстном меню объекта
General (Общие) выбрать пункт New Routing Protocol (Новый протокол маршрутизации). В открывшемся окне нужно выбрать из списка элемент
IGMP Router and Proxy. Система выполнит установку всех необходимых компонентов, и в пространстве имен оснастки появится новый контейнер —
IGMP.
На следующем этапе следует выбрать сетевые интерфейсы, на которых данный компонент будет активизирован, и определить режим их работы. В процессе добавления интерфейса система предложит определить параметры функционирования IGMP на уровне интерфейса (рис. 15.14). В поле
Mode (Режим) необходимо выбрать режим, в котором будет функционировать интерфейс.
Если для сетевых интерфейсов компьютера, находящегося под управлением Windows Server 2003, установлен стек протоколов AppleTalk, служба маршрутизации и удаленного доступа этого компьютера может быть использована для организации системы маршрутизации AppleTalk-трафика.
В панели пространства имен оснастки Routing and Remote Access необходимо в контекстном меню объекта
AppleTalk Routing (Маршрутизация AppleTalk) выбрать пункт Enable AppleTalk Routing (Разрешить маршрутизацию Apple-Talk). Система активизирует соответствующие механизмы.
Рассмотрим некоторые вопросы, связанные с контролем за работой распределенной инфраструктуры маршрутизаторов в корпоративной сети. Операционная система Windows Server 2003 предоставляет администратору возможности централизованного управления всей инфраструктурой маршрутизаторов (реализованных на базе этой операционной системы) при помощи оснастки
Routing and Remote Access.
Администратор может подключить оснастку Routing and Remote Access к
любому маршрутизатору, реализованному на базе Windows Server 2003, и выполнить его удаленное конфигурирование. Для этого в контекстном меню корневого объекта пространства имен оснастки необходимо выбрать пункт
Add Server (Добавить сервер).
В открывшемся окне установите переключатель в одно из следующих положений:
The following computer (Указанный ниже компьютер). В этом случае администратору потребуется задать имя компьютера или указать его IP-адрес;
All Routing and Remote Access computers (Все компьютеры маршрутизации и удаленного доступа). При этом необходимо указать домен, в котором находится интересующий сервер;
Browse Active Directory (Обзор Active Directory). Система предложит выбрать типы серверов, которые следует найти, в диалоговом окне
Find Routers or Remote Access Servers (Поиск маршрутизаторов или серверов удаленного доступа).
После этого оснастка будет подключена к выбранному серверу, будет загружена информация о его конфигурации, и он станет доступным для администрирования.
В пространстве имен оснастки Routing and Remote Access в контекстном меню объекта Static Routes (Статические маршруты) выберите пункт
Show IP Routing Table (Показать таблицу IP-маршрутизации) (рис. 15.15).
Рис. 15.15. Просмотр таблицы маршрутизации
В табл. 15.1 перечислены доступные в оснастке Routing and Remote Access категории просматриваемой информации, которые можно получить из контекстного меню соответствующего компонента.
Таблица 15.1. Категории просматриваемой информации
Компонент |
Пункт меню |
Категория информации |
IP Routing/General (Маршрутизация IP/ Общие)   |
Show TCP/IP Information |
Статистическая информация о работе компонентов стека протоколов TCP/IP (количество пакетов различных протоколов, обработанных службой) |
Show Multicast Forwarding Table |
Содержимое таблицы пересылки группового трафика |
|
Show Multicast Statistics |
Статистическая информация о трафике группового вещания, обрабатываемом службой |
|
IP Routing/ General/ <Интерфейс> |
Show TCP/IP Information |
Статистическая информация о работе компонентов стека протоколов TCP/IP на уровне отдельного интерфейса |
Show Address Translations |
Информация о работе механизма трансляции сетевых адресов |
|
Show IP Addresses |
Информация об IP-адресах, выделенных интерфейсу |
|
Show IP Routing Table |
Таблица маршрутизации данного интерфейса |
|
Show TCP Connections |
Установленные TCP-соединения |
|
Show UPD Listener Ports |
Прослушиваемые UDP-порты |
|
OSPF |
Show Areas |
Области OSPF |
Show Link-state Database |
Содержимое базы данных состояния связей |
|
Show Neighbors |
Информация о соседних маршрутизаторах |
|
Show Virtual Interfaces |
Информация о виртуальных интерфейсах |
|
RIP |
Show Neighbors |
Информация о соседних маршрутизаторах |
IGMP/ <Интерфейс> |
Show Interface Group Table |
Информация о группах вещания, членом которых является данный интерфейс |
NAT/Basic Firewall |
Show DHCP Allocator Information |
Статистика по работе механизма выделения IP-адресов через механизм NAT |
Show DNS Proxy Information |
Статистика по работе механизма разрешения доменных имен посредством механизма NAT |
|
NAT/Basic Firewall/ <Интерфейс> |
Show Mapping |
Информация о существующих преобразованиях (отображениях) |