Настройка инфраструктуры Шлюза приложений

Инфраструктура шлюза приложений Azure включает виртуальную сеть, подсети, группы безопасности сети (NSG) и маршруты, заданные пользователем (UDR).

Виртуальная сеть и выделенная подсеть

Шлюз приложений — это выделенное развертывание в вашей виртуальной сети. Для работы шлюза приложений в виртуальной сети требуется выделенная подсеть. В подсети можно иметь несколько экземпляров определенного развертывания Шлюза приложений. В подсети также можно развернуть другие шлюзы приложений. Но вы не можете развернуть другой ресурс в подсети Шлюз приложений. Вы не можете смешивать SKU шлюзов приложений версий 1 и 2 в одной подсети.

Размер подсети

Шлюз приложений использует один частный IP-адрес для каждого экземпляра, а также другой частный IP-адрес, если сконфигурирован частный фронтальный IP-адрес.

Azure также резервирует пять IP-адресов в каждой подсети для внутреннего использования. Это первые четыре адреса и последние IP-адреса. Например, рассмотрим 15 экземпляров Шлюза приложений без частного фронтального IP-адреса. Для этой подсети требуется не менее 20 IP-адресов. Для внутреннего использования требуется 5 штук, а для экземпляров Шлюза приложений — 15.

Рассмотрим подсеть с 27 экземплярами Шлюз приложений и IP-адресом для частного внешнего IP-адреса. В этом случае вам потребуется 33 IP-адреса. Необходимо 27 экземпляров для экземпляров Шлюза приложений, один для частного фронтенда и 5 для внутреннего использования.

Шлюз приложений (SKU уровня "Стандартный" или "SKU WAF") может поддерживать до 32 экземпляров (32 IP-адреса экземпляра + 1 конфигурация частного IP-адреса + 5 зарезервированных в Azure). Рекомендуется минимальный размер подсети /26.

Шлюз приложений (SKU Standard_v2 или WAF_v2) поддерживает до 125 экземпляров (125 IP-адресов экземпляра + 1 конфигурацию частного внешнего IP-адреса + 5 зарезервированных Azure). Рекомендуется минимальный размер подсети /24.

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

Например, вот как вычислить доступную адресацию для подсети с тремя шлюзами различных размеров:

• Шлюз 1. Максимум 10 экземпляров. Использует частную ip-конфигурацию внешнего интерфейса.
• Шлюз 2: Максимум 2 инстанции. Нет частной конфигурации IP-адреса фронтенда.
• Шлюз 3: Максимум 15 инстанций. Использует частную ip-конфигурацию внешнего интерфейса.
• Размер подсети: /24
  • Размер подсети /24 = 256 IP-адресов — 5 зарезервированных от платформы = 251 доступных адресов
  • 251: шлюз 1 (10) — 1 частная интерфейсная IP-конфигурация = 240
  • 240: шлюз 2 (2) = 238
  • 238: шлюз 3 (15) — 1 частная ip-конфигурация внешнего интерфейса = 222

Подсеть с именем GatewaySubnet зарезервирована для VPN-шлюзов. Ресурсы шлюза приложений версии 1, использующие подсеть GatewaySubnet, необходимо переместить в другую подсеть или перейти на версию 2 SKU до 30 сентября 2023 года, чтобы избежать сбоев управляющей плоскости и несоответствий платформы. Сведения об изменении подсети существующего экземпляра Шлюз приложений см. в разделе часто задаваемые вопросы о Шлюз приложений.

Можно изменить подсеть существующего экземпляра Application Gateway в пределах той же виртуальной сети. Чтобы внести это изменение, используйте Azure PowerShell или Azure CLI. Дополнительные сведения см. в разделе Часто задаваемые вопросы о Шлюзе приложений.

DNS-серверы для разрешения имен

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

Когда экземпляр вашего Шлюза приложений выполняет DNS-запрос, он использует значение с сервера, который отвечает первым.

Разрешение для виртуальной сети

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

