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

Примечание.

Мы рекомендуем использовать модуль Az PowerShell Azure для взаимодействия с Azure. Сведения о начале работы см. в разделе Install Azure PowerShell. Сведения о миграции в модуль Az PowerShell см. в статье Migrate Azure PowerShell из AzureRM в Az.

Следующие распространенные вопросы задаются о Azure Application Gateway.

Общие

Что такое Шлюз приложений?

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

Какие функции поддерживает Шлюз приложений?

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

Как отличаются шлюз приложений и Azure Load Balancer?

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

Какие протоколы поддерживает Шлюз приложений?

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

Как Шлюз приложений поддерживает протокол HTTP/2?

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

Какие ресурсы поддерживаются в составе серверного пула?

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

В каких регионах доступен Шлюз приложений?

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

Для информации о доступности Шлюза приложений v2 (Standard_v2 и WAF_v2) см. Supported regions for Application Gateway v2.

Это развертывание выделено конкретно для моей подписки или оно общее для всех клиентов?

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

Поддерживает ли Шлюз приложений перенаправление с HTTP на HTTPS?

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

В каком порядке обрабатываются прослушиватели?

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

Где я могу найти IP-адрес и DNS-имя Шлюза приложений?

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

Каковы параметры времени ожидания Keep-Alive и времени ожидания простоя TCP?

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

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

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

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

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

Использует ли шлюз приложений существующее TCP-соединение, установленное с сервером?

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

Можно ли переименовать ресурс Шлюза приложений?

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

Можно ли восстановить ресурс Шлюз приложений и его общедоступный IP-адрес, если он был удален?

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

Меняются ли IP-адрес и DNS-имя в течение времени существования шлюза приложений?

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

Поддерживает ли Шлюз приложений статические IP-адреса?

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

Поддерживает ли Шлюз приложений несколько общедоступных IP-адресов в шлюзе?

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

Каким должен быть размер подсети Шлюза приложений?

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

Можно ли развернуть более одного ресурса шлюза приложений в одной подсети?

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

Одна подсеть не поддерживает версии SKU Шлюза приложений v2 и v1.

Поддерживает ли Шлюз приложений версии 2 определяемые пользователем маршруты?

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

Поддерживает ли Шлюз приложений заголовки X-Forwarded-For?

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

Сколько времени занимает развертывание экземпляра Шлюз приложений? Работает ли шлюз приложений во время обновления?

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

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

Можно ли использовать Exchange Server в качестве серверной части с шлюзом приложений?

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

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

Имеются ли рекомендации по переходу с номера SKU версии 1 на номер SKU версии 2?

Да. Более подробную информацию можно найти в Migrate Azure Application Gateway и Web Application Firewall с версии 1 на версию 2.

Поддерживается ли версия 1 SKU для Шлюза приложений?

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

Поддерживает ли этот шлюз приложений версии 2 передачу запросов с аутентификацией NTLM или Kerberos?

Да. Шлюз приложений версии 2 теперь поддерживает прокси-запросы с проверкой подлинности NTLM или Kerberos. Дополнительные сведения см. в разделе "Выделенное внутреннее подключение".

Почему некоторые значения заголовков отсутствуют, когда запросы пересылаются в мое приложение?

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

Поддерживает ли файл cookie привязки Шлюза приложений атрибут SameSite?

Да. Обновление браузера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 Traffic Manager для распределения трафика между несколькими шлюзами приложений в разных центрах обработки данных.

Поддерживает ли Шлюз приложений фильтрацию подключений?

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

Поддерживает ли Шлюз приложений автомасштабирование?

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

Вызывает ли простой ручное или автоматическое увеличение или уменьшение масштаба?

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

Можно ли изменить SKU с "Стандартного" на WAF без прерываний?

Да.

Можно ли изменить размер экземпляра со среднего на большой без прерывания?

Да.

Maintenance

Как шлюз приложений обрабатывает плановое обслуживание?

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

