Часто задаваемые вопросы о Шлюзе приложений

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

Шлюз приложений поддерживает автоматическое масштабирование, разгрузку TLS и прямой режим связи TLS, брандмауэр веб-приложения (WAF), сопоставление сеансов на основе файлов cookie, маршрутизацию на основе URL-пути, размещение нескольких сайтов и другие функции. Полный список поддерживаемых функций см. в статье Что такое Шлюз приложений Azure?

Шлюз приложений — это подсистема балансировки нагрузки уровня 7. Это означает, что он работает только с веб-трафиком (HTTP, HTTPS, WebSocket и HTTP/2). Он поддерживает такие функции, как завершение TLS-подключений, сопоставление сеансов на основе файлов cookie и циклический перебор для распределения нагрузки трафика. Load Balancer распределяет нагрузку трафика на уровне 4 (TCP или UDP).

Шлюз приложений поддерживает протоколы HTTP, HTTPS, HTTP/2 и WebSocket.

См. раздел Поддержка HTTP/2.

См. сведения о поддерживаемых внутренних ресурсах.

Шлюз приложений версии 1 (цен. категории "Стандартный" и WAF) доступен во всех регионах глобальной платформы Azure. Она также доступна в Microsoft Azure под управлением 21Vianet и Azure для государственных организаций.

Сведения о доступности Шлюз приложений версии 2 (Standard_v2 и WAF_v2) см. в поддерживаемых регионах для Шлюз приложений версии 2.

Шлюз приложений — это специальное развертывание в вашей виртуальной сети.

Перенаправление поддерживается. См. статью Общие сведения о перенаправлении для Шлюза приложений.

См. раздел Порядок обработки прослушивателей.

Если вы используете общедоступный IP-адрес в качестве конечной точки, вы найдете сведения о IP-адресах и DNS в ресурсе общедоступного IP-адреса. Или его можно найти в портал Azure на странице обзора шлюза приложений. Если вы используете внутренние IP-адреса, информацию можно найти на странице обзора. Для номера SKU версии 1 шлюзы, созданные после 1 мая 2023 г., не будут автоматически связаны с общедоступным IP-именем по умолчанию. В качестве номера SKU версии 2 откройте ресурс общедоступного IP-адреса и выберите Конфигурация. Для настройки DNS-имени доступно поле Метка DNS-имени (дополнительно).

Keep-Alive Время ожидания определяет время ожидания шлюза приложений для отправки другого HTTP-запроса на постоянное подключение, прежде чем повторно использовать его или закрыть. Время ожидания простоя TCP определяет, сколько времени tcp-подключение остается открытым, если действия отсутствуют.

Для подключений Keep-Alive HTTP/1.1 время ожидания в номере SKU Шлюз приложений версии 1 и версии 2 составляет 120 секунд. Для частных IP-адресов значение не настраивается с временем простоя TCP в течение 5 минут. Время ожидания простоя TCP для интерфейсного виртуального IP-адреса (VIP) обоих номеров SKU Шлюза приложений (версий 1 и 2) по умолчанию составляет 4 минуты. Значение времени ожидания простоя TCP можно настроить в экземплярах версии 1 и 2 Шлюз приложений в диапазоне от 4 минут до 30 минут. Для экземпляров версии 1 и версии 2 Шлюз приложений необходимо перейти к общедоступному IP-адресу шлюза приложений и изменить время ожидания простоя TCP в области конфигурации общедоступного IP-адреса на портале. Значение тайм-аута простоя общедоступного IP-адреса можно задать с помощью PowerShell, выполнив следующие команды:

$publicIP = Get-AzPublicIpAddress -Name MyPublicIP -ResourceGroupName MyResourceGroup
$publicIP.IdleTimeoutInMinutes = "15"
Set-AzPublicIpAddress -PublicIpAddress $publicIP

Для подключений HTTP/2 к интерфейсным IP-адресу Шлюз приложений SKU версии 2 время ожидания простоя равно 180 секунд и не настраивается.

Чтобы предотвратить конфликт и непредвиденное поведение, убедитесь, что время ожидания простоя TCP совпадает с временем ожидания времени ожидания в режиме поддержания активности.

