Развертывание высокодоступных NVAs

В этой статье описываются наиболее распространенные варианты развертывания набора сетевых виртуальных устройств (NVA) для обеспечения высокой доступности в Azure. NVA обычно используется для управления потоком трафика между сегментами сети, классифицированными с различными уровнями безопасности, например между виртуальной сетью De-Militarized (DMZ) и общедоступным Интернетом, или для подключения внешних расположений к Azure, например VPN или SDWAN (Software-Defined глобальной сети).

Существует множество шаблонов проектирования, в которых виртуальные машины используются для проверки трафика между различными зонами безопасности, например:

• Проверка исходящего трафика из виртуальных машин в Интернет и предотвращение кражи данных.
• Чтобы проверить трафик входящего трафика из Интернета в виртуальные машины и предотвратить атаки.
• Чтобы отфильтровать трафик между виртуальными машинами в Azure, чтобы предотвратить боковое перемещение скомпрометированных систем.
• Фильтрация трафика между локальными системами и виртуальными машинами Azure, если они считаются принадлежащими к разным уровням безопасности. (Например, если Azure размещает dmZ и локальные внутренние приложения.)
• Завершение туннелей VPN или SDWAN из внешних расположений, таких как локальные сети или другие общедоступные облака.

Существует множество примеров NVAs, включая следующие:

• Сетевые брандмауэры
• Прокси-серверы обратного уровня 4
• Конечные точки VPN IPsec
• Устройства SDWAN
• Веб-серверы обратного прокси с функциональностью брандмауэра веб-приложения
• Интернет-прокси, чтобы ограничить доступ к интернет-страницам из Azure
• Подсистемы балансировки нагрузки уровня 7

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

Первый вопрос, на который следует ответить, заключается в том, почему требуется высокий уровень доступности для сетевых виртуальных устройств. Причина заключается в том, что эти устройства управляют обменом данными между сегментами сети. Если они недоступны, сетевой трафик не может выполняться, а приложения перестают работать. Запланированные и незапланированные сбои иногда приводят к сбою экземпляров NVA (как и любая другая виртуальная машина в Azure или любом другом облаке). Экземпляры удаляются, даже если эти NVA настроены с управляемыми дисками уровня "Премиум" для предоставления единого экземпляра соглашения об уровне обслуживания в Azure. Поэтому для высокодоступных приложений требуется по крайней мере второй NVA, который может обеспечить подключение.

предварительные требования: в этой статье предполагается базовое представление о сети Azure, azure Load Balancersи маршрутизации трафика виртуальной сети (определяемые пользователем).

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

• Время конвергенции: сколько времени занимает каждое проектирование, чтобы управлять трафиком от неудачного экземпляра NVA?
• Поддержка топологии: какие конфигурации NVA поддерживают каждый вариант разработки? Активный или активный, активный или резервный, масштабируемые кластеры NVA с избыточностью n+1?
• Симметрия трафика: заставляет ли NVA выполнять преобразование адресов исходной сети (SNAT) на пакетах, чтобы избежать асимметричной маршрутизации? Или симметрия трафика применяется другими средствами?

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

Общие сведения об архитектуре высокого уровня доступности

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

Проектирование Подсистемы балансировки нагрузки

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

• Внутренняя подсистема балансировки нагрузки используется для перенаправления внутреннего трафика из Azure и локальной среды в NVA. Эта внутренняя подсистема балансировки нагрузки настроена с правилами портов высокого уровня доступности, чтобы каждый порт TCP/UDP перенаправлялся на экземпляры NVA.
• Общедоступная подсистема балансировки нагрузки предоставляет сетевые сети в Интернете. Так как порты высокого уровня доступности предназначены для входящего трафика, каждый отдельный порт TCP/UDP должен быть открыт в выделенном правиле балансировки нагрузки.

На следующей схеме описывается последовательность прыжков, которые пакеты из Интернета на сервер приложений в периферийной виртуальной сети будут выполняться с обходом сетевого сетевого подключения брандмауэра для управления трафиком в общедоступный Интернет (также называемый "Северо-южный трафик").

Скачайте файл Visio данной архитектуры.

Механизм отправки трафика из периферийных узлов в общедоступный Интернет через NVAs — это маршрут User-Defined для 0.0.0.0/0 с помощью следующего прыжка IP-адреса внутренней подсистемы балансировки нагрузки.