Azure Application Gateway также поддерживает MaxSurge, возможность, которая позволяет подготавливать новые экземпляры во время последовательного обновления, не отключая существующие. Он позволяет клиентам переходить к более новым версиям шлюза без снижения емкости. MaxSurge автоматически включен в шлюзе приложений и не требует настройки.

Заметка: Для подготовки временных экземпляров, используемых MaxSurge, требуется дополнительное пространство IP-адресов. Если во время обновления недостаточно IP-пространства, Application Gateway вернётся к традиционному методу обновления, что может привести к снижению максимальной пропускной способности в зависимости от количества экземпляров.

Настройка

Всегда ли Шлюз приложений развертывается в виртуальной сети?

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

Может ли шлюз приложения взаимодействовать с экземплярами за пределами своей виртуальной сети или своей подписки?

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

Как происходит обновление IP-адреса бэкенд-сервера на основе полного доменного имени?

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

Почему после изменения DNS-серверов для виртуальной сети возникают ошибки 502 или неработоспособные серверные серверы?

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

Поддерживает ли шлюз приложений короткие имена или доменные имена с одной меткой?

Да. Шлюз приложений может разрешать короткие имена (например server1 , или backend) в внутренних пулах, если DNS-сервер может разрешить их. Это работает в любой настройке сети, включая локальные, Azure виртуальные сети или гибридные среды.

Чтобы работало краткое разрешение имен:

• DNS-сервер виртуальной сети должен иметь возможность преобразовать короткое имя в IP-адрес.
• Короткие имена работают так же, как полные доменные имена (FQDN) — шлюз запрашивает у DNS-сервера IP-адрес и использует его.

Примечание. Если вы используете DNS по умолчанию Azure (168.63.129.16), он может разрешать только короткие имена ресурсов в одной виртуальной сети. Чтобы разрешить локальные короткие имена, настройте пользовательский 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-адрес для каждого шлюза приложений.

Поддерживает ли Шлюз приложений пиринг между виртуальными сетями?

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

Можно ли взаимодействовать с локальными серверами при подключении к Azure ExpressRoute или VPN-туннелям?

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

Может ли один серверный пул обслуживать несколько приложений, используя разные порты?

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

Поддерживают ли пользовательские зонды подстановочные знаки или регулярные выражения в данных ответа?

№

Как обрабатываются правила маршрутизации в Шлюзе приложений?

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

Что означает поле **Host** для пользовательских проб?

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

Можно ли разрешить Шлюзу приложений доступ только к некоторым исходным IP-адресам?

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

Можно ли использовать один и тот же порт для общедоступных и частных прослушивателей?

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

Поддерживает ли Шлюз приложений протокол IPv6?

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

Поддерживает ли Шлюз приложений FIPS?

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

Этапы включения режима FIPS в SKU V2: см. раздел Включите режим FIPS для Azure Application Gateway SKU V2.

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

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

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

Register-AzProviderFeature -FeatureName AllowApplicationGatewayEnableFIPS -ProviderNamespace Microsoft.Network

Чтобы зарегистрировать с помощью портала Azure:

• Войдите на портал Azure и найдите функции Preview.
• В поле фильтра введите AllowApplicationGatewayEnableFIPS . Выберите Application Gateway V1 (разрешение режима FIPS), а затем выберите Зарегистрировать.

Step 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 можно использовать curve25519, NistP256 и NistP384, тогда как при включенном режиме FIPS разрешены только NistP256 и NistP384, а curve25519 отключена. Так как кривая25519 становится недоступной в режиме FIPS, убедитесь, что клиенты поддерживают NistP256 или NistP384 для безопасного взаимодействия перед включением FIPS.

Как использовать Application Gateway v2 только с частным фронтенд IP-адресом?

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

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

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

Как остановить и запустить Шлюз приложений?

Для остановки и запуска шлюза приложений можно использовать Azure PowerShell или Azure CLI. При остановке и запуске Шлюза приложений (Application Gateway) выставление счетов также останавливается и снова запускается. Любая операция 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

Конфигурация: TLS

