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

Статья
03/08/2024

Обзор

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

Как проверить работоспособность серверной части

Чтобы проверить работоспособность серверного пула, можно использовать страницу Оценка работоспособности серверной части на портале Azure. Можно также использовать Azure PowerShell, интерфейс командной строки или REST API.

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

Работоспособно
Unhealthy
Неизвестно

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

Примечание.

Если у пользователя нет разрешения на просмотр состояний работоспособности серверной части, No results. отобразится сообщение.

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

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

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

PS C:\Users\testuser\> Get-AzApplicationGatewayBackendHealth -Name "appgw1" -ResourceGroupName "rgOne"
BackendAddressPools :
{Microsoft.Azure.Commands.Network.Models.PSApplicationGatewayBackendHealthPool}
BackendAddressPoolsText : [
{
                              "BackendAddressPool": {
                                "Id": "/subscriptions/536d30b8-665b-40fc-bd7e-68c65f816365/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appgw1/b
                          ackendAddressPools/appGatewayBackendPool"
                              },
                              "BackendHttpSettingsCollection": [
                                {
                                  "BackendHttpSettings": {
                                    "TrustedRootCertificates": [],
                                    "Id": "/subscriptions/536d30b8-665b-40fc-bd7e-68c65f816365/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 Bad Gateway". Чтобы устранить эту проблему, просмотрите столбец Сведения на вкладке Оценка работоспособности серверной части.

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

Примечание.

Запрос пробы <по умолчанию отправляется в формате protocol>://127.0.0.1:<port>. Например, http://127.0.0.1:80 для пробы HTTP через порт 80. Только коды состояния HTTP от 200 до 399 соответствуют работоспособному состоянию. Протокол и порт назначения наследуются от параметров HTTP. Если требуется, чтобы Шлюз приложений выполнял пробу для другого протокола, имени узла или пути и определял другой код состояния как работоспособный, настройте пользовательскую пробу и свяжите ее с параметрами HTTP.

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

Время ожидания внутреннего сервера

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

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

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

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

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

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

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

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

Решение.

Убедитесь, что полное доменное имя в серверном пуле указано правильно и является общедоступным доменом, а затем попробуйте разрешить его с локального компьютера.
Если вы можете разрешить IP-адрес, возможно, в виртуальной сети возникли проблемы с конфигурацией DNS.
Проверьте, настроен ли для виртуальной сети настраиваемый DNS-сервер. Если это так, проверьте DNS-сервер на предмет того, почему он не может разрешить IP-адрес указанного полного доменного имени.
Если вы используете DNS по умолчанию Azure, обратитесь к регистратору доменных имен, чтобы узнать, завершено ли сопоставление соответствующих записей A или записей CNAME.
Если домен является частным или внутренним, попробуйте разрешить его имя из виртуальной машины в той же виртуальной сети. Если вам это удалось, перезапустите Шлюз приложений и проверьте наличие проблемы. Чтобы перезапустить Шлюз приложений, его необходимо отключить и запустить с помощью команд PowerShell, которые описаны в приведенных связанных ресурсах.

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

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

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

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

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

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

b. Проверьте, допускают ли параметры NSG подсети Шлюза приложений исходящий общий и частный трафик, чтобы можно было установить подключение. Дополнительные сведения о создании правил NSG см. на странице документации, приведенной в действии 3a.
```
        $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"
```
Если проблемы с NSG или UDR не обнаружены, проверьте наличие проблем с приложением на внутреннем сервере, которые не позволяют клиентам устанавливать сеанс TCP на настроенных портах. Вот что следует проверить.

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

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-ответа серверной части не соответствовал параметру пробы. Expected:{HTTPStatusCode0} Received:{HTTPStatusCode1}.

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

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

Error	Действия
Несоответствие кода состояния пробы: получено 401	Проверьте, требуется ли для внутреннего сервера аутентификация. Пробы Шлюза приложений не могут передавать учетные данные для аутентификации. Разрешить "HTTP 401" в совпадении кода состояния пробы или пробе в путь, в котором сервер не требует проверки подлинности.
Несоответствие кода состояния пробы: получено 403	доступ запрещен". Проверьте, разрешен ли доступ к пути на внутреннем сервере
Несоответствие кода состояния пробы: получено 404	страница не найдена". Проверьте, доступен ли путь к имени узла на внутреннем сервере. Измените имя узла или параметр пути, указав доступное значение.
Несоответствие кода состояния пробы: получено 405	В запросах пробы для Шлюза приложений используется метод HTTP GET. Проверьте, разрешает ли сервер этот метод.
Несоответствие кода состояния пробы: получено 500	Внутренняя ошибка сервера. Проверьте работоспособность внутреннего сервера и убедитесь, что службы работают.
Несоответствие кода состояния пробы: получено 503	Служба недоступна. Проверьте работоспособность внутреннего сервера и убедитесь, что службы работают.

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

Чтобы создать пользовательскую пробу, выполните эти действия.

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

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

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

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

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

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

Примечание.

Чтобы изучить все сообщения об ошибках, связанные с TLS, и узнать больше о реакции SNI на событие, а также различиях между номерами SKU версий 1 и 2, перейдите на страницу общих сведений о TLS.

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

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

Причина: (Для версии 2) Это происходит, если вы выбрали протокол HTTPS в параметре серверной части, а имя узла пользовательской пробы или серверного параметра (в таком порядке) не соответствует общему имени (CN) сертификата внутреннего сервера.Это происходит, если вы выбрали протокол 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 и нажмите клавишу ВВОД. Можно также выполнить поиск диспетчера сертификатов в меню Пуск.
4. Найдите сертификат (обычно в сертификатах — локальный компьютер\Личный\Сертификаты) и откройте сертификат.
5. На вкладке Сведения проверьте значение Subject (Субъект) сертификата.
Выполнив ведение журнала на сервере серверной части (Linux): выполните следующую команду OpenSSL, указав правильное имя файла сертификата. openssl x509 -in certificate.crt -subject -noout

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

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

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

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

Для SKU версии 2

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

Для SKU версии 1

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

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

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

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

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

Примечание.

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

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

Конечный или серверный сертификат не найден

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

Причина: сертификат конечного объекта (домена или сервера) отсутствует в цепочке сертификатов на внутреннем сервере.

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

Сертификат сервера не выдан общедоступным ЦС

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

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

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

Промежуточный сертификат не подписан общедоступным ЦС.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сообщение: не удалось получить состояние работоспособности серверной части. Это происходит, когда NSG/UDR/Брандмауэр в подсети шлюза приложений блокирует трафик на портах 65503-65534 в случае SKU версии 1, а порты 65200-65535 в случае SKU версии 2 или если полное доменное имя, настроенное в серверном пуле, не удалось разрешить ip-адрес. Дополнительные сведения о посещении - https://aka.ms/UnknownBackendHealth.

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

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

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

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

Application Gateway backend health - Unknown

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

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

Решение.

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

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

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

a. Если у вас есть подключение ExpressRoute/VPN к виртуальной сети через BGP, и если вы рекламируете маршрут по умолчанию, необходимо убедиться, что пакет направляется обратно в место назначения Интернета, не изменяя его. Проверить это можно с помощью параметра Устранение неполадок с подключением на портале Шлюза приложений. b. Выберите назначение вручную, указав любой IP-адрес, поддерживающий маршрутизацию в Интернете, например 1.1.1.1. Задайте любой порт назначения и проверьте подключение. c. Если следующим прыжком является шлюз виртуальной сети, то может существовать маршрут по умолчанию, объявленный через подключение ExpressRoute или VPN.
Если в виртуальной сети настроен пользовательский DNS-сервер, убедитесь, что серверы могут разрешать общедоступные домены. Разрешение имени общедоступного домена может потребоваться в сценариях, когда Шлюз приложений должны обращаться к внешним доменам, таким как серверы OCSP (протокол состояния сертификатов online) или для проверка состояния отзыва сертификата.
Чтобы убедиться, что Шлюз приложений работоспособны и запущены, перейдите к параметру Работоспособность ресурсов на портале и убедитесь, что состояние работоспособно. Если вы видите состояние Неработоспособно или Снижение производительности, обратитесь в службу поддержки.
Если Интернет и частный трафик проходят через Брандмауэр Azure, размещенные в защищенном виртуальном концентраторе (с помощью Центра Azure Виртуальная глобальная сеть):

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

Префикс адреса: 0.0.0.0/0
Определение следующего прыжка. Интернет

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

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

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

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

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

Обзор

Как проверить работоспособность серверной части

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

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

Время ожидания внутреннего сервера

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

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

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

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

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

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

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

Конечный или серверный сертификат не найден

Сертификат сервера не выдан общедоступным ЦС

Промежуточный сертификат не подписан общедоступным ЦС.

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

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

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

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

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

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

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

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

Дополнительные ресурсы