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

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

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

Внимание

Далее мы рассмотрим процесс ручной настройки механизма маршрутизации с вызовом по требованию. Однако настоятельно рекомендуется использовать Demand Dial Interface Wizard (Мастер интерфейса вызова по требованию), чтобы автоматизировать процесс настройки. Этот мастер выполняет все шаги конфигурации, описанные ниже, кроме создания статического маршрута.

Конфигурирование Маршрутизатора 1

Настройка маршрутизации с вызовом по требованию на Маршрутизаторе 1 состоит из следующих трех шагов:

1.Создать интерфейс с вызовом по требованию.

2.Создать статический маршрут.

3.Создать учетную запись Windows, которая может использоваться Маршрутизатором 2 для установки соединения с Маршрутизатором 1.

Создание интерфейса с вызовом по требованию

При помощи оснастки Routing and Remote Access (Маршрутизация и удаленный доступ) администратор на Маршрутизаторе 1 создает интерфейс (с именем DD_SPb) с вызовом по требованию со следующей конфигурацией:

оборудование: модем на СОМ1;

номер телефона: (812)765-4321 begin_of_the_skype_highlighting (812)765-4321 end_of_the_skype_highlighting;

протоколы: 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

Настройка маршрутизации с вызовом по требованию на Маршрутизаторе 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 предоставлено разрешение на удаленный доступ.

Окончательная конфигурация

Окончательная конфигурация маршрутизируемой сети с вызовом по требованию изображена на рис. 8. Указаны все интерфейсы с вызовом по требованию, статические маршруты и учетные записи Windows для офисов в Москве и Санкт-Петербурге.

Рис. 8. Результирующая конфигурация

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

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

1.Пакеты от 173.75.73.5, предназначенные для 173.75.72.10, передаются Маршрутизатору

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 begin_of_the_skype_highlighting (812)765-4321 end_of_the_skype_highlighting.

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 может быть использована для создания пакетных файлов, автоматизирующих инициацию процесса автоматического статического обновления.

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

Применение маршрутизатора Windows Server 2003 для организации виртуальных частных сетей

Механизм маршрутизации с вызовом по требованию может быть использован для организации пересылки маршрутизируемого трафика через Интернет путем организации виртуальной частной сети (Virtual Private Network, VPN) между двумя абонентами. Две подсети могут организовать маршрутизацию внутреннего трафика через Интернет (в принципе — через любую открытую внешнюю сеть) по защищенному каналу, созданному посредством протоколов туннелирования L2TP или РРТР. Защищенный канал создается

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

Пример реализации данного сценария приведен на рис. 9.

Рис. 9. Организация виртуальной частной сети при помощи механизма маршрутизации с вызовом по требованию

Использование Windows Server 2003 в

качестве маршрутизатора

Рассмотрим процесс настройки службы маршрутизации и удаленного доступа 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.ru.hcl).

Конфигурирование службы маршрутизации и удаленного доступа

Служба маршрутизации и удаленного доступа (Routing and Remote Access Service, RRAS) устанавливается автоматически в процессе установки Windows Server 2003. Однако при этом она остается в неактивном состоянии. Прежде чем эта служба сможет быть использована для маршрутизации сообщений, необходимо ее активизировать и должным образом сконфигурировать. Активизация службы выполняется при помощи специального мастера Routing and Remote Access Server Setup Wizard. Этот мастер кроме собственно активизации позволяет выполнить настройку службы в соответствии со стоящими перед администратором задачами. Если служба уже была активизирована ранее (например, при развертывании сервера удаленного доступа), администратор должен выполнить ручную настройку службы.

Работа с мастером Routing and Remote Access Server Setup Wizard

Для запуска мастера необходимо в пространстве имен оснастки Routing and Remote Access вызвать контекстное меню объекта, ассоциированного с сервером, и выбрать в нем пункт

Configure and Enable Routing and Remote Access (Конфигурировать и разрешить маршрутизацию и удаленный доступ). На странице Custom Configuration (Конфигурирование) мастера необходимо выбрать переключатель Custom configuration (Заказная конфигурация). В следующем окне мастера (рис. 10) необходимо установить флажки напротив тех компонентов, которые должны быть активизированы на конфигурируемом сервере.

Рис. 10. Выбор режимов работы службы маршрутизации и удаленного доступа Нажмите ссылку - http://sdam-sam.com/sdat-kvartiru/ сдать квартиру

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

Внимание

Если на компьютере имеются входящие подключения (incoming connections), мастер

Routing and Remote Access Server Setup Wizard запустить невозможно. Нужно сначала удалить их, а затем запустить мастер снова.

Конфигурирование портов и устройств

Согласно терминологии службы маршрутизации и удаленного доступа, под устройством (device) понимается аппаратное или программное обеспечение, предоставляющее порты для установки соединений "точка-точка". Протоколы РРТР или L2TP — примеры виртуальных многопортовых устройств. Чтобы служба маршрутизации и удаленного доступа могла использовать конкретное устройство (порт), нужно разрешить ее функционирование для этого устройства. Для этого необходимо вызвать окно свойств объекта Ports (Порты), расположенного в пространстве имен оснастки Routing and Remote Access. На вкладке Devices (Устройства) следует выбрать требуемое устройство с вызовом по требованию, а затем нажать кнопку Configure (Настроить).

В окне Configure Device (Настройка устройства) (рис. 11) необходимо установить флажок

Demand-dial routing connections (inbound and outbound) (Подключения по требованию

(входящие и исходящие)), а затем нажать кнопку ОК.

Рис. 11. Разрешение использования устройства для организации маршрутизации с вызовом по требованию

Создание статических маршрутов

Уадминистратора имеется две возможности для создания статических маршрутов:

при помощи утилиты командной строки Route.exe;

используя графический интерфейс оснастки Routing and Remote Access. В контекстном меню объекта Static Route (Статический маршрут) необходимо выбрать пункт New Static Route (Создать статический маршрут). В открывшемся окне требуется определить обязательные параметры маршрута (рис. 12).

Если создается маршрут для интерфейса с вызовом по требованию, поле Gateway (Шлюз по умолчанию) окажется недоступным.

Рис. 12. Создание статического маршрута

Развертывание протокола маршрутизации RIP

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

Для установки на маршрутизаторе протокола RIP необходимо в контекстном меню объекта General (Общие) выбрать пункт New Routing Protocol (Новый протокол маршрутизации). В открывшемся окне следует выбрать из списка элемент RIP Version 2 for Internet Protocol. Система выполнит установку всех необходимых компонентов. В пространстве имен оснастки появится новый контейнер — RIP.

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

Развертывание протокола маршрутизации OSPF

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