Проверка функции ISP Redundancy в TMG 2010 RC – Часть 2: Включение функции ISP Redundancy

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

Для начала откройте консоль брандмауэра TMG и щелкните на узле Networking в левой панели консоли. В панели Task, щелкните вкладку Tasks. Теперь щелкните на ссылку Configure ISP Redundancy, как показано на рисунке ниже.

Появится страница Welcome to the ISP Redundancy Configuration Wizard. Щелкните Next.

На странице ISP Redundancy Mode вам предлагается два варианта на выбор:

• Load balancing with failover capability. Эта опция позволяет вам использовать оба провайдера одновременно. Вы можете указать предпочитаемого провайдера, чтобы большая часть трафика шла через него, или можете установить одинаковое использование обоих провайдеров. Эта опция предназначена на случай, если вам нужна большая суммарная пропускная способность, и вас не слишком волнует необходимость оплачивать обе линии сразу. Если связь с одним провайдером пропадает, весь трафик пойдет через другого провайдера.
• Failover only. Эта опция предназначена на тот случай, если вы хотите работать с одним провайдером, а второй держать в резерве до того, как связь с первым прервется. Воспользуйтесь этим вариантом, если вы не хотите платить за две линии сразу, и вам нужна гарантия, что ваше соединение с сетью будет постоянным, даже если связь с основным провайдером пропадет. Если вы не хотите оплачивать лишнюю пропускную способностью, этот вариант – для вас.

В нашем примере выбераем опцию Load balancing with failover capability. Щелкните Next.

На странице ISP Connection 1 вы настраиваете соединение с первым провайдером. В нашем примере мы назовем соединение RRAS1, поскольку оно будет осуществляться через NAT-сервер RRAS1, имитирующем первого провайдера. Так как мы используем отдельные сетевые карты для каждого соединения с провайдером, мы можем выбрать сетевую карту, соединяющую нас с RRAS1, в выпадающем списке Network adapter (optional). Обратите внимание: после того, как мы выбрали сетевую карту, адрес подсети, определяющий шлюз по умолчанию для данной сетевой карты, являющийся внутренним адресом NAT-сервера RRAS1, оказывается в списке в текстовом окне Subnet. Помните, что провайдеры должен находиться в сетях с различными адресами, то есть соединения с провайдерами должны находиться в разных подсетях.

Щелкните Next.

На странице ISP Connection 1 ' Configuration проверьте адрес шлюза, Gateway address, и маску - Mask. Также убедитесь в том, что текстовое окно Subnet содержит правильную маску подсети. Вы можете ввести первичный DNS-сервер, Primary DNS server, и альтернативный DNS-сервер, Alternate DNS server, если хотите, но поскольку есть настоятельная рекомендация не настраивать использование брандмауэром внешних DNS-серверов, я предлагаю вам никогда не вводить адресов в данных текстовых окнах. У вас будут ситуации, когда нужно будет ввести внешний IP-адрес для DNS-серверов на брандмауэре TMG, но этот не тот случай.

Щелкните Next.

На странице ISP Connection 1 ' Dedicated Servers введите IP-адреса серверов, которые должны всегда использовать данное соединение с провайдером. Обычно это серверы из сети провайдера, которые недоступны извне, например, DNS-серверы и серверы синхронизации. SMTP-серверы также часто размещаются в сети провайдера для исходящих сообщений, недоступных извне. Так как в нашем примере мы не используем перенаправления, а также пользуемся серверами синхронизации из Интернета, мы не будем вводить IP-адреса соответствующих серверов.

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

Щелкните Next.

На странице ISP Connection 2 вы делаете то же самое, что и на аналогичной странице для первого провайдера. В нашем примере, второй провайдер будет подключаться через NAT-сервер RRAS2. Обратите внимание на то, что подсеть (Subnet) располагается по адресу сети, отличному от подсети первого провайдера.

Щелкните Next.

Проверьте настройки на странице ISP Connection 2 ' Configuration и щелкните Next.