Какие сертификаты поддерживает Шлюз приложений?

Шлюз приложений поддерживает самозаверяющие сертификаты, сертификаты центров сертификации (ЦС), сертификаты с расширенной проверкой (РП), сертификаты для нескольких доменов (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 (Протокол шифрования с аутентификацией на основе ДЕ с использованием DSS и AES в режиме 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 для управления версиями протокола 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 для управления серверной частью.

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

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

Поддерживает ли шлюз приложений OCSP и скрепление OCSP?

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

Сколько сертификатов проверки подлинности поддерживает Шлюз приложений для повторного шифрования на внутреннем сервере?

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

Нативно интегрируется ли шлюз приложений с Azure Key Vault?

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

Почему не удается выбрать хранилище ключей Azure из другой подписки на портале Azure при настройке сертификата прослушивателя TLS в шлюзе приложений?

В настоящее время портал Azure позволяет выбирать хранилища ключей только из той же подписки, что и шлюз приложений. Это известное ограничение портала. Однако Шлюз приложений поддерживает использование хранилища ключей из другой подписки (в пределах одного клиента Microsoft Entra ID), настроив сертификат с помощью Azure CLI или PowerShell с помощью идентификатора секрета хранилища ключей, если управляемое удостоверение шлюза приложений имеет необходимые разрешения для хранилища ключей.

Как настроить прослушиватели HTTPS для сайтов .com и .NET?

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

Можно ли использовать специальные символы в пароле PFX-файла?

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

Мой сертификат EV выдан компанией DigiCert, и мой промежуточный сертификат был отозван. Как возобновить сертификат в Шлюзе приложений?

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

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

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

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

Для получения информации, касающейся Application Gateway:

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

• Недействительный сертификат или отозванный сертификат
• Время ожидания соединения истекло
• HTTP 502

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

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

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

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

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

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

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

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

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

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

Конфигурация — прокси-сервер TLS/TCP

Используют ли Шлюз приложений уровня 7 и 4 одни и те же внешние IP-адреса?

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

Можно ли использовать прокси-сервер TCP или TLS для трафика HTTP(S)?

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

Каковы имена свойств для прокси-сервера уровня 4?

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

Свойство	Цель
слушатель	Для прослушивателей на основе TLS или TCP
Правило маршрутизации	Связывание прослушивателя уровня 4 с параметром серверной части уровня 4
коллекция настроек бэкенда	Параметры серверной части с использованием TLS или TCP

• REST API
• CLI

Примечание.

Для параметров протокола HTTP или HTTPS нельзя использовать какие-либо свойства уровня 4.

Можно ли сопоставить прослушиватель протокола TCP/TLS с параметром серверной части протокола HTTP(S)?

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

Могут ли свойства L7 и L4 иметь одинаковые имена?

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

Можно ли добавить частную конечную точку в серверный пул при использовании четвёртого уровня (TCP или TLS протоколы)?

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

Использует ли Шлюз приложений соединение Keepalive для серверов бэкэнда?

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

Какой IP-адрес видит сервер при установлении подключения с Шлюзом приложений?

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

Как задать политику TLS для прослушивателей TLS?

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

Поддерживает ли Шлюз приложений сессионную привязку для маршрутизации на уровне 4?

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

Работает ли функция автомасштабирования с прокси-сервером уровня 4?

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

Поддерживается ли Web Application Firewall (WAF) для трафика уровня 4?

Возможности Web Application Firewall (WAF) не будут работать для использования уровня 4.

Поддерживает ли прокси-сервер четвёртого уровня в Шлюзе приложений протокол UDP?

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

Какие порты поддерживаются для прослушивателей TLS/TCP?

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

Как использовать один и тот же номер порта для прослушивателей общедоступных и частных прокси-серверов TLS/TCP?

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

Конфигурация - ingress-контроллер для AKS

Что такое контроллер входящего трафика?

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

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

Можно ли настроить Шлюз приложений напрямую вместо использования контроллера входящего трафика?

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

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

Может ли один экземпляр контроллера входящего трафика управлять несколькими шлюзами приложений?

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

Почему мой кластер AKS с kubenet не работает с AGIC?

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

Можно ли подключить кластер AKS и шлюз приложений в отдельных виртуальных сетях?

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

Какие функции не поддерживаются в надстройке AGIC?

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

Когда следует использовать надстройку, а когда развертывание с помощью Helm?

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

Можно ли контролировать, какая версия AGIC развертывается с помощью надстройки?

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

Можно ли обновить кластер, работающий под управлением Kubenet или Azure CNI, до Azure CNI в режиме Overlay с установленным AGIC?

Да, обновление кластера AKS с Kubenet или CNI на CNI Overlay автоматически обнаруживается Ingress-контроллером Application Gateway. Рекомендуется запланировать обновление во время периода обслуживания, так как может произойти нарушение трафика. Контроллер может занять несколько минут по завершении обновления кластера для обнаружения и настройки поддержки CNI Overlay.

Конфигурация: взаимная проверка подлинности

Что такое взаимная проверка подлинности?

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

Доступна ли взаимная проверка подлинности между Шлюзом приложений и его внутренними пулами?

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

Диагностика и ведение журнала

Какие типы журналов предоставляет Шлюз приложений?

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

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

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

Как узнать, работоспособны ли участники серверного пула?

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

Что такое политика хранения журналов диагностики?

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

Как получить журналы аудита для Шлюза приложений?

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

Можно ли настроить оповещения для Шлюза приложений?

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

Как анализировать статистику трафика для Шлюза приложений?

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

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

Что может быть причиной возврата неизвестного состояния работоспособности внутреннего сервера?

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

Поддерживаются ли журналы потоков в ГБС, связанных с подсетью Шлюза приложений версии 2?

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

Где Шлюз приложений хранит данные клиента?

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

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

• Дополнительные сведения о шлюзе приложений см. в статье What Azure Application Gateway.
• Сведения о завершении TLS и сквозном TLS с помощью шлюза приложений см. статью Enable end-to-end TLS на Azure Application Gateway.

Примечание.

Мы рекомендуем использовать модуль Az PowerShell Azure для взаимодействия с Azure. Сведения о начале работы см. в разделе Install Azure PowerShell. Сведения о миграции в модуль Az PowerShell см. в статье Migrate Azure PowerShell из AzureRM в Az.

Следующие распространенные вопросы задаются о Azure Application Gateway.

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

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

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

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

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

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

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

Для информации о доступности Шлюза приложений v2 (Standard_v2 и WAF_v2) см. Supported regions for Application Gateway v2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Одна подсеть не поддерживает версии SKU Шлюза приложений v2 и v1.

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

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

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

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

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

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

Да. Более подробную информацию можно найти в Migrate Azure Application Gateway и Web Application Firewall с версии 1 на версию 2.

Да. SKU Application Gateway версии v1 продолжает поддерживаться. Настоятельно рекомендуем перейти на версию 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 Traffic Manager для распределения трафика между несколькими шлюзами приложений в разных центрах обработки данных.

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

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

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

Да.

Да.

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

Azure Application Gateway также поддерживает MaxSurge, возможность, которая позволяет подготавливать новые экземпляры во время последовательного обновления, не отключая существующие. Он позволяет клиентам переходить к более новым версиям шлюза без снижения емкости. MaxSurge автоматически включен в шлюзе приложений и не требует настройки.

Заметка: Для подготовки временных экземпляров, используемых MaxSurge, требуется дополнительное пространство IP-адресов. Если во время обновления недостаточно IP-пространства, Application Gateway вернётся к традиционному методу обновления, что может привести к снижению максимальной пропускной способности в зависимости от количества экземпляров.

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

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

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

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

Да. Шлюз приложений может разрешать короткие имена (например server1 , или backend) в внутренних пулах, если DNS-сервер может разрешить их. Это работает в любой настройке сети, включая локальные, Azure виртуальные сети или гибридные среды.

Чтобы работало краткое разрешение имен:

• DNS-сервер виртуальной сети должен иметь возможность преобразовать короткое имя в IP-адрес.
• Короткие имена работают так же, как полные доменные имена (FQDN) — шлюз запрашивает у DNS-сервера IP-адрес и использует его.

Примечание. Если вы используете DNS по умолчанию Azure (168.63.129.16), он может разрешать только короткие имена ресурсов в одной виртуальной сети. Чтобы разрешить локальные короткие имена, настройте пользовательский 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-адрес для каждого шлюза приложений.

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

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

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

№

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

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

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

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

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

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

Этапы включения режима FIPS в SKU V2: см. раздел Включите режим FIPS для Azure Application Gateway SKU V2.

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

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

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

Register-AzProviderFeature -FeatureName AllowApplicationGatewayEnableFIPS -ProviderNamespace Microsoft.Network

Чтобы зарегистрировать с помощью портала Azure:

• Войдите на портал Azure и найдите функции Preview.
• В поле фильтра введите AllowApplicationGatewayEnableFIPS . Выберите Application Gateway V1 (разрешение режима FIPS), а затем выберите Зарегистрировать.

Step 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 можно использовать curve25519, NistP256 и NistP384, тогда как при включенном режиме FIPS разрешены только NistP256 и NistP384, а curve25519 отключена. Так как кривая25519 становится недоступной в режиме FIPS, убедитесь, что клиенты поддерживают NistP256 или NistP384 для безопасного взаимодействия перед включением FIPS.

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

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

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

Для остановки и запуска шлюза приложений можно использовать Azure PowerShell или Azure CLI. При остановке и запуске Шлюза приложений (Application Gateway) выставление счетов также останавливается и снова запускается. Любая операция 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 (Протокол шифрования с аутентификацией на основе ДЕ с использованием DSS и AES в режиме 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 stapling для серверных сертификатов.

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

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

В настоящее время портал Azure позволяет выбирать хранилища ключей только из той же подписки, что и шлюз приложений. Это известное ограничение портала. Однако Шлюз приложений поддерживает использование хранилища ключей из другой подписки (в пределах одного клиента Microsoft Entra ID), настроив сертификат с помощью Azure CLI или PowerShell с помощью идентификатора секрета хранилища ключей, если управляемое удостоверение шлюза приложений имеет необходимые разрешения для хранилища ключей.

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

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

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

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

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

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

Для получения информации, касающейся Application Gateway:

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

• Недействительный сертификат или отозванный сертификат
• Время ожидания соединения истекло
• HTTP 502

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

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

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

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

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

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

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

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

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

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

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

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

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

Свойство	Цель
слушатель	Для прослушивателей на основе TLS или TCP
Правило маршрутизации	Связывание прослушивателя уровня 4 с параметром серверной части уровня 4
коллекция настроек бэкенда	Параметры серверной части с использованием TLS или TCP

• REST API
• CLI

Примечание.

Для параметров протокола HTTP или HTTPS нельзя использовать какие-либо свойства уровня 4.

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

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

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

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

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

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

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

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

Возможности Web Application Firewall (WAF) не будут работать для использования уровня 4.

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

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

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

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

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

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

Если необходимо изменить параметры шлюза приложений, внесите изменения с помощью предоставленной конфигурации на Ingress-контроллере или других объектах 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 — это управляемая служба, которая означает, что Microsoft автоматически обновляет надстройку до последней стабильной версии.

Да, обновление кластера AKS с Kubenet или CNI на CNI Overlay автоматически обнаруживается Ingress-контроллером Application Gateway. Рекомендуется запланировать обновление во время периода обслуживания, так как может произойти нарушение трафика. Контроллер может занять несколько минут по завершении обновления кластера для обнаружения и настройки поддержки CNI Overlay.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Дополнительные сведения о шлюзе приложений см. в статье What Azure Application Gateway.
• Сведения о завершении TLS и сквозном TLS с помощью шлюза приложений см. статью Enable end-to-end TLS на Azure Application Gateway.