Устранение ошибок неправильного шлюза (502) в Шлюз приложений Azure

Сводка

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

Симптомы

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

• Группа безопасности сети (NSG), определяемый пользователем маршрут (UDR) или настраиваемая проблема DNS.
• Проверка работоспособности по умолчанию не может достигать виртуальных машин на серверной стороне.
• Тайм-аут запроса или проблемы подключения при запросах пользователей.
• Серверный пул шлюза приложений не настроен или пуст.
• Неработоспособные экземпляры в BackendAddressPool.
• Вышестоящий SSL-сертификат не соответствует.

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

Причина

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

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

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

Решение

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

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

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

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

3. Проверьте эффективную группу безопасности сети и маршрут с помощью серверной виртуальной машины.

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

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

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

Решение

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

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

Неправильная или недопустимая настройка пользовательских проб работоспособности

Причина

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

В следующей таблице описаны дополнительные свойства, которые можно задать:

Решение

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

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

Проблемы времени ожидания запроса или подключения с запросами пользователей

Причина

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

Решение

Этот параметр можно настроить с помощью BackendHttpSetting, который можно применить к разным пулам. Разные серверные пулы могут иметь разные конфигурации BackendHttpSetting и разные параметры времени ожидания запроса.

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

Серверный пул шлюза приложений не настроен или пуст

Причина

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

Решение

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

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

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

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

Причина

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

Решение

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

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

Причина

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

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

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

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

Рассмотрим пример.

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

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

Как нам известно, включение HTTPS в параметре "Backend 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, в противном случае вторая часть сквозной связи, которая происходит между экземплярами шлюза приложений и серверной частью, завершается сбоем с ошибкой "Upstream SSL-сертификат не совпадает", и выдает ошибку сервера: 502. Веб-сервер получил недопустимый ответ при выполнении роли шлюза или прокси-сервера.