Проверка функции ISP Redundancy в TMG 2010 RC – Часть 1: Настройка виртуальной инфраструктуры и интерфейсов брандмауэра TMG

Одной из тех функций, появления которых я с нетерпением ждал в TMG 2010, была функция балансировки нагрузки провайдеров(ISP load balancing). Если вы уже знакомы с брандмауэром ISA, вероятно, вы знаете, что поддержка нескольких провайдеров – то, чего не хватало со времен выхода ISA 2004. Это нужная функция, и в грядущем брандмауэре TMG она у нас будет!

Перед тем, как перейти к подробностям о многопровайдерных возможностях TMG, рассмотрим некоторые моменты, о которых необходимо сказать заранее:

• Хотя о функции говорят как о поддержке «многопровайдерности», на самом деле количество провайдеров ограничено двумя
• Необходимо взаимодействие на уровне NAT между сетями источника и назначения; то есть если у вас используется взаимодействие на уровне маршрутизации на любой из защищаемых брандмауэром TMG сетей, воспользоваться функцией многопровайдерности вы не сможете
• Каждое соединение с провайдером требует подключения к шлюзу по умолчанию, который располагается по другому сетевому номеру, т.к. шлюзы по умолчанию не могут находиться в сети с одинаковым ID (то есть внешние IP-адреса в брандмауэре TMG не могут иметь один и тот же сетевой номер)
• Ваши внешние интерфейсы не могут использовать DHCP для получения их адресов; если вы подключены к провайдеру как домашний пользователь, поддержка нескольких провайдеров – не для вас
• Вы можете разместить оба соединения с провайдерами на одной сетевой карте, либо на двух сетевых картах; в данной статье пойдет речь о конфигурации с двумя сетевыми картами, при этом когда каждое соединение с провайдером представлено отдельным внешним интерфейсом
• Разгрузка процессора должна быть либо включена, либо выключена на обеих сетевых картах; если она включена на одной и выключена на другой, тогда и на первой она работать не будет.

Это то, что вам необходимо знать о многопровайдерности до того, как мы начнем углубляться в детали.

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

• Failover only - в этом режиме все время используется только один провайдер, пока он не станет недоступным. Когда это происходит, все соединения направляются ко второму провайдеру. Это хороший выбор на случай, если одна линия у вас быстрая, а вторая - медленная (хотя и достаточно быстрая для того, чтобы продержаться до восстановления первой), кроме того, вам не придется много платить за полосу, используемую довольно редко
• Failover and load balancing - в этом режиме используются обе линии. У вас есть возможность установить веса для каждой линии на тот случай, если равное использование обеих линий вас не устраивает. Если одна из линий разрывается, все соединения переходят на работающую линию

На бумаге все это выглядит прекрасно, но работает ли оно на самом деле? Да, работает. Но вы хотите верить мне на слово или самостоятельно разобраться в теме? Подозреваю последнее. Поэтому я хочу показать вам, как все это настроить в виртуальной среде.

Как вы, вероятно, знаете, моя любимая среда для статей на ISAserver.org - VMware Workstation (сейчас я использую версию 6.5). Почему? Потому что я ее всегда использовал, она у меня работает, я хорошо разбираюсь в ней и в ее сетевой модели. При этом я не призываю вас тоже использовать VMware Workstation для тестирования собственной конфигурации. Если вам нравится Windows Virtual PC, ESX Server или Microsoft Hyper-V, они тоже отлично справятся. Разница будет только в терминологии, однако принципы применимы к любому из этих продуктов.

Начнем с базовой виртуальной сетевой схемы для нашей тестовой среды. Мы будем работать с четырьмя виртуальными сетями или виртуальными коммутаторами, каждый из которых принадлежит отдельному физическому или виртуальному сегменту Ethernet.

