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

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

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

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

Набросок 1

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

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

Набросок 2

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

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

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

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

Набросок 3

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

Щелкните Next.

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

Набросок 4

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

Щелкните Next.

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

Набросок 5

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

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

Щелкните Next.

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

Набросок 6

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

Щелкните Next.

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

Набросок 7

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

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

Набросок 8

На страничке ISP Connection 2 ‘ Dedicated Servers введите Айпишники серверов, доступных соединению со вторым провайдером. Тут применимы те же принципы и ограничения, что и для первого провайдера.

Щелкните Next.

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

Набросок 9

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

Щелкните Next.

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

Набросок 10

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

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

Набросок 11

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

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

Щелкните OK.

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

Набросок 12

Щелкните 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 в TMG 2010 RC – Часть 2: Включение функции ISP Redundancy

Набросок 13

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

Направьте внимание: пункт Connectivity detection не показывался в мастере. Здесь у вас есть три функции:

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

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

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

Набросок 14

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

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

Набросок 15

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

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

Другими словами, если соединение с 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.

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

Набросок 16

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

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

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

Набросок 17

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

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

Набросок 18

Заключение

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

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.