Устранение проблем с работоспособностью серверной части в Шлюзе приложений

Сводка

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

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

Средства проверки работоспособности серверной части

Чтобы проверить работоспособность back-end пула, можно использовать следующие средства:

• страница Backend Health на портале Azure.
• Azure PowerShell (см. также Get-AzApplicationGatewayBackendHealth.
• CLI.
• REST API.

Состояние, полученное любым из этих методов, может быть одним из следующих состояний:

• Healthy
• Unhealthy
• Неизвестно

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

Состояние работоспособности сервера: неисправное

Если статус работоспособности серверной части неисправен, вид портала выглядит как на следующем снимке экрана.

Если вы используете запрос REST API Azure PowerShell, CLI или Azure, вы получите ответ, похожий на следующий пример:

PS C:\Users\testuser\> Get-AzApplicationGatewayBackendHealth -Name "appgw1" -ResourceGroupName "rgOne"
BackendAddressPools :
{Microsoft.Azure.Commands.Network.Models.PSApplicationGatewayBackendHealthPool}
BackendAddressPoolsText : [
{
                              "BackendAddressPool": {
                                "Id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appgw1/b
                          ackendAddressPools/appGatewayBackendPool"
                              },
                              "BackendHttpSettingsCollection": [
                                {
                                  "BackendHttpSettings": {
                                    "TrustedRootCertificates": [],
                                    "Id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appg
                          w1/backendHttpSettingsCollection/appGatewayBackendHttpSettings"
                                  },
                                  "Servers": [
                                    {
                                      "Address": "10.0.0.5",
                                      "Health": "Healthy"
                                    },
                                    {
                                      "Address": "10.0.0.6",
                                      "Health": "Unhealthy"
                                    }
                                  ]
                                }
                              ]
                            }
                        ]

После получения неработоспособного состояния серверного сервера для всех серверов в серверном пуле запросы не пересылаются на серверы, а шлюз приложений возвращает ошибку "502 Недопустимый шлюз" клиенту запроса. Чтобы устранить эту проблему, просмотрите столбец Сведения на вкладке Оценка работоспособности серверной части.

Сообщение, отображаемое в столбце сведений , содержит более подробные сведения о проблеме и на основе этих сведений, вы можете начать устранение неполадок.

Сообщения об ошибках

Таймаут сервера бекэнда

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

Причина. После того как Шлюз приложений отправляет HTTP(S)-запрос пробы на внутренний сервер, он ждет ответ от внутреннего сервера в течение заданного периода времени. Если серверный бэкенд не отвечает в течение этого периода (время ожидания), он помечается как неисправный, пока не начнет снова отвечать в течение настроенного времени ожидания.

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

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

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

Ошибка разрешения DNS

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

Cause: Если внутренний пул имеет тип IP-адреса, FQDN (полное доменное имя) или службы приложений, шлюз приложений определяет IP-адрес из полного доменного имени через DNS (настраиваемый или Azure по умолчанию). Затем Шлюз приложений пытается подключиться к серверу через TCP-порт, указанный в параметрах HTTP. Но если это сообщение отображается, это означает, что Шлюзу приложений не удалось успешно определить IP-адрес указанного полного доменного имени.

Резолюция:

1. Убедитесь, что полное доменное имя в серверном пуле указано правильно и является общедоступным доменом, а затем попробуйте разрешить его с локального компьютера.
2. Если вам удается разрешить IP-адрес, возможно, в конфигурации DNS виртуальной сети что-то неправильно.
3. Проверьте, настроен ли для виртуальной сети настраиваемый DNS-сервер. Если это так, проверьте DNS-сервер о том, почему он не может разрешить IP-адрес указанного полного доменного имени.
4. Если вы используете Azure DNS по умолчанию, убедитесь, что у регистратора доменных имен выполнено правильное сопоставление записей A или CNAME.
5. Если домен является частным или внутренним, попробуйте разрешить его из виртуальной машины в той же виртуальной сети. Если вы не можете это устранить, перезапустите шлюз приложений и снова проверьте. Чтобы перезапустить Шлюз приложений, его необходимо отключить и запустить с помощью команд PowerShell, которые описаны в приведенных связанных ресурсах.
6. Если вы используете короткие имена (доменные имена с одной меткой, например server1 вместо полного доменного имени server1.contoso.com), убедитесь, что DNS-сервер может разрешить короткое имя. встроенная служба DNS Azure (168.63.129.16) разрешает только короткие имена ресурсов в одной виртуальной сети. Для локальных коротких имен используйте пользовательский DNS-сервер, настроенный с соответствующими доменами поиска.

Ошибка TCP-подключения

Сообщение: Шлюзу приложений не удалось подключиться к серверной части. Убедитесь, что серверная часть отвечает на порту, используемом для пробы. Также проверьте, не блокирует ли какая-либо NSG/UDR/брандмауэр доступ к IP и порту этого бэкенда.

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

Решение. Если вы получите эту ошибку, выполните следующие действия.

1. Проверьте, можно ли подключиться к внутреннему серверу через порт, указанный в параметрах HTTP, с помощью браузера или PowerShell. Например, выполните следующую команду: Test-NetConnection -ComputerName www.bing.com -Port 443

2. Если указанный порт не является нужным портом, введите правильный номер порта для Шлюз приложений для подключения к внутреннему серверу.

3. Если не удается подключиться к порту и с локального компьютера, выполните следующие действия.

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

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

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

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

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

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

4. Если проблемы с NSG или UDR не обнаружены, проверьте наличие проблем с приложением на внутреннем сервере, которые не позволяют клиентам устанавливать сеанс TCP на настроенных портах. Вот что следует проверить.

   a. Откройте командную строку (Win+R -> cmd), введите netstat и нажмите Enter.

   b. Проверьте, прослушивает ли сервер настроенный порт. Рассмотрим пример.

           Proto Local Address Foreign Address State PID
           TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4
   

   c. Если он не прослушивает настроенный порт, проверьте параметры вашего веб-сервера. Например: привязки сайтов в IIS, блокирование сервера в NGINX и виртуальный узел в Apache.

   d. Проверьте параметры брандмауэра ОС, чтобы убедиться, что входящий трафик к порту разрешен.

Несоответствие кода состояния HTTP

Сообщение: код состояния HTTP-ответа серверной части не соответствовал параметру пробы. Ожидается: {HTTPStatusCode0} Получено: {HTTPStatusCode1}.

Причина. После установки TCP-подключения и подтверждения TLS (если протокол TLS включен), Шлюз приложений отправляет пробу в виде HTTP-запроса GET на внутренний сервер. Как описано ранее, для пробы по умолчанию задано значение <protocol>://127.0.0.1:<port>/, и он рассматривает коды состояния ответа в диапазоне от 200 до 399 как исправные. Если сервер возвращает любой другой код состояния, он помечается как неисправный с соответствующим сообщением.

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

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

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

Несоответствие текста ответа HTTP

Сообщение: текст HTTP-ответа серверной части не соответствовал параметру пробы. Текст полученного ответа не содержит {string}.

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

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

1. Обратитесь к внутреннему серверу локально или с клиентского компьютера по пути пробы и проверьте текст ответа.
2. Убедитесь, что текст ответа в настраиваемой конфигурации пробы шлюза приложений соответствует настроенной конфигурации.
3. Если он не совпадает, измените конфигурацию пробы, чтобы она принимала правильное строковое значение.

Узнайте больше о процессе сопоставления проверок на шлюзе приложений.

Общее имя (CN) не соответствует

Сообщение: (Для версии 2) Общее имя конечного сертификата, представленного сервером, не соответствует имени хоста проверки или серверной настройки шлюза приложений.
(для версии 1) Общее имя (CN) сертификата бэкенда не соответствует.

Причина: (Для версии 2) Это происходит, когда вы выбираете протокол HTTPS в параметрах серверной части, и ни имя узла пользовательской пробы, ни имя узла серверной части не соответствуют общему имени (CN) сертификата серверной части.
(для версии 1) Полное доменное имя целевого сервера серверного пула не соответствует общему имени (CN) сертификата внутреннего сервера.

Решение. Сведения об имени узла критически важны для внутреннего подключения HTTPS, так как это значение используется для задания указания имени сервера (SNI) во время подтверждения TLS. Эту проблему можно устранить следующими способами на основе конфигурации шлюза.

Для версии 2

• При использовании проверки по умолчанию в соответствующем параметре серверной части шлюза приложений вашей системы можно указать имя хоста. В настройке серверной части можно выбрать "Замена определенным именем хоста" или "Выбрать имя хоста из целевого серверного объекта".
• Если вы используете настраиваемую пробу — для пользовательской пробы, можно использовать поле host, чтобы указать общее имя сертификата внутреннего сервера. Кроме того, если параметр серверной части уже настроен с тем же хостнеймом, в настройках пробы можно выбрать "Выбрать хостнейм из настройки серверной части".

Для версии 1 убедитесь, что полное доменное имя целевого внутреннего пула совпадает с общим именем (CN).

Советы. Чтобы определить общее имя (CN) внутреннего сертификата сервера, можно использовать любой из этих методов. Кроме того, обратите внимание, что согласно RFC 6125, если SAN существует, проверка SNI проводится только по этому полю. Поле общего имени совпадает, если в сертификате нет SAN.

• Используя браузер или любой клиент: получайте доступ к серверу напрямую (не через Шлюз приложений) и нажмите на значок замка в адресной строке, чтобы просмотреть сведения о сертификате. Его можно найти в разделе "Кому выдано".

• Войдите на внутренний сервер (Windows):

  1. Войдите на компьютер, на котором размещено приложение.
  2. Нажмите клавиши Win+R или щелкните правой кнопкой мыши кнопку Пуск, а затем выберите Запустить.
  3. Введите certlm.msc и нажмите Enter. Можно также выполнить поиск диспетчера сертификатов в меню Пуск.
  4. Найдите сертификат (обычно в сертификатах — локальный компьютер\Личный\Сертификаты) и откройте сертификат.
  5. На вкладке "Сведения" проверьте тему сертификата.

• Авторизовавшись на сервере бэкенда (Linux): выполните следующую команду OpenSSL, указав правильное имя файла сертификата. openssl x509 -in certificate.crt -subject -noout

Срок действия сертификата серверной части истек

Сообщение: сертификат бэкенда недействителен. Текущая дата не попадает в указанный в сертификате диапазон дат "Действителен с" и "Действителен до".

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

Решение. Решение зависит от того, какая часть цепочки сертификатов истекла на серверном сервере.

Для SKU V2

• Истекший сертификат (также известный как сертификат домена или сервера) — обновите сертификат сервера у поставщика сертификатов и установите новый сертификат на сервере. Убедитесь, что вы устанавливаете полную цепочку сертификатов, состоящую из Leaf (topmost) > Intermediate(s) > Root. В зависимости от типа центра сертификации (ЦС) можно выполнить следующие действия в шлюзе.

  • Общедоступный ЦС: если издатель сертификата является хорошо известным ЦС, вам не нужно предпринимать никаких действий в шлюзе приложений.
  • Частный ЦС: если конечный сертификат выдан частным ЦС, необходимо проверить, изменился ли корневой сертификат ЦС. В таких случаях необходимо загрузить новый сертификат корневого сертификационного центра (ЦС) (.CER) в связанный параметр серверной части вашего шлюза.

• Истекший срок действия промежуточного или корневого сертификата— как правило, эти сертификаты имеют относительно расширенные сроки действия (десять или два). Когда срок действия корневого или промежуточного сертификата истекает, рекомендуется проверить у поставщика сертификатов обновленные файлы сертификатов. Убедитесь, что вы устанавливаете эту обновленную и полную цепочку сертификатов, которая содержит Leaf (topmost) > Intermediate(s) > Root, на сервер заднего плана.

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

Для SKU V1

• Обновите конечный сертификат (также известный как доменный или серверный) у вашего ЦС и загрузите тот же самый конечный сертификат (.CER) в соответствующую настройку бэкенда вашего шлюза приложений.

Промежуточный сертификат не найден

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

Причина. Промежуточные сертификаты не установлены в цепочке сертификатов на сервере серверной части.

Решение. Промежуточный сертификат используется для подписи конечного сертификата и поэтому необходим для завершения цепочки. Проверьте центр сертификации (ЦС) на предмет необходимых промежуточных сертификатов и установите их на внутреннем сервере. Цепочка должна начинаться с финального сертификата, затем следовать промежуточные сертификаты, и завершаться корневым сертификатом Центра Сертификации (ЦС). Рекомендуем установить полную цепочку на внутреннем сервере, включая корневой сертификат ЦС. Для справки ознакомьтесь с примером цепочки сертификатов в разделе "'Лист' должен быть самым верхним в цепочке".

Эти изображения показывают разницу между самозаверенными сертификатами.

Сертификат листа или сервера не найден

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

Причина: Конечный сертификат (также известный как сертификат домена или сервера) отсутствует в цепочке сертификатов на сервере.

Решение: Вы можете получить листовой сертификат из центра сертификации (ЦС). Установите этот конечный сертификат и все его сертификаты подписи (промежуточные и корневые сертификаты ЦС) на серверном сервере. Цепочка должна начинаться с финального сертификата, затем следовать промежуточные сертификаты, и завершаться корневым сертификатом Центра Сертификации (ЦС). Рекомендуем установить полную цепочку на внутреннем сервере, включая корневой сертификат ЦС. Для справки ознакомьтесь с примером цепочки сертификатов в разделе "'Лист' должен быть самым верхним в цепочке".

Сертификат сервера не выдан публично известным центром сертификации

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

Причина: Вы выбрали "известный сертификат центра сертификации" в параметрах серверной части, но корневой сертификат, представленный сервером, не является общедоступным.

Решение: Когда конечный сертификат выдан частным центром сертификации (ЦС), сертификат корневого ЦС, который выполняет подпись, должен быть отправлен в параметры серверной части шлюза приложений. Это позволяет шлюзу приложений установить доверенное соединение с внутренним сервером. Чтобы устранить эту проблему, перейдите к связанным настройкам бэкенда, выберите "не широко известный УЦ" и загрузите сертификат корневого УЦ (CER). Чтобы определить и скачать корневой сертификат, можно выполнить те же действия, которые описаны в разделе Несоответствие доверенных корневых сертификатов.

Промежуточный сертификат не подписан публично известным УЦ.

Сообщение.Промежуточный сертификат не подписан известным центром сертификации (ЦС). Убедитесь, что цепочка сертификатов завершена и правильно упорядочена на сервере серверной части.

Причина: Вы выбрали "сертификат известного УЦ" в настройках серверной части, но промежуточный сертификат, представленный сервером, не подписан каким-либо общедоступным УЦ.

Решение: Если сертификат выдан частным центром сертификации (ЦС), сертификат корневого ЦС, который подписывает сертификат, должен быть загружен в связанный параметр настроек бэкенда шлюза приложений. Это позволяет шлюзу приложений установить доверенное соединение с внутренним сервером. Чтобы устранить эту проблему, обратитесь к частному центру сертификации, чтобы получить соответствующий сертификат корневого ЦС (.CER), и загрузите этот файл .CER в настройки backend вашего шлюза приложений, выбрав "неизвестный центр сертификации". Также рекомендуется установить полную цепочку на внутреннем сервере, включая корневой сертификат ЦС, чтобы упростить проверку.

Несоответствие доверенных корневых сертификатов (корневой сертификат на серверном сервере отсутствует)

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

Причина: Ни один из сертификатов корневого центра сертификации, загруженных в связанный параметр настройки серверной части, не подписал промежуточный сертификат, установленный на сервере. Бэкэнд сервер имеет установлены только конечные и промежуточные сертификаты.

Решение: Конечный сертификат подписан промежуточным сертификатом, который, в свою очередь, подписан корневым сертификатом ЦС. При использовании сертификата из частного центра сертификации (ЦС) необходимо отправить соответствующий сертификат корневого ЦС в шлюз приложений. Обратитесь к частному УЦ, чтобы получить соответствующий сертификат Корневого УЦ (.CER) и загрузите этот CER-файл в настройках серверной части вашего шлюза приложений.

Несоответствие доверенного корневого сертификата (корневой сертификат доступен на сервере бэкенда)

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

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

Решение: Это относится к сертификату серверной части, выданному частным центром сертификации (ЦС) или самоподписанному. Определите и загрузите правильный корневой сертификат ЦС в соответствующую настройку бэкэнда.

Советы. Чтобы определить и скачать корневой сертификат, можно использовать любой из этих методов.

• С помощью браузера: Осуществите доступ к интерфейсу серверной системы напрямую (не через Шлюз приложений) и щелкните на значок замка сертификата в адресной строке, чтобы просмотреть сведения о сертификате.

  1. Выберите корневой сертификат в цепочке и нажмите кнопку "Экспорт". По умолчанию это . CRT-файл.
  2. Откройте файл .CRT.
  3. Перейдите на вкладку "Сведения" и щелкните "Копировать в файл",
  4. На странице мастера экспорта сертификатов нажмите кнопку "Далее",
  5. Выберите "X.509 в кодировке Base-64 (.CER)" и нажмите "Далее".
  6. Присвойте новому имени файла и нажмите кнопку "Далее",
  7. Нажмите кнопку "Готово", чтобы получить . CER-файл.
  8. Загрузите этот корневой сертификат (.CER) частного центра сертификации (ЦС) в настройки серверной части шлюза приложений.

• Входя на сервер бэкенда (Windows)

  1. Войдите на компьютер, на котором размещено приложение.
  2. Нажмите клавиши Win+R или щелкните правой кнопкой мыши кнопку Пуск, а затем выберите Запустить.
  3. Введите certlm.msc и нажмите Enter. Можно также выполнить поиск диспетчера сертификатов в меню Пуск.
  4. Найдите сертификат, как правило, в сертификатах — локальный компьютер\Personal\Certificates и откройте его.
  5. Выберите корневой сертификат, а затем выберите Просмотр сертификата.
  6. В свойствах сертификата выберите вкладку "Сведения" и нажмите кнопку "Копировать в файл",
  7. На странице мастера экспорта сертификатов нажмите кнопку "Далее",
  8. Выберите "X.509 в кодировке Base-64 (.CER)" и нажмите "Далее".
  9. Присвойте новому имени файла и нажмите кнопку "Далее",
  10. Нажмите кнопку "Готово", чтобы получить . CER-файл.
  11. Загрузите этот корневой сертификат (.CER) частного центра сертификации (ЦС) в настройки серверной части шлюза приложений.

Лист должен быть самым верхним в цепочке.

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

Причина: Конечный сертификат (также известный как домен или сервер) не установлен в правильном порядке на сервере.

Решение. Установка сертификата на серверном сервере должна содержать упорядоченный список сертификатов, состоящих из конечного сертификата и всех его сертификатов подписи (сертификатов промежуточного и корневого ЦС). Эта цепочка должна начинаться с конечного сертификата, а затем промежуточных сертификатов и, наконец, корневого сертификата ЦС. Рекомендуем установить полную цепочку на внутреннем сервере, включая корневой сертификат ЦС.

Дан пример установки сертификата сервера вместе с его сертификатами промежуточного и корневого Центра сертификации, обозначаемых как глубины (0, 1, 2 и т. д.) в OpenSSL. Вы можете проверить то же самое для сертификата внутреннего сервера с помощью следующих команд OpenSSL.
s_client -connect <FQDN>:443 -showcerts
ИЛИ
s_client -connect <IPaddress>:443 -servername <TLS SNI hostname> -showcerts

Неудачная проверка сертификата

Сообщение. Не удалось проверить допустимость внутреннего сертификата. Чтобы узнать причину, проверьте данные диагностики OpenSSL на наличие сообщения, связанного с кодом ошибки {код_ошибки}.

Причина. Эта ошибка возникает, когда Шлюз приложений не может проверить действительность сертификата.

Решение. Чтобы устранить эту проблему, убедитесь, что сертификат на сервере был создан правильно. Например, вы можете использовать OpenSSL для проверки сертификата и его свойств, а также попытаться повторно передать сертификат в параметры HTTP Шлюза приложений.

Неподдерживаемый протокол прокси-сервера

Сообщение: Убедитесь, что сервер бэкенда настроен для принятия заголовка протокола Прокси, отправленного зондами.

Причина: Эта ошибка возникает только с параметрами серверной части протокола TLS, для которых включена сохранение IP-адресов клиента. В этом режиме Application Gateway отправляет заголовок протокола Proxy Protocol перед началом TLS-рукопожатия с серверной частью для диагностики. Если сервер серверной части не настроен для синтаксического анализа такого заголовка, проверка работоспособности завершается сбоем, и шлюз приложений помечает его как недоступным.

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

Состояние работоспособности серверной части: Неизвестно

Обновления записей DNS серверного пула

Сообщение: не удалось получить данные о состоянии серверной части. Это происходит, когда NSG/UDR/брандмауэр в подсети шлюза приложений блокирует трафик на портах 65503-65534 в случае версии SKU v1, а на портах 65200-65535 в случае версии SKU v2, или если полное доменное имя, настроенное в пуле серверов (backend pool), не удается разрешить в IP-адрес. Чтобы узнать больше, посетите - https://aka.ms/UnknownBackendHealth.

Причина: Для целевых серверных интерфейсов на основе полностью квалифицированного доменного имени (FQDN) шлюз приложений кэширует и воспользуется последним известным IP-адресом, если не удается получить ответ на последующий поиск DNS. Операция PUT на шлюзе в таком состоянии может полностью очистить его кэш DNS. В результате не будет адреса назначения, с которым шлюз может соединиться.

Резолюция: Проверьте и исправьте DNS-серверы, чтобы убедиться, что они возвращают ответ для указанного полностью квалифицированного доменного имени (FQDN). Кроме того, необходимо проверить, доступны ли DNS-серверы через виртуальная сеть шлюза приложений.

Другие причины.

Если работоспособность серверной части отображается как "Неизвестно", представление портала напоминает следующий снимок экрана:

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

1. Группа безопасности сети в подсети шлюза приложений блокирует входящий доступ к портам 65503-65534 (номер SKU версии 1) или 65200-65535 (номер SKU версии 2) из Интернета.
2. UDR в подсети шлюза приложений имеет маршрут по умолчанию (0.0.0.0/0/0), а следующий прыжок не указан как "Интернет".
3. Маршрут по умолчанию объявляется подключением ExpressRoute или VPN к виртуальной сети по протоколу BGP.
4. Пользовательский DNS-сервер настроен в виртуальной сети, которая не может разрешать общедоступные доменные имена.
5. Шлюз приложений находится в неисправном состоянии.

Solution:

1. Проверьте, не блокирует ли группа безопасности сети доступ из Интернета к портам 65503–65534 (номер SKU версии 1) или 65200–65535 (SKU версии 2).

   a. На вкладке шлюза приложений Overview щелкните ссылку виртуальная сеть/Subnet. b. На вкладке "Подсети" виртуальной сети выберите подсеть, в которой развернуты Шлюз приложений. c. Проверьте, настроен ли хоть один NSG. d. Если настроена группа безопасности сети (NSG), найдите эту NSG на вкладке Поиск или в разделе Все ресурсы. д) В разделе "Правила для входящих подключений" добавьте правило для разрешения диапазона портов назначения 65503-65534 для версии SKU 1 или 65200-65535 для версии SKU 2, при этом Источник установлен как тег службы GatewayManager. f. Выберите Сохранить и убедитесь, что сервер отображается как исправный. Кроме того, это можно сделать с помощью PowerShell или интерфейса командной строки.

