Поделиться через

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

  • Статья

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

Примечание.

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

Обзор

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

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

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

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

Решение

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

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

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

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

Например:

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

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

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

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

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

Решение

Требуется, чтобы CNAME сертификата TLS, установленного на сервере серверной части, совпадал с именем узла, настроенным в параметрах серверной части HTTP, в противном случае второй частью сквозного обмена данными, которая происходит между экземплярами Шлюз приложений и серверной частью, завершится сбоем с параметром "Upstream SSL certificate not match", и выдаст обратно обратноОшибка сервера: 502 — веб-сервер получил недопустимый ответ при выполнении роли шлюза или прокси-сервера.

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

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