Для трафика между Azure и общедоступным Интернетом каждое направление потока трафика пересекает другую подсистему балансировки нагрузки Azure. Это происходит даже в том случае, если брандмауэр NVA имеет единый сетевой адаптер для общедоступных и внутренних сетей, так как пакет входящего трафика проходит через общедоступную подсистему балансировки нагрузки и исходящий пакет проходит через внутреннюю подсистему балансировки нагрузки. Так как оба направления потока проходят через различные подсистемы балансировки нагрузки, если требуется симметрия трафика, как правило, в большинстве брандмауэров необходимо выполнить преобразование сетевых адресов источника (SNAT) экземплярами NVA, чтобы привлечь возвращаемый трафик и избежать асимметрии трафика.

Ту же структуру с подсистемами балансировки нагрузки можно использовать, а также для проверки трафика между Azure и локальными сетями (восточная или западная часть), где участвует только внутренняя подсистема балансировки нагрузки:

Механизм отправки трафика между периферийными узлами через NVAs точно такой же, поэтому ни одна другая схема не предоставляется. В приведенных выше примерах схем, так как spoke1 не знает о диапазоне периферийных2, 0.0.0.0/0 UDR отправляет трафик, направленный на речь2 во внутреннюю подсистему балансировки нагрузки Azure NVA.

Для трафика между локальными сетями и Azure или между виртуальными машинами Azure симметрия трафика гарантируется в NVAs с одним сетевым адаптером внутренним azure Load Balancer: если оба направления потока трафика проходят через один и тот же Azure Load Balancer, то один и тот же экземпляр NVA будет выбран подсистемой балансировки нагрузки. В случае виртуальных сетевых адаптеров с двумя сетевыми адаптерами, где существует внутренняя подсистема балансировки нагрузки для каждого чувства связи, симметрия трафика должна быть предоставлена через SNAT, как в приведенном выше примере "Север/Юг".

Еще одна проблема, с которой сталкиваются виртуальные сетевые сетевые адаптеры в этом проекте, заключается в том, где отправлять ответы на проверки работоспособности подсистемы балансировки нагрузки. Azure Load Balancer всегда использует тот же IP-адрес, что и источник для проверок работоспособности (168.63.129.16). NVA должен быть в состоянии отправить ответ на проверку работоспособности, полученную из этого IP-адреса, в том же интерфейсе, что и они были получены. Обычно для этого требуется несколько таблиц маршрутизации в операционной системе, так как маршрутизация на основе назначения отправляет ответ на проверки работоспособности всегда через один сетевой адаптер.

Azure Load Balancer имеет хорошее время конвергенции в отдельных сбоях NVA. Так как проб работоспособности можно отправлять каждые 5 секунд, и для объявления экземпляра серверной части из службы обычно требуется 10–15 секунд для конвергентного трафика в другой экземпляр NVA.

Эта программа установки поддерживает как активные, так и активные и резервные конфигурации. Для активных и резервных конфигураций экземпляры NVA должны предложить порт TCP/UDP или конечную точку HTTP, которая отвечает только на пробы работоспособности Load Balancer для экземпляра, который находится в активной роли.

Использование подсистем балансировки нагрузки L7

В частности, этот вариант для устройств безопасности заменяет общедоступную подсистему балансировки нагрузки Azure с подсистемой балансировки нагрузки уровня 7, например шлюза приложений Azure (который можно рассматривать как NVA самостоятельно). В этом случае для NVAs требуется только внутренняя подсистема балансировки нагрузки для трафика, исходящего из систем рабочей нагрузки. Этот механизм иногда используется устройствами с двумя сетевыми картами, чтобы избежать проблемы маршрутизации с проверкой работоспособности Azure Load Balancer, описанной в предыдущем разделе. Одно из ограничений этой структуры заключается в том, что он поддерживает только протоколы уровня 7, поддерживаемые подсистемой балансировки нагрузки уровня 7, обычно HTTP(S).

NVA должен принимать входящий трафик для протоколов, не поддерживаемых подсистемой балансировки нагрузки уровня 7, а также потенциально всех исходящих трафика. Дополнительные сведения об этой конфигурации при использовании брандмауэра Azure в качестве NVA и Шлюза приложений Azure в качестве веб-обратного прокси-сервера уровня 7 см. в разделе брандмауэра и шлюза приложений для виртуальных сетей.

Сервер маршрутизации Azure

сервер маршрутизации Azure — это служба, которая позволяет NVA взаимодействовать с Azure SDN через протокол BGP. Не только NVAs узнали, какие префиксы IP-адресов существуют в виртуальных сетях Azure, но они могут внедрять маршруты в действующие таблицы маршрутов виртуальных машин в Azure.

