Устранение ошибок "Недопустимый шлюз" в шлюзе приложений

Практическое руководство по устранению ошибок "Недопустимый шлюз" (502), полученных при использовании шлюза приложений Azure.

Примечание

В этой статье предусмотрено использование модуля Azure Az PowerShell, который является рекомендуемым модулем PowerShell для взаимодействия с Azure. Чтобы начать работу с модулем Az PowerShell, ознакомьтесь со статьей Установка Azure PowerShell. Дополнительные сведения см. в статье Перенос Azure PowerShell с AzureRM на Az.

Обзор

После настройки шлюза приложений может появиться сообщение об ошибке: "502 - Веб-сервером в качестве шлюза или прокси-сервера получен недопустимый ответ". Возможные причины возникновения этой ошибки:

Проблема группы безопасности сети, определенного пользователем маршрута или пользовательской службы DNS

Причина

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

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

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

Решение

Проверьте конфигурацию NSG, UDR и DNS, сделав следующее:

  • Проверьте группы безопасности сети, связанные с подсетью шлюза приложений. Убедитесь, что связь с серверной частью не заблокирована.
  • Проверьте определяемый пользователем маршрут, связанный с подсетью шлюза приложений. Убедитесь, что определяемый пользователем маршрут не направляет трафик за пределы внутренней подсети. Проверьте маршрутизацию к виртуальным сетевым устройствам или маршруты по умолчанию, объявляемые для подсети шлюза приложений через Azure ExpressRoute или VPN.
$vnet = Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName
Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet
  • Проверьте действующую NSG и маршрут с серверной виртуальной машиной.
Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName nic1 -ResourceGroupName testrg
Get-AzEffectiveRouteTable -NetworkInterfaceName nic1 -ResourceGroupName testrg
  • Проверьте наличие пользовательской службы DNS в виртуальной сети. Службу DNS можно проверить, просмотрев подробности свойств виртуальной сети в выходных данных.
Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName 
DhcpOptions            : {
                           "DnsServers": [
                             "x.x.x.x"
                           ]
                         }

При ее наличии убедитесь, что DNS-сервер может правильно разрешить полное доменное имя участника внутреннего пула.

Проблемы со стандартной пробой работоспособности

Причина

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

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

В таблице приведены значения, связанные со стандартной пробой работоспособности:

Свойства проверки Значение Описание
URL-адрес проверки http://127.0.0.1/ URL-адрес
Интервал 30 Интервал проверки в секундах
Время ожидания 30 Время ожидания проверки в секундах
Пороговое значение сбоя 3 Количество повторных попыток проверки. Сервер внутреннего пула считается неисправным, когда количество повторных неудачных попыток проверки достигает порогового значения сбоя.

Решение

  • Значение узла для запроса будет равно 127.0.0.1. Убедитесь, что стандартный сайт настроен и ожидает передачи данных по адресу 127.0.0.1.
  • Протокол запроса определяется протоколом BackendHttpSetting.
  • Для / пути URI будет задано значение.
  • Если в параметре BackendHttpSetting задан порт, отличный от 80, на стандартном сайте нужно настроить ожидание передачи данных через этот порт.
  • Вызов к protocol://127.0.0.1:port должен вернуть код результата HTTP 200. Необходимо вернуть в течении 30-секундного периода ожидания.
  • Убедитесь, что настроенный порт открыт и отсутствуют правила брандмауэра или группы безопасности сети Azure, блокирующие входящий или исходящий трафик в настроенном порте.
  • Если классические виртуальные машины Azure или облачная служба используются с полным доменным именем или общедоступным IP-адресом, откройте соответствующую конечную точку.
  • Если виртуальная машина настроена с помощью Azure Resource Manager и находится за пределами виртуальной сети, в которой развернут шлюз приложений, настройте в группе безопасности сети доступ через нужный порт.

Проблемы с пользовательскими пробами работоспособности

Причина

Пользовательские пробы работоспособности более гибкие по сравнению со стандартными. Для пользовательских проб можно настроить интервал, URL-адрес и путь к ним (для тестирования), а также число неудачных откликов, после которых экземпляр внутреннего пула будет считаться неработоспособным.

Добавлены следующие дополнительные свойства.

Свойства проверки Описание
Имя Имя проверки. Это имя используется для указания проверки в параметрах HTTP внутреннего сервера
Протокол Протокол, используемый для проверки. Проба использует протокол, определенный в параметрах HTTP серверной части.
Узел Имя узла для проверки. Применяется только в случае, если в шлюзе приложений настроено многосайтовое подключение. (То есть указывается не имя узла виртуальной машины.)
путь Относительный путь проверки. Путь должен начинаться с "/". Проба отправляется по адресу <протокол>://<узел>:<порт><путь>.
Интервал Интервал проверки в секундах. Интервал времени между двумя последовательными проверками.
Время ожидания Время ожидания проверки в секундах. Если ответ о работоспособности не получен в течение этого времени ожидания, то проба считается неудачной.
Пороговое значение сбоя Количество повторных попыток проверки. Сервер внутреннего пула считается неисправным, когда количество повторных неудачных попыток проверки достигает порогового значения сбоя.

Решение

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

  • проба указана правильно, согласно руководству;
  • Если шлюз приложений настроен для одного сайта, по умолчанию имя узла должно быть указано как 127.0.0.1 , если иное не настроено в пользовательской зонде.
  • Убедитесь, что вызов к http://<узел>:<порт><путь> возвращает HTTP-код результата 200.
  • Убедитесь, что значения "Интервал", "Время ожидания" и "Порог работоспособности" находятся в допустимом диапазоне.
  • При использовании зонда HTTPS убедитесь, что внутренний сервер не требует SNI путем настройки резервного сертификата.

Время ожидания запроса

Причина

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

Решение

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

    New-AzApplicationGatewayBackendHttpSettings -Name 'Setting01' -Port 80 -Protocol Http -CookieBasedAffinity Enabled -RequestTimeout 60

Пустой серверный пул адресов

Причина

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

Решение

Убедитесь, что серверный пул адресов не пуст. Это можно сделать с помощью PowerShell, интерфейса командной строки или на портале.

Get-AzApplicationGateway -Name "SampleGateway" -ResourceGroupName "ExampleResourceGroup"

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

BackendAddressPoolsText:

[{
    "BackendAddresses": [{
        "ipAddress": "10.0.0.10",
        "ipAddress": "10.0.0.11"
    }],
    "BackendIpConfigurations": [],
    "ProvisioningState": "Succeeded",
    "Name": "Pool01",
    "Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
    "Id": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool01"
}, {
    "BackendAddresses": [{
        "Fqdn": "xyx.cloudapp.net",
        "Fqdn": "abc.cloudapp.net"
    }],
    "BackendIpConfigurations": [],
    "ProvisioningState": "Succeeded",
    "Name": "Pool02",
    "Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
    "Id": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool02"
}]

Неработоспособные экземпляры в серверном пуле адресов

Причина

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

Решение

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

Дальнейшие действия

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