Проверьте управление доступом на основе ролей Azure, чтобы убедиться, что пользователи и субъекты-службы, работающие с шлюзами приложений, имеют по крайней мере следующие разрешения в виртуальной сети или подсети:

• Microsoft.Network/virtualNetworks/subnets/join/action
• Microsoft.Network/virtualNetworks/subnets/read

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

Разрешения

В зависимости от того, создаете ли вы новые ресурсы или используете существующие, добавьте соответствующие разрешения из следующего списка:

Дополнительные сведения см. в разделе "Разрешения Azure для сетевых и виртуальных сетей".

Область ролей

В процессе определения пользовательской роли можно указать область назначения ролей на четырех уровнях: группа управления, подписка, группа ресурсов и ресурсы. Чтобы предоставить доступ, необходимо назначить роли пользователям, группам, субъектам-службам или управляемым удостоверениям в определенной области. Эти границы структурированы в системе "родитель-ребёнок", где каждый уровень иерархии делает границу более специфичной. Вы можете назначать роли на любом из этих уровней области, а выбранный уровень определяет, как широко применяется роль. Например, роль, назначенная на уровне подписки, может каскадно уменьшаться до всех ресурсов в этой подписке, а роль, назначенная на уровне группы ресурсов, будет применяться только к ресурсам в этой конкретной группе. Дополнительные сведения об уровне области см. в разделе "Уровни области".

Идентифицируйте затронутых пользователей или учетные записи служб для вашей подписки

Перейдя в Azure Advisor для своей учетной записи, вы можете проверить, есть ли у вашей подписки пользователи или учетные записи сервисов с недостаточными разрешениями. Ниже приведены сведения об этой рекомендации.

Название: Обновление разрешений VNet для пользователей шлюза приложений
Категория: Надежность
Воздействие: Высокое

Использование временного флага управления экспонированием функций Azure (AFEC)

В качестве временного расширения мы ввели контроль управления доступностью компонентов Azure на уровне подписки Azure Feature Exposure Control (AFEC). Вы можете зарегистрироваться в AFEC и использовать его, пока не исправите разрешения для всех пользователей и служебных принципалов. Зарегистрируйтесь для данной функции, выполнив те же действия, что и при регистрации предварительной версии функции для подписки Azure.

Имя: Microsoft.Network/DisableApplicationGatewaySubnetPermissionCheck
Описание: Отключить проверку разрешений на подсеть для шлюза приложений
ProviderNamespace: Microsoft.Network
EnrollmentType: AutoApprove

Диспетчер виртуальных сетей Azure

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

Конфигурация правил администратора безопасности в Диспетчере виртуальная сеть Azure позволяет определять политики безопасности в масштабе и применять их одновременно к нескольким виртуальным сетям.

Группы безопасности сети

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

Обязательные правила безопасности

Чтобы использовать NSG с вашим шлюзом приложений, необходимо создать или сохранить некоторые важные правила безопасности. Вы можете задать приоритет в том же порядке.

Правила для входящего трафика

Трафик клиента: разрешать входящий трафик от ожидаемых клиентов (в качестве исходного IP-адреса или диапазона IP-адресов), а также для назначения в качестве префикса ВСЕГО IP-адреса подсети шлюза приложений и портов входящего доступа. Например, если ваш прослушиватель настроен для портов 80 и 443, необходимо их разрешить. Вы также можете задать для этого правила значение Any.

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

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

• Версия 2: порты 65200-65535
• V1: порты 65503-65534

Проверки Azure Load Balancer: Разрешить входящий трафик из источников с тегом службы AzureLoadBalancer. Это правило создается по умолчанию для групп безопасности сети. Не следует вручную переопределять правило Deny, чтобы обеспечить бесперебойную работу вашего шлюза приложений.

Вы можете заблокировать весь другой входящий трафик с помощью правила "Запретить все ".

Правила для исходящего трафика