Да. Шлюз приложений повторно использует существующие TCP-подключения с серверным сервером.

№ Невозможно переименовать ресурс Шлюз приложений. Необходимо создать новый ресурс с нужным именем.

№ После удаления невозможно восстановить ресурс Шлюз приложений или его общедоступный IP-адрес. Необходимо создать новый ресурс.

В Шлюз приложений номер SKU версии 1 виртуальный IP-адрес может измениться, если остановить и запустить шлюз приложений. Однако DNS-имя, связанное со шлюзом приложений, не меняется никогда. Поскольку оно остается неизменным, мы рекомендуем использовать псевдоним CNAME и настроить его для DNS-адреса шлюза приложений. В Шлюз приложений SKU версии 2 IP-адреса являются статическими, поэтому IP-адрес и DNS-имя не изменятся в течение всего времени существования шлюза приложений.

Да. Номер SKU Шлюз приложений версии 2 поддерживает статические общедоступные IP-адреса и статические внутренние IP-адреса. Номер SKU версии 1 поддерживает статические внутренние IP-адреса.

Шлюз приложений поддерживает только один общедоступный IP-адрес для каждого IP-протокола. Если шлюз приложений настроен как DualStack, он может поддерживать два общедоступных IP-адреса, один для IPv4 и один для IPv6.

См. рекомендации по выбору размера подсети Шлюза приложений.

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

Одна подсеть не поддерживает оба номера SKU Шлюза приложений версий 2 и 1.

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

Да. См. раздел Изменения в запросе.

Подготовка новых развертываний номера SKU Шлюза приложений версии 1 может занять до 20 минут. Изменения в размере или числе экземпляров не нарушают работу шлюза приложений, он остается активным во время обновления.

В большинстве развертываний с номером SKU версии 2 подготовка к работе занимает около 6 минут. Однако процесс может занять больше времени в зависимости от типа развертывания. Например, развертывание в нескольких зонах доступности с большим количеством экземпляров может занять более 6 минут.

Обновления, инициированные Шлюз приложений, применяются по одному домену обновления за раз. По мере обновления экземпляров каждого домена обновления остальные экземпляры в других доменах обновления продолжают обслуживать трафик¹. Активные подключения тщательно очищаются от экземпляров, обновляемых до 5 минут, чтобы помочь установить подключение к экземплярам в другом домене обновления до начала обновления. Во время обновления Шлюз приложений временно выполняется при сниженной максимальной емкости, которая определяется числом настроенных экземпляров. Процесс обновления переходит к следующему набору экземпляров, только если текущий набор экземпляров был успешно обновлен.

¹ Рекомендуется настроить минимальное количество экземпляров 2 для развертываний SKU Шлюз приложений версии 1, чтобы обеспечить по крайней мере один экземпляр может обслуживать трафик во время применения обновлений.

поддерживается Шлюз приложенийПрокси-сервер протокола TLS/TCP через его прокси-сервер уровня 4 в предварительной версии.

