Облако меняет подходы к проектированию инфраструктуры, в том числе структуры брандмауэров, так как сеть больше не располагается на физическом уровне и не ограничена виртуальными локальными сетями. Виртуальная сеть поддерживает не все возможности физической сети. К ним относятся использование плавающих IP-адресов или широковещательного трафика, что оказывает влияние на реализацию архитектур с высоким уровнем доступности. Подсистемы балансировки нагрузки для сетевых виртуальных модулей (NVA) могут и должны быть реализованы определенным способом для создания высокодоступной архитектуры в виртуальной сети. В этом руководстве описан структурированный подход к проектированию брандмауэров с высоким уровнем доступности в Azure с использованием сторонних виртуальных модулей.
Варианты проектирования высокодоступных виртуальных сетевых модулей
При развертывании архитектур с высоким уровнем доступности существует несколько вариантов для обеспечения отработки отказа:
- Таблицы маршрутов, управляемые API Azure. В этом варианте используются две таблицы маршрутов — одна активная и одна пассивная — для замены IP-адреса активного шлюза для всех служб, работающих в виртуальной сети или подсети.
- Плавающий IP-адрес, управляемый API Azure. В этом варианте используется дополнительный IP-адрес на брандмауэре, который можно перемещать между активным и резервным брандмауэрами.
- Управление с помощью подсистемы балансировки нагрузки. В этом варианте используется служба Azure Load Balancer, которая выступает в роли IP-адреса шлюза для подсети и перенаправляет трафик на активный брандмауэр. Она может даже перенаправлять трафик в режиме "активный — активный", чтобы обеспечить полноценную балансировку нагрузки.
Недостаток первых двух вариантов заключается в том, что отработка отказа выполняется медленно. Брандмауэр должен вызвать отработку отказа, которая по сути является "перенастройкой" служб Azure посредством нового развертывания. В зависимости от того, насколько быстро выполняется развертывание, потоки трафика будут приостановлены на несколько минут. Кроме того, в таких вариантах нельзя использовать конфигурацию "активный — активный", когда оба брандмауэра работают одновременно.
Поэтому третий вариант является наиболее предпочтительным. Время простоя сводится к минимуму, так как подсистема балансировки нагрузки может выполнить отработку отказа практически мгновенно на резервный брандмауэр (в режиме "активный — пассивный") или просто удалить загрузку на сбойном брандмауэре (в режиме "активный — активный"). Но вы не можете просто использовать подсистемы балансировки нагрузки как "шлюзы по умолчанию", так как они влияют на поток трафика, а TCP-пакеты должны поддерживать отслеживание состояния.
Брандмауэры в двухзонной конфигурации
На рисунке ниже представлены два брандмауэра (FW-1 и FW-2) с внешней подсистемой балансировки нагрузки и внутренним сервером S1.
Это простая архитектура, используемая для входящего трафика. Пакет поступает в подсистему балансировки нагрузки, которая выбирает целевой брандмауэр из своей конфигурации. Затем выбранный брандмауэр отправляет трафик на внутренний сервер или веб-сервер. Если в брандмауэре FW-1 включена поддержка SNAT, сервер S1 будет видеть трафик, который поступает с внутреннего IP-адреса брандмауэра FW-1, и поэтому также будет отправлять брандмауэру FW-1 свой ответ на пакет. В таком сценарии можно быстро выполнить отработку отказа на брандмауэр FW-2. Для исходящего трафика можно добавить еще одну внутреннюю подсистему балансировки нагрузки. Таким образом, при инициировании трафика сервером S1 будет действовать тот же механизм. Трафик поступает во внутреннюю подсистему балансировки нагрузки, которая выбирает брандмауэр, выполняющий преобразование с помощью NAT для внешнего разрешения:
Брандмауэры в трехзонной конфигурации
При добавлении в брандмауэр еще одного интерфейса возникают проблемы. Поэтому преобразование с помощью NAT между внутренними зонами необходимо отключить. В этом случае рассмотрим подсети B и C:
Маршрутизация на уровне 3 между внутренними зонами (подсети B и C) будет выполняться с балансировкой нагрузки без преобразования сетевых адресов. Схема настройки станет более понятной, если рассмотреть потоки трафика с подсистемами балансировки нагрузки в другом представлении. На схеме ниже показано представление, в котором внутренние подсистемы балансировки нагрузки связаны с определенной сетевой картой в брандмауэрах:
При поступлении трафика на уровне 3 (без NAT) сервер S2 будет воспринимать IP-адрес сервера S1 как адрес источника. Поэтому сервер S2 будет отправлять обратный трафик для подсети B (к которой принадлежит IP-адрес S1) во внутреннюю подсистему балансировки нагрузки в подсети C. Так как внутренние подсистемы балансировки нагрузки в подсетях B и C не синхронизируют свои состояния сеансов, в зависимости от алгоритма балансировки нагрузки трафик может попадать на брандмауэр FW-2. По умолчанию брандмауэр FW-2 не имеет каких-либо данных о первоначальном пакете (зеленого цвета) и поэтому прервет подключение.
Некоторые поставщики брандмауэров пытаются реализовать сохранение данных о состоянии подключения между брандмауэрами. Но для поддержания актуальности данных о подключениях им нужно обеспечить практически мгновенную синхронизацию. Уточните у своего поставщика брандмауэра, рекомендуется ли такая конфигурация.
Лучшим способом решения этой проблемы является ее устранение. В приведенном выше примере решением будет удаление подсети C. Это позволяет нам воспользоваться преимуществами виртуальных сетей.
Изоляция узлов в подсети с помощью групп безопасности сети
При наличии двух виртуальных машин в одной подсети можно задействовать группу безопасности сети, которая изолирует трафик между ними. По умолчанию трафик в виртуальной сети может передаваться без ограничений. Добавление правила Запретить все в группе безопасности сети изолирует все виртуальные машины друг от друга.
Виртуальные сети использую одни и те же внутренние (виртуальные) маршрутизаторы
Виртуальные сети и подсети используют одну систему внутреннего маршрутизатора от Azure. Поэтому указывать IP-адрес маршрутизатора для каждой подсети не требуется. Назначение маршрута может быть в любой точке той же виртуальной сети или даже за ее пределами.
В виртуальных сетях вы можете управлять маршрутами в каждой подсети. Такие маршруты также могут указывать на один IP-адрес в другой подсети. На рисунке выше это будет внутренняя подсистема балансировки нагрузки в подсети D, которая распределяет нагрузку между двумя брандмауэрами. Так как сервер S1 инициирует трафик (зеленого цвета), при балансировке нагрузки он будет направлен, например, на брандмауэр FW-1. Брандмауэр FW-1 затем подключается к серверу S2 (по-прежнему зеленого цвета). S2 отправляет ответный трафик на IP-адрес S1 (так как преобразование сетевых адресов отключено). Применяются таблицы маршрутизации, поэтому сервер S2 использует тот же IP-адрес подсистемы балансировки нагрузки, что и шлюз. Внутренняя подсистема балансировки нагрузки сможет сопоставить трафик с трафиком первоначального сеанса и, таким образом, всегда будет направлять его обратно на брандмауэр FW-1. Затем FW-1 отправляет трафик на сервер S1. Благодаря этому обеспечивается синхронность потока трафика.
Для такой настройки брандмауэр должен иметь таблицу маршрутов (на внутреннем уровне), которая указывает подсети B и подсети C на шлюз такой подсети по умолчанию. Этот шлюз подсети — первый логически доступный IP-адрес в диапазоне подсети в этой виртуальной сети.
Влияние на работу служб обратных прокси-серверов
При развертывании служба обратных прокси-серверов обычно может располагаться за брандмауэром. Кроме того, вы можете разместить ее на одной линии с брандмауэром. Это позволит выполнять маршрутизацию трафика через брандмауэр. Преимущество такой настройки заключается в том, что служба обратных прокси-серверов будет видеть исходный IP-адрес подключающегося клиента:
Для такой конфигурации таблицы маршрутов в подсети E должны направлять трафик подсетей B и C через внутреннюю подсистему балансировки нагрузки. Некоторые службы обратных прокси-серверов имеют встроенные брандмауэры, что позволяет полностью убрать брандмауэр из этого сетевого потока. Внутренние брандмауэры направляют трафик от обратного прокси-сервера непосредственно на серверы в подсетях B и C.
В таком случае для обратного прокси-сервера также потребуется SNAT, чтобы избежать передачи обратного трафика через брандмауэры в подсеть A и его блокировки.
VPN/ER
В Azure предоставляются службы VPN и аварийного восстановления с поддержкой BGP и высоким уровнем доступности через шлюзы виртуальной сети Azure. Большинство разработчиков архитекторы используют их для серверных или внутренних (без выхода в Интернет) подключений. При такой настройке таблица маршрутизации также должна включать данные о подсетях, обслуживающих эти подключения. Это не имеет большого значения для подключений подсетей B и C, но важно при проектировании обратного трафика. Общая картина:
В этой архитектуре трафик поступающий на брандмауэр, например, при передаче данных из подсети B в подсеть X, будет направляться во внутреннюю подсистему балансировки нагрузки, которая в свою очередь отправляет его на другой брандмауэр. По внутреннему маршруту в брандмауэре трафик отправляется обратно в шлюз подсети (первый доступный IP-адрес в подсети D). Вам не нужно передавать трафик непосредственно на устройство шлюза, так как другой маршрут в подсети D будет включать маршрут для подсети X, указывающий на шлюз виртуальной сети. Сеть Azure выполняет фактическую маршрутизацию.
Обратный трафик, поступающий из подсети X, будет перенаправляться во внутреннюю подсистему балансировки нагрузки в подсети D. Эта подсеть шлюза также будет иметь специальный маршрут, указывающий подсетям B и C на внутреннюю подсистему балансировки нагрузки. Трафик подсети D не проходит через внутреннюю подсистему балансировки нагрузки. В таком случае действует обычная маршрутизация между виртуальными сетями.
Хотя это не показано на схеме, целесообразно включить для подсетей B, C, D и шлюза маршрут с указанием подсети A на внутреннюю подсистему балансировки нагрузки. Такое размещение позволяет избежать "обычной" маршрутизации виртуальной сети для обхода брандмауэров. Сетевой стек Azure воспринимает такую подсеть A как просто еще одну подсеть в виртуальной сети, хотя вы работаете с ней как с сетью периметра, сетью Интернета и т. д.
Итоги
В целом, способ взаимодействия с брандмауэрами в локальных (физических или на основе виртуальных ЛС) сетях с таким же количеством интерфейсов (виртуальных или физических) отличается от подхода в Azure. При необходимости вы все равно можете (в некоторой степени) использовать подход Azure, но существуют более оптимальные способы уменьшить время простоя при отработке отказа, реализовать работу в режиме "активный — активный" и обеспечить отсутствие ошибок в таблице маршрутизации.
Дополнительные сведения об использовании подсистем балансировки нагрузки в качестве шлюзов для всего трафика можно найти в статье Общие сведения о портах с высоким уровнем доступности.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.
Автор субъекта:
- Roelf Zomerman | Старший архитектор облачных решений
Следующие шаги
Дополнительные сведения о технологиях компонентов:
Связанные ресурсы
Сведения о связанных архитектурах:
- Реализация безопасной гибридной сети
- Гибридное подключение
- Расширение локальной сети с помощью VPN
- Выбор между пирингом виртуальной сети и VPN-шлюзами
- Устранение неполадок гибридного VPN-подключения
- Звездообразная топологии сети в Azure
- Подключение автономные серверы с помощью сетевого адаптера Azure