Исходящий трафик в интернет: разрешить направленный в интернет трафик для всех адресатов. Это правило создается по умолчанию для групп безопасности сети (NSG). Не следует вручную переопределять правило отказать, чтобы обеспечить бесперебойную работу вашего шлюзового приложения. Правила NSG для исходящего трафика, которые запрещают любое исходящее подключение, не должны создаваться.

Поддерживаемые маршруты, определяемые пользователем

Тонкое управление подсетью шлюза приложений с помощью правил таблицы маршрутов возможно в общедоступной предварительной версии. Дополнительные сведения см. в разделе «Развертывание шлюза частных приложений (предварительная версия)».

С текущими функциональными возможностями существуют некоторые ограничения:

• v1. Для SKU v1 UDR поддерживаются в подсети шлюза приложений, если они не изменяют сквозное общение с запросами и ответами. Например, в подсети Шлюза приложений можно настроить UDR, чтобы он указывал на устройство брандмауэра для проверки пакетов. Однако при этом необходимо убедиться, что пакет после проверки может достичь предполагаемого назначения. Невыполнение этого требования может привести к неправильному выполнению пробы работоспособности или некорректной маршрутизации трафика. Маршруты, изученные или маршруты по умолчанию 0.0.0.0/0, которые распространяются через Azure ExpressRoute или VPN-шлюзы в виртуальной сети, также включены.

• версия 2. Для SKU версии 2 поддерживаются и неподдерживаемые сценарии.

Поддерживаемые сценарии для версии 2

Сценарий 1: Отключение распространения маршрутов протокола BGP в подсеть Шлюза приложений с помощью UDR

Иногда маршрут шлюза по умолчанию (0.0.0.0/0) объявляется через шлюзы ExpressRoute или VPN, связанные с виртуальной сетью Шлюза приложений. Это поведение нарушает трафик управления, который требует непосредственного доступа к интернету. В таких сценариях можно использовать UDR для отключения распространения маршрутов BGP.

Чтобы отключить распространение маршрутов BGP:

1. Создайте ресурс таблицы маршрутов в Azure.
2. Отключите параметр Распространение маршрутов шлюза виртуальной сети.
3. Свяжите таблицу маршрутов с соответствующей подсетью.

Включение UDR для этого сценария не должно привести к нарушению существующих настроек.

Сценарий 2. UDR для перенаправления 0.0.0.0/0 в Интернет

Вы можете создать UDR для отправки трафика 0.0.0.0/0 непосредственно в Интернет.

Сценарий 3: UDR для Службы Azure Kubernetes (AKS) с kubenet

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

Чтобы использовать таблицу маршрутов и обеспечить работу kubenet:

1. Перейдите в группу ресурсов, созданную AKS. Имя группы ресурсов должно начинаться с MC_.

2. В этой группе ресурсов найдите таблицу маршрутизации, созданную с помощью AKS. В таблице маршрутизации должны быть указаны следующие сведения:

   • Префикс адреса должен быть диапазоном IP-адресов тех подов в AKS, которые вы хотите достичь.
   • Тип следующего прыжка должен быть виртуальным устройством.
   • В качестве адреса для следующего прыжка следует указать IP-адрес узла, на котором размещены объекты pod.

3. Свяжите эту таблицу маршрутизации с подсетью Шлюза приложений.

Неподдерживаемые сценарии для версии 2

Сценарий 1. UDR для виртуальных устройств

Для версии 2 не поддерживаются сценарии, где трафик 0.0.0.0/0 должен перенаправляться через виртуальный модуль, центральную или периферийную виртуальную сеть или локальную сеть (принудительное туннелирование).

Дополнительные услуги

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

• Azure ExpressRoute

• Брандмауэр Azure

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

• Виртуальная глобальная сеть Azure

• Управляемая NVA

• VPN-шлюз Azure

Следующие шаги

• Сведения о конфигурации внешнего IP-адреса
• Узнайте о частном развертывании шлюза приложений
• Что такое управление доступом на основе ролей Azure
• Контроль доступа на основе ролей в Azure