Прокси-сервер шлюза приложений уровня 7 с протоколами HTTP(S) не поддерживает такие протоколы электронной почты, как SMTP, IMAP и POP3. Однако для некоторых вспомогательных служб электронной почты, таких как Outlook Web Access (OWA), ActiveSync и трафик автообнаружения, использующий протоколы HTTP(S), можно использовать прокси-сервер уровня 7, а их трафик должен передаваться. (Примечание. При использовании SKU WAF могут потребоваться исключения в правилах WAF.

Да. Дополнительные сведения см. в разделе "Миграция Шлюз приложений Azure" и Брандмауэр веб-приложений с версии 1 до версии 2.

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

№ Шлюз приложений версии 2 не поддерживает запросы прокси-сервера с проверкой подлинности NTLM или Kerberos.

Имена заголовков запросов могут содержать буквенно-цифровые символы и дефисы. Имена заголовков запросов, содержащие другие символы, удаляются при отправке запроса в серверный целевой объект. Имена заголовков ответа могут содержать любые буквенно-цифровые символы и определенные символы, как определено в RFC 7230.

Да. Обновление браузера Chromium версии 80 ввело мандат на HTTP-файлы cookie без атрибута SameSite, который будет рассматриваться как SameSite=Lax. Это означает, что браузер не будет отправлять файл cookie сходства Шлюза приложений в контексте решений сторонних разработчиков.

Для поддержки этого сценария Шлюз приложений внедряет другой файл cookie, который вызывается ApplicationGatewayAffinityCORS в дополнение к существующему ApplicationGatewayAffinity файлу cookie. Эти файлы cookie похожи, но ApplicationGatewayAffinityCORS файл cookie имеет два дополнительных атрибута, добавленных в него: SameSite=None и Secure. Эти атрибуты поддерживают закрепленные сеансы даже для междоменных запросов. Дополнительные сведения см. в разделе сходства на основе файлов cookie.

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

Если развернуто два или больше экземпляров, номер SKU Шлюза приложений версии 1 поддерживает сценарии с высоким уровнем доступности. Azure распределяет эти экземпляры по доменам сбоя и обновления, чтобы избежать одновременного сбоя всех экземпляров. Номер SKU версии 1 поддерживает масштабируемость путем добавления нескольких экземпляров одного шлюза для распределения нагрузки.

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

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

Да. Вы можете настроить фильтрацию подключений, чтобы изменить участников во внутреннем пуле без прерывания. Дополнительные сведения см. в разделе "Очистка подключений" Шлюз приложений.

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

№ Экземпляры распределяются через домены обновления и домены сбоя.

Да.

Да.

Да. Шлюз приложений всегда развертывается в подсети виртуальной сети. Эта подсеть может содержать только шлюзы приложений. Дополнительные сведения см. в разделе "Требования к виртуальной сети и подсети".

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

Как и любой сопоставитель DNS, ресурс Шлюз приложений учитывает значение записи DNS серверного сервера . После истечения срока действия TTL шлюз выполняет поиск для обновления этой информации DNS. При этом поиске, если шлюз приложений сталкивается с проблемой получения ответа (или нет записи DNS), шлюз продолжает использовать последнее известное значение DNS для обслуживания трафика. Дополнительные сведения см. в разделе Как работает шлюз приложений.

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

№ Однако вы можете развернуть другие шлюзы приложений в подсети.

Шлюз приложений можно перемещать между подсетями только в одной виртуальной сети. Она поддерживается с версией 1 с общедоступным и частным интерфейсом (динамическим выделением) и версией 2 только с общедоступным интерфейсом. Невозможно переместить шлюз приложений в другую подсеть, если частная ip-конфигурация внешнего интерфейса статически выделена. Шлюз приложений должен находиться в состоянии "Остановлено " для выполнения этого действия. Остановка или запуск версии 1 изменяет общедоступный IP-адрес. Эту операцию можно выполнить только с помощью Azure PowerShell и Azure CLI, выполнив следующие команды:

Azure PowerShell

$VNet = Get-AzVirtualNetwork -Name "<VNetName>" -ResourceGroupName "<ResourceGroup>"
$Subnet = Get-AzVirtualNetworkSubnetConfig -Name "<NewSubnetName>" -VirtualNetwork $VNet
$AppGw = Get-AzApplicationGateway -Name "<ApplicationGatewayName>" -ResourceGroupName "<ResourceGroup>"
Stop-AzApplicationGateway -ApplicationGateway $AppGw
$AppGw = Set-AzApplicationGatewayIPConfiguration -ApplicationGateway $AppGw -Name $AppGw.GatewayIPConfigurations.Name -Subnet $Subnet
#If you have a private frontend IP configuration, uncomment and run the next line:
#$AppGw = Set-AzApplicationGatewayFrontendIPConfig -Name $AppGw.FrontendIPConfigurations.Name[1] -Subnet $Subnet -ApplicationGateway $AppGw
Set-AzApplicationGateway -ApplicationGateway $AppGw

Дополнительные сведения см. в описании Set-AzApplicationGatewayIPConfiguration.

Azure CLI

az network application-gateway stop -g <ResourceGroup> -n <ApplicationGatewayName>
az network application-gateway update -g <ResourceGroup> -n <ApplicationGatewayName> --set gatewayIpConfigurations[0].subnet.id=<subnetID>

См. раздел Группы безопасности сети в подсети Шлюза приложений.

См. раздел Определяемые пользователем маршруты, поддерживаемые в подсети Шлюза приложений.

№ Политики конечных точек службы для учетных записей хранения не поддерживаются в подсети Шлюз приложений и настраивают его, блокируя трафик инфраструктуры Azure.

См. раздел Ограничения Шлюза приложений.

Да. Служба "Шлюз приложений" поддерживает один внутренний и один внешний IP-адрес для каждого шлюза приложений.

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

Да, при условии, что разрешен трафик.

Архитектура микрослужб поддерживается. Для проверки на разных портах необходимо настроить несколько параметров серверной части.

№

См. раздел Порядок правил обработки.

Поле узла указывает имя для отправки пробы при настройке мультисайта на Шлюз приложений. В противном случае используйте 127.0.0.1. Это значение отличается от имени компьютера виртуальной машины. Его формат: <протокол>://<узел>:<порт><путь>.

Да. См. раздел "Ограничить доступ к определенным исходным IP-адресам".

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

Шлюз приложений версии 2 поддерживает интерфейсы IPv4 и IPv6. В настоящее время поддержка IPv6 доступна только для новых шлюзов приложений. Для поддержки IPv6 виртуальная сеть должна быть двойной стеком. Шлюз приложений версии 1 не поддерживает виртуальные сети с двумя стеками.

Шлюз приложений номера SKU версии 11 могут выполняться в утвержденном режиме работы FIPS 140-2, который обычно называется режимом FIPS. Режим FIPS вызывает проверенный криптографический модуль FIPS 140-2, обеспечивающий алгоритмы, совместимые с FIPS для шифрования, хэширования и подписывания при включении. Чтобы убедиться, что режим FIPS включен, FIPSMode параметр необходимо настроить с помощью PowerShell, шаблона Azure Resource Manager или REST API после регистрации подписки, чтобы включить настройку FIPSmode.

Примечание. В рамках соответствия FedRAMP правительство США предписывает системам работать в режиме, утвержденном FIPS после августа 2024 года.

Действия по включению режима FIPS в номере SKU версии 1.

Шаг 1. Зарегистрируйте функцию AllowApplicationGatewayEnableFIPS , чтобы зарегистрировать подписку для конфигурации режима FIPS.

Чтобы зарегистрировать с помощью Azure PowerShell, откройте запрос Cloud Shell и введите следующее:

Register-AzProviderFeature -FeatureName AllowApplicationGatewayEnableFIPS -ProviderNamespace Microsoft.Network

Чтобы зарегистрировать портал Azure, выполните следующие действия.

• Войдите в портал Azure и найдите функции предварительной версии.
• В поле фильтра введите AllowApplicationGatewayEnableFIPS . Выберите Шлюз приложений версии 1 Разрешить режим FIPS и нажмите кнопку "Зарегистрировать".

Шаг 2. Задайте для свойства enableFips значение True с помощью PowerShell, шаблона Azure Resource Manager или REST API.

# Get the application gateway
$appgw = Get-AzApplicationGateway -Name <ApplicationGatewayName> -ResourceGroupName <ResourceGroupName>
# Set the EnableFips property
$appgw.EnableFips = $true
# Update the application gateway
Set-AzApplicationGateway -ApplicationGateway $appgw

Изменение режима FIPS не влияет на общую доступность наборов шифров на шлюзах версии 1. Однако при использовании криптографии с многоточием кривой для шифров с отключенным режимом FIPS можно использовать кривую25519, NistP256 и NistP384, тогда как в режиме FIPS разрешены только NistP256 и NistP384, а кривая25519 отключена. Так как кривая25519 становится недоступной в режиме FIPS, убедитесь, что клиенты поддерживают NistP256 или NistP384 для безопасного взаимодействия перед включением FIPS.

Шлюз приложений версии 2 в настоящее время поддерживает конфигурацию внешнего интерфейса частного IP-адреса (без общедоступного IP-адреса) через общедоступную предварительную версию. Дополнительные сведения см. в разделе "Частное Шлюз приложений развертывания (предварительная версия)".

Для текущей общей поддержки доступности Шлюз приложений версии 2 поддерживает следующие сочетания:

• Частный IP-адрес и общедоступный IP-адрес
• только общедоступный IP-адрес.

Чтобы ограничить трафик только частными IP-адресами с текущими функциями, выполните следующий процесс:

1. Создайте шлюз приложений с общедоступным и частным ИНТЕРФЕЙСНЫМ IP-адресом.

2. Не создавайте прослушиватели для общедоступного интерфейсного IP-адреса. Шлюз приложений не будет прослушивать трафик на общедоступный IP-адрес, если для него не создаются прослушиватели.

3. Создайте и подключите группу безопасности сети для подсети Шлюз приложений со следующей конфигурацией в порядке приоритета:

   1. Разрешить трафик из источника в качестве тега службы GatewayManager, destination as Any, и целевой порт как 65200-65535. Такой диапазон портов требуется для обмена данными в рамках инфраструктуры Azure. Эти порты защищены (заблокированы) службой проверки подлинности сертификата. Внешние сущности, включая администраторов пользователей шлюза, не могут инициировать изменения в этих конечных точках без соответствующих сертификатов.

   2. Разрешить трафик из источника в качестве тега службы AzureLoadBalancer и целевого порта как Any.

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

   4. Сохраните правила по умолчанию, такие как AllowVNetInBound , чтобы доступ к частному IP-адресу не был заблокирован.

   5. Исходящее подключение к Интернету не может быть заблокировано. В противном случае возникают проблемы с ведением журнала и метрик.

Пример конфигурации NSG для доступа только для частных IP-адресов:

Azure PowerShell или Azure CLI можно использовать для остановки и запуска Шлюз приложений. При остановке и запуске Шлюз приложений выставление счетов также останавливается и запускается. Любая операция PUT, выполненная на остановленном шлюзе приложений (например, добавление тега, пробы работоспособности или прослушивателя) активирует запуск. Рекомендуется остановить шлюз приложений после обновления конфигурации.

# Stop an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Stop-AzApplicationGateway -ApplicationGateway $appGateway       

# Start an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Start-AzApplicationGateway -ApplicationGateway $appGateway           

# Stop an existing Azure Application Gateway instance

az network application-gateway stop -g MyResourceGroup -n MyAppGateway

# Start an existing Azure Application Gateway instance

az network application-gateway start -g MyResourceGroup -n MyAppGateway

Шлюз приложений поддерживает самозаверяющие сертификаты, сертификаты центров сертификации (ЦС), сертификаты с расширенной проверкой (РП), сертификаты для нескольких доменов (SAN) и шаблоны сертификатов.

Шлюз приложений поддерживает следующие наборы шифров:

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

Дополнительные сведения о настройке параметров TLS см. в статье Настройка версий политики TLS и комплектов шифров на Шлюзе приложений.

Да. Шлюз приложений поддерживает разгрузку TLS и сквозную tls, которая перешифровывает трафик в серверную часть.

Да. Вы можете настроить Шлюз приложений, чтобы запретить версии TLS 1.0, TLS 1.1 и TLS 1.2. По умолчанию протоколы SSL версий 2.0 и 3.0 уже отключены, и их настройки нельзя изменить.

Да. В Шлюзе приложений можно настроить комплекты шифров. Чтобы определить пользовательскую политику, включите по крайней мере один из следующих наборов шифров:

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256

Шлюз приложений использует SHA256 для управления серверной частью.

Шлюз приложений поддерживает до 100 сертификатов TLS/SSL.

Да. Шлюз приложений поддерживает сертификаты с расширениями OCSP и ассоциацию OCSP для сертификатов сервера.

Шлюз приложений поддерживает до 100 сертификатов проверки подлинности.

Да, номер SKU Шлюза приложений версии 2 поддерживает Key Vault. Дополнительные сведения см. в статье о завершении TLS-подключений с использованием сертификатов из Key Vault.

Для маршрутизации в нескольких доменах (на основе узла) можно создать многосайтовые прослушиватели, настроить прослушиватели, использующие протокол HTTPS, и связать прослушиватели с правилами маршрутизации. Дополнительные сведения см. в статье Размещение нескольких сайтов с помощью Шлюза приложений.

№ Используйте только буквенно-цифровые символы в пароле PFX-файла.

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

• Ошибка 1649951
• Ошибка 1650910

В соответствии с требованиями к соответствию требованиям отрасли поставщики ЦС начали отзывать несоответствующие ЦС и выдавать соответствующие ЦС, что требует от клиентов повторной выдачи сертификатов. Корпорация Майкрософт тесно сотрудничает с этими поставщиками, чтобы свести к минимуму потенциальное влияние на службы Azure. Однако самозадаемые сертификаты или сертификаты, используемые в сценариях с собственным сертификатом (BYOC), по-прежнему подвергаются риску неожиданного отзыва.

Чтобы проверить, были ли отозваны сертификаты, используемые приложением, см . объявление DigiCert и средство отслеживания отзыва сертификатов. Если ваши сертификаты были отозваны или будут отозваны, необходимо запросить новые сертификаты от поставщика ЦС, используемого в приложениях. Чтобы избежать прерывания доступности приложения из-за неожиданного отзыва сертификатов или обновления сертификата, который был отменен, см . отзыв несоответствующих центров сертификации, потенциально влияющих на службы Azure клиента.

Сведения, относящиеся к Шлюз приложений:

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

• Недопустимый сертификат или сертификат отменен
• Время ожидания подключения истекло
• HTTP 502

Чтобы избежать прерывания работы приложения из-за этой проблемы или повторной отправки отзыва ЦС, необходимо выполнить следующие действия:

1. Обратитесь к поставщику сертификатов по вопросам повторного получения сертификатов.
2. После повторного создания обновите сертификаты на Шлюз приложений/WAF с полной цепочкой доверия (конечный, промежуточный и корневой сертификат). В зависимости от того, где вы используете сертификат, в прослушивателе или параметрах HTTP шлюза приложений выполните действия, описанные здесь, чтобы обновить сертификаты. Дополнительные сведения см. по ссылкам документации.
3. Обновите серверы внутренних приложений, чтобы использовать перезаписанный сертификат. В зависимости от используемого серверного сервера шаги обновления сертификата могут отличаться. Проверьте документацию от поставщика.

Чтобы обновить сертификат для прослушивателя, выполните следующие действия.

1. В портал Azure откройте ресурс Шлюз приложений.
2. Откройте параметры прослушивателя, связанные с сертификатом.
3. Выберите "Обновить или изменить выбранный сертификат".
4. Отправьте новый PFX-сертификат с паролем и нажмите кнопку "Сохранить".
5. Откройте веб-сайт и проверьте, работает ли сайт должным образом. Дополнительные сведения см. в разделе "Продление Шлюз приложений сертификатов".

Если вы ссылаетесь на сертификаты из Key Vault в прослушивателе Шлюз приложений, рекомендуется выполнить следующие действия для быстрого изменения:

1. В портал Azure перейдите к параметрам Key Vault, связанным с шлюзом приложений.
2. Добавьте или импортируйте перезаписанный сертификат в хранилище. Дополнительные сведения см. в кратком руководстве по созданию хранилища ключей с помощью портал Azure.
3. После импорта сертификата перейдите к параметрам прослушивателя Шлюз приложений и в разделе "Выбор сертификата из Key Vault" выберите раскрывающийся список "Сертификат" и выберите недавно добавленный сертификат.
4. Выберите Сохранить. Дополнительные сведения о завершении TLS на Шлюз приложений с сертификатами Key Vault см. в разделе "Завершение TLS с помощью сертификатов Key Vault".

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

Если вы используете номер SKU версии 1 службы Шлюз приложений/WAF, необходимо отправить новый сертификат в качестве внутреннего сертификата проверки подлинности.

1. В портал Azure откройте ресурс Шлюз приложений.
2. Откройте параметры HTTP, связанные с сертификатом.
3. Выберите " Добавить сертификат", отправьте повторно отправленный сертификат и нажмите кнопку "Сохранить".
4. Старый сертификат можно удалить позже, нажав кнопку "Параметры ... " рядом со старым сертификатом. Нажмите кнопку "Удалить", а затем нажмите кнопку "Сохранить". Дополнительные сведения см. в разделе "Настройка сквозного TLS" с помощью Шлюз приложений на портале.

Если вы используете SKU версии 2 службы Шлюз приложений/WAF, вам не нужно отправлять новый сертификат в параметрах HTTP, так как номер SKU версии 2 использует "доверенные корневые сертификаты", и никаких действий не требуется предпринять здесь.

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

Хотя трафик HTTP(S) можно обслуживать через протоколы прокси-сервера L4, мы не рекомендуем это сделать. Решение прокси-сервера L7 Шлюз приложений обеспечивает более широкий контроль и безопасность протоколов HTTP(S) с помощью расширенных функций, таких как перезаписи, сходство сеансов, перенаправление, WebSockets, WAF и многое другое.

Свойства ресурсов для функций уровня 4 отличаются от свойств уровня 7. Соответственно, при использовании REST API или CLI необходимо использовать следующие свойства.

• REST API
• CLI

№ Свойства уровня 4 и уровня 7 не могут быть перекрестными. Поэтому правило маршрутизации позволяет связать прослушиватель уровня 4 типа только с параметром серверной части уровня 4 типа.

Вы не можете использовать то же имя для L7 (httpListeners) и L4 (прослушиватели). Это относится к другим свойствам L4, таким как backendSettingsCollection и routingRules.

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

Он не использует Keepalive для внутренних подключений. Для каждого входящего запроса на подключение внешнего прослушивателя Шлюз приложений инициирует новое внутреннее подключение для выполнения этого запроса.

Сервер серверного сервера видит IP-адрес шлюза приложений. В настоящее время мы не поддерживаем "Сохранение IP-адресов клиента", с помощью которого серверное приложение может быть известно о IP-адресе исходного клиента.

Одна и та же конфигурация политики TLS/SSL применима для уровня 7 (HTTPS), а также уровня 4 (TLS). Теперь для прослушивателей TLS можно использовать профиль SSL (для политики TLS для конкретного прослушивателя и взаимной проверки подлинности). Однако в настоящее время профиль SSL может быть связан только с прослушивателем TLS через CLI, PowerShell или REST API.

№ Маршрутизация клиента на тот же сервер серверной части в данный момент не поддерживается. Подключения будут распределены по циклически перебору между серверами в серверном пуле.

Да, функция автомасштабирования будет работать для пиков и сокращений трафика для протокола TLS или TCP.

Возможности Брандмауэр веб-приложений (WAF) не будут работать для использования уровня 4.

№ Поддержка UDP недоступна в настоящее время.

Тот же список разрешенных диапазонов портов и исключений применяется для прокси уровня 4.

Использование общего порта для прослушивателей TLS/TCP в настоящее время не поддерживается.

Kubernetes позволяет создавать deployment и service ресурсы для предоставления группы модулей pod внутри кластера. Для предоставления той же службы внешним Ingress образом определяется ресурс, который обеспечивает балансировку нагрузки, завершение TLS и виртуальное размещение на основе имен. Для удовлетворения этого Ingress ресурса требуется контроллер входящего трафика, который прослушивает любые изменения Ingress ресурсов и настраивает политики подсистемы балансировки нагрузки.

Контроллер Шлюз приложений входящего трафика (AGIC) позволяет использовать Шлюз приложений в качестве входящего трафика для Служба Azure Kubernetes, также известного как кластер AKS.

Прямая конфигурация Шлюз приложений не поддерживается.

Если необходимо изменить параметры Шлюз приложений, внесите изменения с помощью предоставленной конфигурации на контроллере входящего трафика или других объектов Kubernetes, например с помощью поддерживаемых заметок. После того как Шлюз приложений связан с Шлюз приложений контроллером входящего трафика (AGIC), почти все конфигурации этого шлюза будут синхронизированы и контролируются контроллером входящего трафика. Если вы пытаетесь напрямую настроить Шлюз приложений императивно или через инфраструктуру как код, эти изменения в конечном итоге будут перезаписаны контроллером входящего трафика.

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

AGIC пытается автоматически связать ресурс таблицы маршрутов с подсетью Шлюз приложений, но может не сделать это из-за отсутствия разрешений из AGIC. Если AGIC не удается связать таблицу маршрутов с подсетью Шлюз приложений, в журналах AGIC появится ошибка. В этом случае необходимо вручную связать таблицу маршрутов, созданную кластером AKS, с подсетью Шлюз приложений. Дополнительные сведения см. в разделе Поддерживаемые определяемые пользователем маршруты.

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

Различия между AGIC, развернутыми через Helm и развернутыми в качестве надстройки AKS, см. в разделе "Разница между развертыванием Helm и надстройкой AKS".

Различия между AGIC, развернутыми через Helm и развернутыми в качестве надстройки AKS, см. в разделе "Разница между развертыванием Helm и надстройкой AKS", особенно в таблицах, которые документируют, какие сценарии поддерживаются AGIC, развернутые через Helm, а не надстройка AKS. Как правило, развертывание через Helm позволяет протестировать бета-функции и выпуск кандидатов до официального выпуска.

№ Надстройка AGIC — это управляемая служба, которая означает, что корпорация Майкрософт автоматически обновляет надстройку до последней стабильной версии.

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

Нет, взаимная проверка подлинности в настоящее время выполняется только между интерфейсным клиентом и шлюзом приложений. В настоящее время взаимная проверка подлинности серверной части не поддерживается.

Шлюз приложений предоставляет три журнала.

• ApplicationGatewayAccessLog: журнал доступа содержит каждый запрос, отправленный интерфейсу шлюза приложений. Данные включают в себя IP-адрес вызывающего абонента, запрошенный URL-адрес, задержку ответа, код возврата и байты в и вне. Он содержит одну запись для шлюза приложений.
• ApplicationGatewayPerformanceLog: журнал производительности записывает сведения о производительности для каждого шлюза приложений. Здесь указываются сведения о пропускной способности в байтах, общем числе обслуженных запросов, количестве неудачных запросов, а также числе работоспособных и неработоспособных внутренних экземпляров.
• ApplicationGatewayFirewallLog. Для шлюзов приложений, настроенных с помощью WAF, журнал брандмауэра содержит запросы, которые регистрируются в режиме обнаружения или в режиме предотвращения.

Данные для всех журналов собираются каждые 60 секунд. Дополнительные сведения см. в разделе о работоспособности внутренних служб, диагностика журналах и метрик для Шлюз приложений.

Проверьте работоспособность с помощью командлета PowerShell Get-AzApplicationGatewayBackendHealth или портала. Дополнительные сведения см. в разделе Журналы диагностики.

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

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

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

Просматривать и анализировать журналы доступа можно несколькими способами. Используйте журналы Azure Monitor, Excel, Power BI и т. д.

Можно также использовать шаблон Resource Manager, который устанавливает и запускает популярный анализатор журналов GoAccess для журналов доступа Шлюза приложений. GoAccess предоставляет ценную статистику трафика HTTP, такую как уникальные посетители, запрошенные файлы, узлы, операционные системы, браузеры, коды состояния HTTP и многое другое. Дополнительные сведения см. на GitHub в файле сведений в папке шаблона Resource Manager.

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

Из-за текущих ограничений платформы, если у вас есть группа безопасности сети в подсети Шлюз приложений версии 2 (Standard_v2, WAF_v2) и если в ней включены журналы потоков NSG, вы увидите недетерминированное поведение. Этот сценарий в настоящее время не поддерживается.

Шлюз приложений не перемещает или не хранит данные клиента из региона, в котором он развернут.

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

• Дополнительные сведения о Шлюз приложений см. в статье "Что такое Шлюз приложений Azure".
• Сведения о завершении TLS и сквозном tls с помощью Шлюз приложений см. в статье "Включение сквозного TLS" на Шлюз приложений Azure.