Troubleshooting bad gateway errors in Application Gateway (Устранение ошибок "Недопустимый шлюз" в Шлюзе приложений)

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

Примечание.

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

Обзор

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

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

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

Причина

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

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

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

Решение

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

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

2. Проверьте определяемый пользователем маршрут, связанный с подсетью шлюза приложений. Убедитесь, что определяемый пользователем маршрут не направляет трафик за пределы внутренней подсети. Проверьте маршрутизацию к виртуальным сетевым устройствам или маршруты по умолчанию, объявляемые для подсети шлюза приложений через Azure ExpressRoute или VPN.

   $vnet = Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName
   Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet
   

3. Проверьте действующую NSG и маршрут с серверной виртуальной машиной.

   Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName nic1 -ResourceGroupName testrg
   Get-AzEffectiveRouteTable -NetworkInterfaceName nic1 -ResourceGroupName testrg
   

4. Проверьте наличие пользовательской службы DNS в виртуальной сети. Службу DNS можно проверить, просмотрев подробности свойств виртуальной сети в выходных данных.

   Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName 
   DhcpOptions            : {
                              "DnsServers": [
                                "x.x.x.x"
                              ]
                            }
   

5. При ее наличии убедитесь, что 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.
• Убедитесь, что интервал, время ожидания и неработоспособнаяthreshold находятся в допустимых диапазонах.
• При использовании зонда HTTPS убедитесь, что внутренний сервер не требует SNI путем настройки резервного сертификата.

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

Причина

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

Решение

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

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

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

Причина

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

Решение

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

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

Выходные данные из предыдущего командлета должны содержать пул адресов неmpty серверной части. В следующем примере показаны два пула, которые настроены с полным доменным именем или 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"
}]

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

Причина

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

Решение

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

Вышестоящий SSL-сертификат не соответствует

Причина

Сертификат TLS, установленный на внутренних серверах, не соответствует имени узла, полученному в заголовке запроса узла.

В сценариях, когда включён сквозной TLS, конфигурация, которая достигается путём редактирования соответствующих "Параметров HTTP бекэнда" и изменения конфигурации параметра "Протокол бекэнда" на HTTPS, необходимо убедиться, что DNS-имя сертификата TLS, установленного на серверных системах, соответствует имени хоста, поступающему в бекэнд в запросе заголовка хоста HTTP.

При использовании параметра протокола HTTPS вместо HTTP в "Настройках HTTP на серверной части" второй этап обмена данными между экземплярами Шлюза Приложений и бэкэнд-серверами будет шифроваться с помощью TLS.

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

Например:

Представьте, что у вас есть шлюз приложений для обслуживания https-запросов для домена www.contoso.com. Вы можете делегировать домен contoso.com в общедоступную зону Azure DNS и запись DNS в этой зоне, указывающую www.contoso.com на общедоступный IP-адрес конкретного шлюза приложений, который будет обслуживать запросы.

На этом шлюзе приложений должен быть прослушиватель для узла www.contoso.com с правилом, которое требует настройки HTTP на стороне бэкенда, принудительно использующие протокол HTTPS (чтобы обеспечить сквозное шифрование TLS). Это же правило может настроить внутренний пул с двумя виртуальными машинами под управлением IIS в качестве веб-серверов.

Как мы знаем, включение HTTPS в параметре "Backed HTTP Setting" правила делает вторую часть связи, которая происходит между экземплярами шлюза приложений и серверами в серверной части для использования TLS.

Если серверные серверы не имеют сертификата TLS, выданного для DNS-имени www.contoso.com или *.contoso.com, запрос завершается ошибкой сервера: 502 — веб-сервер получил недопустимый ответ, выполняя роль шлюза или прокси-сервера , так как вышестоящий SSL-сертификат (сертификат, установленный на внутренних серверах), не соответствует имени узла в заголовке узла, и, следовательно, согласование TLS завершается ошибкой.

www.contoso.com >- IP-адрес внешнего интерфейса APP GW —> прослушиватель с правилом настройки "Параметры HTTP серверной части" для использования протокола HTTPS вместо HTTP > Пул серверов серверной части > Веб-сервер (должен иметь установленный сертификат TLS для www.contoso.com)

Решение

Необходимо, чтобы DNS-имя сертификата TLS, установленного на сервере бекенда, совпадало с именем узла, настроенным в параметрах серверной части HTTP, иначе вторая часть сквозного обмена данными, происходящего между экземплярами шлюза приложений и сервером бекенда, завершится сбоем с ошибкой 'SSL-сертификат не совпадает с вышестоящим узлом', и возвращает ошибку сервера: 502. Веб-сервер получил недопустимый ответ при выполнении роли шлюза или прокси-сервера.

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

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