На странице ISP Connection 2 ' Dedicated Servers введите IP-адреса серверов, доступных соединению со вторым провайдером. Здесь применимы те же принципы и ограничения, что и для первого провайдера.

Щелкните Next.

На странице Load Balancing Configuration укажите, какие веса вы хотите присвоить соединениям. Если скорость у обоих соединений одинаковая, обычно устанавливается одинаковое использование провайдеров. А если у одного из провайдеров скорость больше, вероятно, лучше будет придать больший вес ему. В данном примере, RRAS2 быстрее, чем RRAS1, поэтому я отдам ему 75% всех соединений, а RRAS1 - 25% соединений. Метод распределения соединений я описывал в первой статье цикла, так что если вы хотите узнать, как брандмауэр TMG делает это, обратитесь к первой части.

Щелкните Next.

Проверьте настройки на странице Completing the ISP Redundancy Configuration Wizard, а затем щелкните Finish.

После того, как вы нажмете Finish, появится диалоговое окно, информирующее вас о том, что вы должны добавить постоянные статические маршруты для каждого IP-адреса в DNS, настроенного на внешнесетевых адаптерах на каждом сервере Forefront TMG. Это нужно для того, чтобы убедиться в том, что DNS-запросы отправляются через соответствующий сетевой адаптер.

Причина ручного создания статических маршрутов для провайдеров заключается в том, что автоматическая маршрутизация при функции ISP Redundancy работает только в том случае, если существует взаимодействие на уровне NAT между источником и пунктом назначения. Поскольку DNS-соединения исходят от самого брандмауэра TMG, соединение должно взаимодействовать на уровне маршрута, так как все соединения от сети Local Host Network с любой другой сетью используют взаимодействие на уровне маршрута.

Щелкните OK.

Щелкните Apply для сохранения конфигурации брандмауэра. Внесите описание изменений в диалоговом окне Configuration Change Description, если хотите, а затем щелкните Apply в этом же диалоговом окне. Щелкните OK в диалоговом окне Saving Configuration Changes.

А теперь давайте посмотрим, как функционирует ISP Redundancy. Сначала обратим внимание на панель Dashboard. Здесь показывается информация о статусе сети (Network Status) для каждого соединения с провайдером. На рисунке ниже вы видите статус(Status) , время безотказной работы (Uptime) и скорость (Bytes/Sec) для каждого провайдера. Заметьте: значительную часть полосы использовалась RRAS2, потому что когда я делал скриншот, я скачивал Windows XP SP2 через брандмауэр TMG.

А что если вам понадобится изменить настройки конфигурации функции ISP Redundancy? Просто щелкните на узел Networkingв левой панели консоли брандмауэра TMG и сделайте двойной щелчок на соединении с провайдером, свойства которого вы хотите поменять. На рисунке ниже показана вкладка General диалогового окна RRAS1 Properties. Здесь вы можете поменять название (Name), IP-адрес шлюза (Gateway IP address), маску (Mask), подсеть (Subnet), определение соединения (Connectivity detection) и соотношение балансировки нагрузки Load Balancing ratio.

Обратите внимание: пункт Connectivity detection не показывался в мастере. Тут у вас есть три опции:

• Disable, connection is down. При этом отключается определение, есть ли нет связь с провайдером, и отключается соединение с провайдером. Понадобиться эта опция вам может для административных или тестовых целей.
• Disabled, connection is up. Эта опция отключает определение, есть или нет связь с провайдером, но оставляет включенным соединение. Эта опция вам может понадобиться, если вы хотите использовать данное соединение с провайдером все время, вне зависимости от состояния связи.
• Enabled. Это опция по умолчанию.

Возможно, вам стало интересно, каким образом брандмауэр TMG определяет, есть ли связь с провайдером или нет. Это хороший вопрос. TMG отправляет запросы на соединение к корневым DNS-серверам Интернета. Если соединение происходит, значит, связь работает. Соответственно, если соединения нет, значит, связь отсутствует.