• Bridged - это рабочая производственная сеть в моем офисе. Виртуальные сетевые карты соединены мостом с этой сетью, имеют рабочие IP-адреса в сети, и подключены к Интернету через эту сеть.
• VMNet3 - это виртуальный коммутатор, представляющий сегмент Ethernet, соединяющий брандмауэр TMG с первым провайдером
• VMNet4 - это виртуальный коммутатор, представляющий сегмент Ethernet, соединяющий брандмауэр TMG со вторым провайдером
• VMNet2 - это виртуальный коммутатор, представляющий сегмент Ethernet, соединяющий внутренний интерфейс брандмауэра TMG с сетью Интернет по умолчанию

На рисунке ниже показаны все эти виртуальные коммутаторы и устройства, к ним подключенные:

• RRAS1 - это ВМ Windows Server 2003 с настроенной службой RRAS, настроенная как сервер NAT. Внешний интерфейс этой ВМ подключен к сети Bridged, а внутренний интерфейс подключен к VMNet3, соединяя сетевую карту брандмауэра TMG, связанную с провайдером RRAS1, c сервером NAT RRAS
• RRAS2 - это ВМ Windows Server 2003 с настроенной службой RRAS, настроенная как сервер NAT. Внешний интерфейс этой ВМ подключен к сети Bridged, а внутренний интерфейс подключен к VMNet4, который соединяет сетевую карту брандмауэра TMG, связанную с провайдером RRAS2, c сервером NAT RRAS
• TMG Firewall - у брандмауэра TMG три сетевые карты. Одна соединена с VMNet3, подключенной к провайдеру RRAS1; другая соединена с VMNet4, подключенной к провайдеру RRAS2; и еще одна соединена с VMNet2, подключенной к сети Интернет по умолчанию
• DC - контроллер домена Windows Server 2003 для домена msfirewall.org; брандмауэр TMG относится к этому домену и подключается к VMNet2

Некоторые замечания о конфигурации:

• Узлы RRAS1 и RRAS2 представляют собой шлюзы по умолчанию, которыми вы воспользуетесь, когда будете настраивать провайдеры для вашей производственной конфигурации. Следовательно, внутренний IP-адрес RRAS1 представляет собой шлюз по умолчанию вашего первого провайдера, а внутренний IP-адрес RRAS2 – второго. Наша тестовая среда несколько отличается: в ней действующее соединение с Интернетом располагается в сети bridged; из-за этого внешние интерфейсы RRAS1 и RRAS2 используют один и тот же шлюз по умолчанию
• Я использую отдельные сетевые карты на брандмауэре TMG для каждого провайдера; это не является необходимым, и в следующей статье я покажу альтернативную конфигурацию, где не будет отдельных сетевых карт для соединений с провайдерами
• Такую же сегментацию сети можно получить и с помощью других средств виртуализации - Windows Virtual PC, ESX и Hyper-V поддерживают аналогичные методы сегментации

Теперь, когда у нас определена инфраструктура виртуальной сети, посмотрим на схему IP-адресации. Информация об IP-адресации, с которой мы работаем сейчас, отображена на рисунке ниже. Обратите внимание на сетевую карту провайдера RRAS1 в TMG, которая использует внутренний интерфейс RRAS1 как шлюз по умолчанию, при этом сетевая карта RRAS2 использует внутренний интерфейс RRAS2 как шлюз по умолчанию. Также обратите внимание на то, что сетевой сегмент RRAS1 располагается в диапазоне адресов 10.0.1.0/24, а сегмент RRAS2 - 10.0.2.0/24.

Внутренняя сеть по умолчанию брандмауэра TMG - 10.0.0.0/24, а контроллер доменов во внутренней сети по умолчанию использует брандмауэр TMG как шлюз по умолчанию.

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

Например, предположим, что первому провайдеру отдается 75% нагрузки, а второму – 25% .Если число, полученное из хэша, равно 30, соединение передается первому провайдеру. Если бы число, полученное из хэша, равнялось 80, соединение бы передавалось второму провайдеру.

То есть процедура такая:

• Проверка числа нагрузки основной линии, представленного в процентах
• Если число, полученное из хэша, меньше числа нагрузки, соединение переходит на основную линию
• Если число, полученное из хэша, больше числа нагрузки, соединение переходит на вторичную линию