2. Проверьте, имеет ли UDR маршрут по умолчанию (0.0.0.0/0) со следующим маршрутом, не установленным как Интернет:

   a. Выполните пункты 1a и 1b, чтобы выяснить вашу подсеть. b. Проверьте, настроен ли UDR. Если это так, выполните поиск соответствующего ресурса на панели поиска или в разделе Все ресурсы. c. Проверьте наличие маршрутов по умолчанию (0.0.0.0/0) с следующим узлом, который не задан как Интернет. Если параметр имеет значение Virtual Device или виртуальная сеть Gateway, необходимо убедиться, что виртуальный модуль или локальное устройство может правильно направлять пакет обратно в место назначения Интернета без изменения пакета. Если пробы направляются через виртуальное устройство и изменяются, ресурс бэкенда отображает код состояния 200, а состояние работоспособности шлюза приложений может отображаться как Неизвестно. Это не означает ошибку. Трафик по-прежнему должен маршрутизироваться через Шлюз приложений без проблем. d. В противном случае измените следующий прыжок на Internet (Интернет), выберите Сохранить и проверьте работоспособность серверной части.

3. Маршрут по умолчанию, объявленный подключением ExpressRoute/VPN к виртуальной сети через BGP (протокол пограничного шлюза):

   a. Если у вас есть подключение ExpressRoute/VPN к виртуальной сети через BGP, и если вы рекламируете маршрут по умолчанию, необходимо убедиться, что пакет направляется обратно в место назначения Интернета, не изменяя его. Проверить это можно с помощью параметра Устранение неполадок с подключением на портале Шлюза приложений. b. Выберите адрес назначения вручную, как любой IP-адрес, маршрутизируемый через интернет, например 1.1.1.1. Задайте любой порт назначения и проверьте подключение. c. Если следующим узлом является шлюз виртуальной сети, по ExpressRoute или VPN может распространяться маршрут по умолчанию.

