Настройка инфраструктуры Шлюза приложений
Инфраструктура Шлюз приложений Azure включает в себя виртуальную сеть, подсети, группы безопасности сети (NSG) и определяемые пользователем маршруты (определяемые пользователем).
Виртуальная сеть и выделенная подсеть
Шлюз приложений — это выделенное развертывание в вашей виртуальной сети. Для работы шлюза приложений в виртуальной сети требуется выделенная подсеть. В подсети можно использовать несколько экземпляров определенного Шлюз приложений развертывания. В ней можно развернуть дополнительные шлюзы приложений. Но вы не можете развернуть другой ресурс в подсети Шлюз приложений. Вы не можете смешивать номера 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
Внимание
Хотя для каждого развертывания SKU Шлюз приложений версии 2 не требуется подсеть /24, настоятельно рекомендуется. Подсеть /24 гарантирует, что Шлюз приложений версии 2 достаточно места для автомасштабирования расширений и обновлений обслуживания.
Убедитесь, что в подсети Шлюза приложений версии 2 достаточно адресного пространства, чтобы разместить количество экземпляров, необходимое для обслуживания максимального ожидаемого трафика. Если указать максимальное число экземпляров, подсеть должна иметь емкость по крайней мере для нескольких адресов. Сведения о планировании емкости по количеству экземпляров см. в разделе "Сведения о количестве экземпляров".
Именованной GatewaySubnet подсети зарезервировано для VPN-шлюзов. Ресурсы Шлюз приложений версии 1 с помощью GatewaySubnet подсети необходимо переместить в другую подсеть или перенести на номер SKU версии 2 до 30 сентября 2023 года, чтобы избежать сбоев плоскости управления и несоответствий платформы. Сведения об изменении подсети существующего экземпляра Шлюз приложений см. в разделе часто задаваемые вопросы о Шлюз приложений.
Совет
IP-адреса выделяются с начала определенного пространства подсети для экземпляров шлюза. Так как экземпляры создаются и удаляются из-за создания шлюзов или событий масштабирования, становится трудно понять, какой следующий доступный адрес находится в подсети. Чтобы определить следующий адрес, используемый для будущего шлюза и иметь непрерывную тему адресации для интерфейсных IP-адресов, рекомендуется назначать внешние IP-адреса из верхней половины определенного подмножества.
Например, если адресное пространство подсети равно 10.5.5.0/24, Рассмотрите возможность настройки частной ip-конфигурации внешнего IP-адреса шлюзов, начиная с версии 10.5.5.254, а затем 10.5.5.253, 10.5.252, 10.5.5.251 и т. д. для будущих шлюзов.
Можно изменить подсеть существующего экземпляра Шлюз приложений в одной виртуальной сети. Чтобы внести это изменение, используйте Azure PowerShell или Azure CLI. Дополнительные сведения см. в разделе Часто задаваемые вопросы о Шлюзе приложений.
DNS-серверы для разрешения имен
Ресурс виртуальной сети поддерживает конфигурацию DNS-сервера , которая позволяет выбирать между предоставленными Azure по умолчанию или пользовательскими DNS-серверами. Экземпляры шлюза приложений также учитывают эту конфигурацию DNS для любого разрешения имен. После изменения этого параметра необходимо перезапустить шлюз приложений (остановить и запустить), чтобы эти изменения вступили в силу на экземпляры.
Когда экземпляр Шлюз приложений выдает DNS-запрос, он использует значение с сервера, который отвечает первым.
Примечание.
Если в виртуальной сети Шлюз приложений используются пользовательские DNS-серверы, DNS-сервер должен иметь возможность разрешать общедоступные интернет-имена. Шлюз приложений требует этой возможности.
Разрешение для виртуальной сети
Ресурс Шлюз приложений развертывается в виртуальной сети, поэтому проверка также выполняются для проверки разрешения на ресурс виртуальной сети. Эта проверка выполняется во время операций создания и управления, а также применяется к управляемым удостоверениям для контроллера входящего трафика Шлюз приложений.
Проверьте управление доступом на основе ролей Azure, чтобы убедиться, что пользователи и субъекты-службы, работающие с шлюзами приложений, имеют по крайней мере следующие разрешения в виртуальной сети или подсети:
- Microsoft.Network/virtualNetworks/subnets/join/action
- Microsoft.Network/virtualNetworks/subnets/read
Вы можете использовать встроенные роли, например сетевые участник, которые уже поддерживают эти разрешения. Если встроенная роль не предоставляет правильного разрешения, можно создать и назначить пользовательскую роль. Дополнительные сведения об управлении разрешениями подсети.
Примечание.
Возможно, потребуется разрешить достаточно времени для обновления кэша Azure Resource Manager после изменения назначения ролей.
Определение затронутых пользователей или субъектов-служб для подписки
Перейдя в Помощник по Azure для своей учетной записи, вы можете проверить, есть ли у вашей подписки пользователи или субъекты-службы с недостаточным разрешением. Ниже приведены сведения об этой рекомендации.
Title: Update VNet permission of Шлюз приложений users
Category: Reliability
Impact: High
Использование временного флага управления экспозицией компонентов Azure (AFEC)
В качестве временного расширения мы представили элемент управления экспозицией компонентов Azure на уровне подписки (AFEC). Вы можете зарегистрировать в AFEC и использовать его, пока не исправите разрешения для всех пользователей и субъектов-служб. Зарегистрируйтесь для функции, выполнив те же действия, что и предварительная регистрация компонентов для подписки Azure.
Имя: Microsoft.Network/DisableApplicationGatewaySubnetPermissionCheck
Description: Disable Шлюз приложений Subnet Permission Check
ProviderNamespace: Microsoft.Network
EnrollmentType: AutoApprove
Примечание.
Мы рекомендуем использовать подготовку AFEC только в качестве промежуточного устранения, пока не назначьте правильное разрешение. Необходимо определить приоритеты для всех применимых пользователей (и субъектов-служб), а затем отменить регистрацию этого флага AFEC, чтобы повторно ввести проверку разрешений на ресурс виртуальной сети. Рекомендуется не зависеть от этого метода AFEC окончательно, так как он будет удален в будущем.
Диспетчер виртуальных сетей Azure
Диспетчер виртуальная сеть Azure — это служба управления, которая позволяет группировать, настраивать, развертывать и управлять виртуальными сетями глобально в разных подписках. С помощью диспетчера виртуальных сетей можно определить сетевые группы, чтобы идентифицировать и логически сегментировать виртуальные сети. После этого можно определить нужные конфигурации подключения и безопасности и применить их ко всем выбранным виртуальным сетям в группах сети одновременно.
Конфигурация правил администратора безопасности в Диспетчере виртуальная сеть Azure позволяет определять политики безопасности в масштабе и применять их одновременно к нескольким виртуальным сетям.
Примечание.
Правила администратора безопасности диспетчера виртуальная сеть Azure применяются только к подсетям Шлюз приложений, содержащим шлюзы приложений с включенной сетевой изоляцией. Подсети с шлюзами приложений, у которых отключена сетевая изоляция , не имеют правил администратора безопасности.
Группы безопасности сети
Группы безопасности сети можно использовать для Шлюз приложений подсети, но помните о некоторых ключевых точках и ограничениях.
Внимание
Эти ограничения NSG смягчаются при использовании частного Шлюз приложений развертывания (предварительная версия).
Обязательные правила безопасности
Чтобы использовать группу безопасности сети с шлюзом приложений, необходимо создать или сохранить некоторые важные правила безопасности. Вы можете задать приоритет в том же порядке.
Правила для входящего трафика
Трафик клиента: разрешать входящий трафик от ожидаемых клиентов (в качестве исходного IP-адреса или диапазона IP-адресов), а также для назначения в качестве префикса ВСЕГО IP-адреса подсети шлюза приложений и портов входящего доступа. Например, если у вас есть прослушиватели, настроенные для портов 80 и 443, необходимо разрешить эти порты. Вы также можете задать для этого правила значение Any.
| Исходный код | Исходные порты | Назначение | Конечные порты | Протокол | Открыть |
|---|---|---|---|---|---|
<as per need> |
Любое | <Subnet IP Prefix> |
<listener ports> |
TCP | Разрешить |
После настройки активных общедоступных и частных прослушивателей (с правилами) с одинаковым номером порта шлюз приложений изменяет назначение всех входящих потоков на интерфейсные IP-адреса шлюза. Это изменение происходит даже для прослушивателей, не использующих порт. При использовании той же конфигурации порта необходимо включить внешний и частный IP-адреса шлюза в назначение правила входящего трафика.
| Исходный код | Исходные порты | Назначение | Конечные порты | Протокол | Открыть |
|---|---|---|---|---|---|
<as per need> |
Любое | <Public and Private frontend IPs> |
<listener ports> |
TCP | Разрешить |
Порты инфраструктуры: разрешать входящие запросы из источника в виде тега службы GatewayManager и любого назначения. Диапазон портов назначения отличается на SKU и необходим для обмена данными о состоянии работоспособности серверной части. Эти порты защищены или заблокированы сертификатами Azure. Внешние сущности не могут инициировать изменения в этих конечных точках без соответствующих сертификатов.
- Версия 2: порты 65200-65535
- V1: порты 65503-65534
| Исходный код | Исходные порты | Назначение | Конечные порты | Протокол | Открыть |
|---|---|---|---|---|---|
| GatewayManager | Любой | Любой | <as per SKU given above> |
TCP | Разрешить |
Пробы Azure Load Balancer. Разрешить входящий трафик из источника в качестве тега службы AzureLoadBalancer . Это правило создается по умолчанию для групп безопасности сети. Не следует переопределять его вручную, чтобы обеспечить гладкие операции шлюза приложений.
| Исходный код | Исходные порты | Назначение | Конечные порты | Протокол | Открыть |
|---|---|---|---|---|---|
| AzureLoadBalancer | Любой | Любой | Любой | Любой | Разрешить |
Вы можете заблокировать весь другой входящий трафик с помощью правила "Запретить все ".
Правила для исходящего трафика
Исходящий трафик в Интернет: разрешить исходящий трафик в Интернет для всех назначений. Это правило создается по умолчанию для групп безопасности сети. Не следует переопределять его вручную, чтобы обеспечить гладкие операции шлюза приложений. Правила NSG для исходящего трафика, которые запрещают создание исходящего подключения.
| Исходный код | Исходные порты | Назначение | Конечные порты | Протокол | Открыть |
|---|---|---|---|---|---|
| Любой | Любой | Интернет | Любой | Любой | Разрешить |
Примечание.
Шлюз приложений, у которых нет Включенная сетевая изоляция не позволяет отправлять трафик между пиринговой виртуальной сетью, если трафик в удаленную виртуальную сеть отключен.
Поддерживаемые маршруты, определяемые пользователем
Точное управление Шлюз приложений подсетью с помощью правил таблицы маршрутов возможно в общедоступной предварительной версии. Дополнительные сведения см. в разделе "Частное Шлюз приложений развертывания (предварительная версия)".
С текущими функциональными возможностями существуют некоторые ограничения:
Внимание
Использование определяемых пользователем пользователей в подсети Шлюз приложений может привести к тому, что состояние работоспособности в серверном представлении работоспособности отображается как неизвестное. Это также может привести к сбою при создании журналов и метрик Шлюза приложений. Не рекомендуется использовать определяемые пользователем ПОЛЬЗОВАТЕЛЬСКИЙ запросы в подсети Шлюз приложений, чтобы можно было просматривать работоспособности серверной части, журналы и метрики.
v1. Для SKU версии 1 определяемые пользователем UDR поддерживаются в подсети Шлюз приложений, если они не изменяют сквозное взаимодействие с запросами и ответами. Например, в подсети Шлюза приложений можно настроить UDR, чтобы он указывал на устройство брандмауэра для проверки пакетов. Однако при этом необходимо убедиться, что пакет после проверки может достичь предполагаемого назначения. Невыполнение этого требования может привести к неправильному выполнению пробы работоспособности или некорректной маршрутизации трафика. Кроме того, включены маршруты, распространяемые Azure ExpressRoute или VPN-шлюзами по умолчанию 0.0.0.0.0/0.
версия 2. Для SKU версии 2 поддерживаются и неподдерживаемые сценарии.
Поддерживаемые сценарии для версии 2
Предупреждение
Неправильная настройка таблицы маршрутов может привести к появлению в Шлюзе приложений версии 2 асимметричной маршрутизации. Убедитесь, что весь трафик плоскости управления и управления отправляется непосредственно в Интернет, а не через виртуальную (модуль). Также могут быть затронуты журналы, метрики и проверка списков отзыва сертификатов.
Сценарий 1. UDR для отключения распространения маршрутов протокола BGP в подсеть Шлюз приложений
Иногда маршрут шлюза по умолчанию (0.0.0.0/0) объявляется через шлюзы ExpressRoute или VPN, связанные с виртуальной сетью Шлюза приложений. Это поведение нарушает трафик плоскости управления, который требует прямого пути к Интернету. В таких сценариях можно использовать UDR для отключения распространения маршрутов BGP.
Отключение распространения маршрутов BGP:
- Создайте ресурс таблицы маршрутов в Azure.
- Отключите параметр Распространение маршрутов шлюза виртуальной сети.
- Свяжите таблицу маршрутов с соответствующей подсетью.
Включение UDR для этого сценария не должно привести к нарушению существующих настроек.
Сценарий 2. UDR для перенаправления 0.0.0.0/0 в Интернет
Вы можете создать UDR для отправки трафика 0.0.0.0/0 непосредственно в Интернет.
Сценарий 3. UDR для Служба Azure Kubernetes (AKS) с kubenet
Если вы используете kubenet с AKS и Шлюз приложений контроллером входящего трафика, вам потребуется таблица маршрутов, позволяющая отправлять трафик в модули pod из Шлюз приложений направляться на правильный узел. Вам не нужно использовать таблицу маршрутов, если вы используете интерфейс сети контейнеров Azure.
Чтобы использовать таблицу маршрутов, чтобы разрешить работу kubenet:
Перейдите в группу ресурсов, созданную AKS. Имя группы ресурсов должно начинаться с
MC_.В этой группе ресурсов найдите таблицу маршрутизации, созданную с помощью AKS. В таблице маршрутизации должны быть указаны следующие сведения:
- Префикс адреса должен входить в диапазон IP-адресов объектов pod в AKS, которые вы хотите охватить.
- Тип следующего прыжка должен быть виртуальным (модуль).
- В качестве адреса для следующего прыжка следует указать IP-адрес узла, на котором размещены объекты pod.
Свяжите эту таблицу маршрутизации с подсетью Шлюза приложений.
Неподдерживаемые сценарии для версии 2
Сценарий 1. UDR для виртуальных (модуль)
Любой сценарий, в котором необходимо перенаправить 0.0.0.0/0 через виртуальную (модуль), виртуальную сеть концентратора или периферийную виртуальную сеть или локальную (принудительное туннелирование) для версии 2 не поддерживается.