Проверить это мы можем, посмотрев на след в NetMon на рисунке ниже. IP-адреса 10.0.2.3 и 10.0.1.3 являются внешними адресами для брандмауэра TMG, к которым он подключается при каждом соединении с провайдером. Адрес пункта назначения, 192.33.4.12 - IP-адрес одного из корневых DNS-серверов Интернета. Любопытно здесь то, что это не совсем DNS-запросы: это просто соединения TCP-порта 53 с корневыми DNS-серверами. Если вы посмотрите на расшифровку, вы увидите, что протокольная информация по DNS отсутствует. Вы увидите только трехстороннее «рукопожатие». Уверен, для этого есть важная причина, но не знаю, какая.

Теперь о том, как брандмауэр TMG определяет, какая связь отсутствует, и как он обнаруживает, что связь снова появилась.

Множество серверов опрашивается, чтобы определить наличие проблем со связью для конкретного провайдера. Если ответы от нескольких корневых DNS-серверов не получены через конкретного провайдера, TMG повторяет попытку подключения еще два раза (всего три попытки, включая первую) с интервалом в 60 секунд перед тем, как переключиться на соединение со вторым провайдером и отметить первое как нерабочее.

То есть, если соединение с RRAS1 в действительности пропало в 12:58, попытки соединиться с корневыми DNS-серверами будут происходит еще в 12:59 и в 13:00. И если эти попытки окажутся неудачными, связь считается потерянной. В промежуток времени между 12:58 и 13:00 соединения все еще будут направляться через нерабочий провайдер.

Когда соединение с провайдером считается потерянным, брандмауэр TMG будет проверять упавший провайдер каждые 5 минут (300 секунд) и когда упавшее соединение отвечает в первый раз, следом производятся еще две попытки с интервалом в 60 секунд, и если все они успешны, эта линия считается снова рабочей. Когда основная линия начинает считаться рабочей, TMG будет создавать новые соединения через этот провайдер.

То есть, если соединение с RRAS1 отмечено как нерабочее в 13:00, оно не будет проверяться снова до 13:05. В 13:05 происходит проверка. В случае успеха, проверка снова пойдет в 13:06 и еще раз в 13:07. Если все эти проверки успешны, связь отмечается как рабочая и соединения пойдут через данную линию снова.

Чтобы посмотреть, что происходит при прерывании работы провайдера, я отключил RRAS2. Если подождать 2-3 минуты, вы увидите в узле Dashboard в левой панели консоли брандмауэра TMG, что статус поменялся на Local.

Ну, это не проблема! Я перешел к моему клиенту, скачал файл и тот автоматически переместился на RRAS1. Не забывайте о том, что если клиент воспользовался упавшим провайдером, чтобы обратиться к конкретному сайту, только через примерно 2 минуты соединение с сайтом будет отдано рабочему провайдеру.

Если вы посмотрите в Alerts, вы увидите одно предупреждение, информирующее вас о том, что связь с провайдером недоступна, как показано на рисунке ниже.

Что касается предупреждений, некоторые из них относятся к функции ISP Redundancy (см. рисунок ниже).

Заключение

Во второй части цикла статей я рассказал о том, как работает функция ISP Redundancy, как настроить ваши сетевые карты, чтобы они были готовы к работе с функцией ISP Redundancy, а также как настроить саму функцию. Обращаю ваше внимание на то, что данный цикл статей посвящен конкретному случаю использования, где у вас для каждого провайдера есть отдельная сетевая карта. Это не является необходимостью. Вы можете настроить и IP-адреса провайдеров, и IP-адреса шлюзов на одной сетевой карте. Если кому-то интересно, я могу написать отдельную статью по поводу такой конфигурации, но мне кажется это довольно простым случаем, в котором применимы те же самые принципы. Наслаждайтесь функцией ISP Redundancy в TMG и дайте мне знать, что думаете о ней и о том, как она работает у вас!