4. Если в виртуальной сети настроен пользовательский DNS-сервер, убедитесь, что серверы могут разрешать общедоступные домены. Разрешение имени общедоступного домена может потребоваться в сценариях, когда шлюз приложений должен обращаться к внешним доменам, таким как серверы OCSP (протокол состояния сертификата online) или проверять состояние отзыва сертификата.

5. Чтобы убедиться, что шлюз приложений работоспособен и работает, перейдите к параметру Работоспособность ресурсов на портале и убедитесь, что состояние Healthy. Если отображается состояние Нездорово или Снижена, обратитесь в поддержку Azure.

6. Если Интернет и частный трафик проходят через Брандмауэр Azure, размещенную в защищенном виртуальном концентраторе (с помощью центра Виртуальная глобальная сеть Azure):

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

   Префикс адреса: 0.0.0.0/0
   Следующий переход: Интернет

   b. Чтобы шлюз приложений смог отправить трафик в внутренний пул через Брандмауэр Azure в центре Виртуальная глобальная сеть, настройте следующий определяемый пользователем маршрут:

   Префикс адреса: подсеть серверного пула
   Следующий прыжок: Брандмауэр Azure частный IP-адрес

Справочные материалы

• Диагностика работоспособности и ведение журнала серверной части шлюза приложений.
• Устранение неполадок подключения в Azure Network Watcher - ознакомьтесь с документацией по функции Устранение неполадок подключения, чтобы узнать, как использовать этот инструмент.