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

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

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

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

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

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

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

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

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

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

Bridged – это рабочая производственная сеть в моем кабинете. Виртуальные сетевые карты соединены мостом с этой сетью, имеют рабочие Айпишники в сети, и подключены к Вебу через эту сеть.
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 представляют собой шлюзы по дефлоту, которыми вы воспользуетесь, когда будете настраивать провайдеры для вашей производственной конфигурации. Как следует, внутренний Айпишник RRAS1 представляет собой шлюз по дефлоту вашего первого провайдера, а внутренний Айпишник RRAS2 – второго. Наша тестовая среда несколько отличается: в ней действующее соединение с Вебом размещается в сети bridged; из-за этого наружные интерфейсы RRAS1 и RRAS2 употребляют один и тот же шлюз по дефлоту
Я использую отдельные сетевые карты на брандмауэре TMG для каждого провайдера; это не является нужным, и в последующей статье я покажу альтернативную конфигурацию, где не будет отдельных сетевых карт для соединений с провайдерами
Такую же сегментацию сети можно получить и при помощи других средств виртуализации – Windows Virtual PC, ESX и Hyper-V поддерживают подобные способы сегментации

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

Набросок 1

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

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

Набросок 2

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

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

Другими словами процедура такая:

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

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

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

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

Набросок 3

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

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

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

Набросок 4

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

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

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

Набросок 5

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

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

Набросок 6

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

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

Набросок 7

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

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

Набросок 8

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

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

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

Заключение

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

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

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