На схеме над каждым экземпляром NVA выполняется пиринг BGP с сервером маршрутизации Azure. В периферийных подсетях таблица маршрутов не требуется, так как сервер маршрутизации Azure программирует маршруты, объявленные NVAs. Если два или более маршрутов программируются на виртуальных машинах Azure, они используют равные затраты multiPathing (ECMP) для выбора одного из экземпляров NVA для каждого потока трафика. В результате SNAT является обязательным в этой структуре, если симметрия трафика является требованием.

Этот метод вставки поддерживает как активные, так и активные (все NVA объявляют одни и те же маршруты на сервере маршрутизации Azure), а также активный или резервный (один NVA объявляет маршруты с более коротким путем AS, чем другой). Сервер маршрутизации Azure поддерживает не более 8 прилагаемых BGP. Таким образом, если используется масштабируемый кластер активных NVA, эта конструкция поддерживает не более 8 экземпляров NVA.

Время конвергенции быстро выполняется в этой настройке и зависит от хранимых и временных таймеров примечаний BGP. Хотя сервер маршрутизации Azure имеет хранимые и временные таймеры по умолчанию (60 секунд и 180 секунд соответственно), NVAs могут согласовывать более низкие таймеры во время создания примечаний BGP. Установка этих таймеров слишком низкая может привести к нестабильности BGP.

Это наиболее распространенный вариант для NVAs, которые должны взаимодействовать с маршрутизацией Azure, например SDWAN или IPsec NVAs, которые обычно имеют хорошую поддержку BGP и должны узнать префиксы, настроенные в виртуальных сетям Azure, или объявить определенные маршруты через частные пиринги ExpressRoute. Этот тип устройств обычно без отслеживания состояния, поэтому симметрия трафика не является проблемой, поэтому SNAT не требуется.

Gateway Load Balancer

Подсистема балансировки нагрузки шлюза Azure — это новый способ вставки NVA в путь к данным без необходимости управлять трафиком с помощью маршрутов User-Defined. Для виртуальных машин, которые предоставляют свои рабочие нагрузки через Azure Load Balancer или общедоступный IP-адрес, входящий и исходящий трафик можно перенаправлять прозрачно в кластер NVAs, расположенный в другой виртуальной сети. На следующей схеме описывается путь, который пакеты следуют за входящим трафиком из общедоступного Интернета, если рабочие нагрузки предоставляют приложению через Azure Load Balancer:

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

Внедрение служб с помощью Подсистемы балансировки нагрузки шлюза можно использовать для входящих потоков, поступающих в общедоступную подсистему балансировки нагрузки Azure (и их возвращаемый трафик), а также для исходящих потоков, поступающих в Azure. East-West трафик между виртуальными машинами Azure не может использовать подсистему балансировки нагрузки шлюза для внедрения NVA.

В кластере NVA пробы проверки работоспособности Azure Load Balancer используются для обнаружения отдельных сбоев экземпляра NVA, достижения быстрого времени конвергенции (10–15 секунд).

Изменение PIP-UDR

Идея, лежащая в основе этого дизайна, имеет установку, которая будет необходима без избыточности NVA, и изменить ее в случае, если NVA страдает от простоя. На схеме ниже показано, как общедоступный IP-адрес Azure связан с активным NVA (NVA1), а маршруты User-Defined в периферии имеют активный IP-адрес NVA в качестве следующего прыжка (10.0.0.37).

Если активная NVA стала недоступной, резервный NVA вызовет API Azure для переназначления общедоступного IP-адреса и периферийных User-Defined Маршрутов к себе (или переместите частный IP-адрес). Эти вызовы API могут занять несколько минут, чтобы быть эффективными, поэтому эта конструкция предлагает худшее время конвергенции всех вариантов в этом документе.

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

Одним из преимуществ этого проекта является то, что для обеспечения симметрии трафика не требуется преобразование исходных сетевых адресов (SNAT), так как в любой момент времени активен только один NVA.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Основные авторы:

• Кит Майер | Главный архитектор облачных решений
• Telmo Sampaio | Диспетчер инженеров-служб
• Хосе Морено | Главный инженер

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Дальнейшие действия

• Узнайте, как реализовать безопасную гибридную сеть с помощью брандмауэра Azure.
• сети периметра — cloud Adoption Framework
• Cloud DMZ — Cloud Adoption Framework