На рисунке ниже представлен пример. Провайдеру RRAS1 назначено 75% соединений, а провайдеру RRAS2 – 25%. Интерфейсы конфигураций вы видите на рисунке. Когда PC-1 подключается к WEB-1, число, полученное из хэша, равно 60. Поскольку это меньше, чем процент, отведенный основному соединению, нагрузка передается именно ему, в данном случае – провайдеру RRAS1. Когда PC-1 подключается к WEB-2, число, полученное из хэша, равно 80, что больше процента, отведенного основному соединению, поэтому соединение переходит ко второму провайдеру.

Конечно, если вы установите одинаковые проценты (50%) для каждого провайдера, половина чисел, полученных из хэша, будет больше 50, а половина – меньше, поэтому все соединения будут равномерно распределяться между провайдерами.

А что с настройкой сетевого интерфейса для брандмауэра TMG? Эта тема была несколько неясной до недавнего времени, когда появился пост в блоге команды TMG Firewall, где они хорошо пояснили, что нужно делать (то, чего не было в файле справки).

На рисунке ниже вы видите сетевые интерфейсы, настроенные для брандмауэра TMG, используемого в данном примере. Интерфейс LAN соединен с VMNet2, интерфейс WAN соединен с VMNet3 и WAN2 соединен с VMNet4.

Интерфейс WAN представлен первой сетевой картой, настроенной для брандмауэра, поэтому он получил шлюз по умолчанию перед началом настройки брандмауэра TMG. На рисунке ниже вы видите, что ему был приписан IP-адрес, соответствующий провайдеру RRAS1, и дан шлюз по умолчанию – внутренний IP-адрес виртуальной машины RRAS1 (это и будет шлюз по умолчанию вашего действующего первого провайдера в производственной среде).

Однако вам нужно сделать еще одну вещь. Нужно открыть настройки TCP/IP, перейти к Advanced и отключить функцию Automatic metric. Microsoft рекомендует так поступать, чтобы функция избыточности провайдеров корректно работала, возможно, дело тут в несовместимости механизмов маршрутизации в Windows и в TMG – подробностей от Microsoft не было. Так или иначе, но вам придется отключить автоматику и вручную настраивать метрику. Само значение неважно, насколько я могу судить, единственное требование – предпочтительный интерфейс должен иметь меньшую метрику, чем вторичный. На рисунке ниже вы видите, что я установил метрику предпочтительного соединения в 1.

На рисунке ниже показана информация об IP-адресации для вторичного провайдера, т.е. RRAS2. Метрику этого интерфейса я установил в 2.

Ого! А что это? Windows недовольна тем, что я установил два шлюза по умолчанию на одной машине. Я не могу винить Windows за это, ведь, как известно, так делать не следует. Однако функция избыточности провайдеров в TMG позволяет нам нарушить это правило, поэтому можно спокойно нажимать Yes, так как мы уверены, что все будет в порядке.

Просто для интереса, перед тем, как запустить функцию избыточности провайдеров на брандмауэре TMG, я решил глянуть, какой интерфейс будет использоваться. Я уже настроил брандмауэр TMG и создал правило 'all open' (очень популярное при тестировании и совсем не популярное в рабочих производственных средах). С помощью tracert я выяснил, что использовался предпочтительный интерфейс. Это правильно; возможно, так получилось из-за более низкой метрики? Или, может, из-за того, что этот интерфейс первым настраивался на этом компьютере и первым получил шлюз по умолчанию? Если у меня найдется время, я посмотрю, что будет, если переключить метрики.

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

• Создал начальную виртуальную машину с двумя сетевыми картами: внутренней и внешней
• Внес информацию об IP-адресации на внутренний и внешний интерфейсы
• Установил брандмауэр TMG
• Убедился в том, что установка брандмауэра TMG успешно завершилась
• Отключил ВМ TMG и установил третью виртуальную сетевую карту для поддержки линии вторичного провайдера
• После перезапуска ВМ настроил третью виртуальную сетевую карту
• Перезапустил ВМ после настройки информации об IP-адресации на третьем интерфейсе

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

Заключение

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