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

Устранение распространенных проблем с Azure Front Door

  • Статья

В данной статье описывается, как устранять распространенные проблемы маршрутизации, с которыми вы можете столкнуться в конфигурации Azure Front Door.

Другие отладочные заголовки HTTP

Вы можете запросить Azure Front Door для возврата дополнительных заголовков ответов HTTP для отладки. Подробные сведения см. в статье о необязательных заголовках ответов.

Ответ 503 или 504 из Azure Front Door через несколько секунд

Симптом

  • Регулярные запросы, отправляемые на серверную часть без прохождения через входную дверь Azure, выполняются успешно. Прохождение Через Azure Front Door приводит к 503 или 504 ответам на ошибки.
  • Как правило, ошибка Azure Front Door появляется примерно через 30 секунд.
  • Периодические ошибки типа 503 отображаются с сообщением "ErrorInfo: OriginInvalidResponse".

Причина

Причина этой проблемы может быть одной из трех вещей:

  • Чтобы получить запрос от Azure Front Door, вашему источнику требуется больше времени, чем настроенное время ожидания. По умолчанию время ожидания составляет 30 секунд.
  • Время, необходимое для отправки ответа на запрос от входной двери Azure, превышает значение времени ожидания.
  • Клиент отправил запрос диапазона байтов с заголовком Accept-Encoding. Это означает, что включено сжатие.

Действия по устранению неполадок

  • Отправьте запрос в источник напрямую, не перейдя через Azure Front Door. Узнайте, сколько времени обычно занимает источник ответа.

  • Отправьте запрос через Azure Front Door и убедитесь, что вы получаете ответы 503. В противном случае проблема может быть не во времени ожидания. Создайте запрос на поддержку для дальнейшего устранения проблемы.

  • Если запросы, выполняемые через Azure Front Door, приводят к коду ответа на ошибку 503, настройте время ожидания ответа Источника для Azure Front Door. Вы можете увеличить используемое по умолчанию время ожидания до 4 минут (240 секунд). Чтобы настроить этот параметр, перейдите на страницу обзора профиля Front Door. Выберите Время ожидания отклика источника и введите значение от 16 до 240 секунд.

    Примечание.

    Возможность настройки времени ожидания ответа Источника доступна только в Azure Front Door уровня "Стандартный" или "Премиум".

    Снимок экрана: параметры времени ожидания источника на странице обзора профиля Azure Front Door.

  • Если увеличение времени ожидания не устраняет проблему, используйте средство, например Fiddler или средство разработчика браузера, чтобы проверить, отправляет ли клиент запросы диапазона байтов с заголовками Accept-Encoding . Из-за этого параметра источник отправляет ответы с разной длиной содержимого.

    Если клиент отправляет запросы диапазона байтов с заголовками Accept-Encoding, у вас есть два варианта. Первым вариантом является отключение сжатия в Origin или Azure Front Door. Второй вариант — создать правило набора правил для удаления Accept-Encoding из запроса на запросы диапазона байтов.

    Снимок экрана: правило Accept-Encoding в наборе правил.

Ответы типа 503 от Azure Front Door только для HTTPS

Симптом

  • Все ответы 503 возвращаются только для конечных точек Azure Front Door с поддержкой HTTPS.
  • Регулярные запросы, отправляемые на серверную часть без прохождения через входную дверь Azure, выполняются успешно. Переход через входную дверь Azure приводит к сообщениям об ошибках типа 503.
  • Периодические ошибки типа 503 отображаются с сообщением "ErrorInfo: OriginInvalidResponse".

Причина

Причин данной проблемы может быть три:

  • Серверный пул — это IP-адрес.
  • Серверный сервер возвращает сертификат, который не соответствует полному доменному имени (FQDN) внутреннего пула Azure Front Door.
  • Серверный пул — это сервер веб-приложений Azure.

Действия по устранению неполадок

  • Серверный пул — это IP-адрес.

    EnforceCertificateNameCheck должен быть отключен.

    У Azure Front Door есть коммутатор с именем EnforceCertificateNameCheck. По умолчанию эта настройка включена. При включении Azure Front Door проверяет, совпадает ли имя узла серверного пула с именем сертификата внутреннего сервера или одной из записей в расширении альтернативных имен субъектов.

    • Чтобы отключить EnforceCertificateNameCheck на портале Azure, сделайте следующее:

      На портале с помощью выключателя включите или выключите этот параметра на панели Проект Azure Front Door (классическая версия).

      Снимок экрана: кнопка переключателя.

      В Azure Front Door уровня "Стандартный" и "Премиум" этот параметр можно найти в настройках источника при добавлении источника в группу источников или при конфигурации маршрута.

      Снимок экрана: флажок проверки имени субъекта сертификата.

  • Внутренний сервер возвращает сертификат, который не соответствует полному доменному имени серверного пула Azure Front Door. Есть два способа решения этой проблемы:

    • Возвращенный сертификат должен соответствовать полному доменному имени.
    • EnforceCertificateNameCheck должен быть отключен.

  • Серверный пул — это сервер веб-приложений Azure.

    • Проверьте, настроено ли веб-приложение Azure с использованием SSL на основе IP-адресов, а не на основе SNI (указание имени сервера). Если настройка выполнена на основе IP-адреса, его следует изменить на SNI.
    • Если внутренний сервер не работает из-за сбоя сертификата, возвращается сообщение об ошибке типа 503. Вы можете проверить работоспособность внутренних серверов на портах 80 и 443. Если порт 443 не работает, проблема, скорее всего, заключается в SSL. Так как внутренний сервер настроен на использование полного доменного имени, мы понимаем, что он отправляет SNI.

    С помощью OPENSSL проверьте возвращаемый сертификат. Для этого подключитесь к внутреннему серверу с помощью -servername. Он должен возвращать SNI, который соответствует полному доменному имени серверного пула:

    openssl s_client -connect backendvm.contoso.com:443 -servername backendvm.contoso.com

Запросы, отправленные в личный домен, возвращают код состояния 400

Симптом

  • Вы создали экземпляр Azure Front Door. Запрос к домену или интерфейсному узлу возвращает код состояния HTTP 400.
  • Вы создали сопоставление DNS (сервера доменных имен) для личного домена с настроенным интерфейсным узлом. При отправке запроса на имя хоста личного домена возвращается код состояния HTTP 400. Похоже, что запрос не направляется к настроенной вами внутренней службе.

Причина

Проблема возникает, если вы не настроили правило маршрутизации для пользовательского домена, который был добавлен в качестве внешнего хоста. Для данного внешнего хоста необходимо явным образом добавить правило маршрутизации. Необходимо создать правило, даже если правило маршрутизации уже настроено для внешнего узла в поддомене Azure Front Door, которое равно *.azurefd.net.

Действие по устранению неполадок

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

Служба Azure Front Door не перенаправляет HTTP на HTTPS

Симптом

У Azure Front Door есть правило маршрутизации, которое перенаправляет HTTP на HTTPS, но доступ к домену по-прежнему поддерживает HTTP в качестве протокола.

Причина

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

Действия по устранению неполадок

Запрос к имени хоста внешнего интерфейса возвращает код состояния 411

Симптом

Вы создали экземпляр Azure Front Door уровня "Стандартный" или "Премиум" и настроили:

  • узел внешнего интерфейса;
  • группу источников, где есть по крайней мере один источник;
  • правило маршрутизации, которое подключает узел внешнего интерфейса к группе источников.

Ваше содержимое кажется недоступным, когда запрос отправляется на настроенный интерфейсный хост, потому что возвращается код состояния HTTP 411.

Ответы на такие запросы также могут содержать HTML-страницу ошибки с пояснительной инструкцией. Пример ошибки: HTTP Error 411. The request must be chunked or have a content length (Ошибка HTTP 411. Запрос должен быть разделен на блоки или ограничен по длине).

Причина

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

Примером несоответствия выступает запрос POST, отправленный без заголовка Content-Length или Transfer-Encoding. Пример: curl -X POST https://example-front-door.domain.com. Данный запрос не соответствует требованиям, изложенным в RFC 7230. Azure Front Door заблокирует запрос посредством ответа HTTP 411. Такие запросы не регистрируются.

Подобный алгоритм действий отличается от функциональности брандмауэра веб-приложения (WAF) в Azure Front Door. В настоящее время отключить это поведение невозможно. Все HTTP-запросы должны соответствовать требованиям, даже если функция WAF не используется.

Действия по устранению неполадок

  • Убедитесь, что ваши запросы соответствуют требованиям, изложенным в необходимых RFC.
  • Запишите любой текст HTML-сообщения, возвращаемый в ответ на запрос. Текст сообщения часто объясняет, почему запрос не соответствует требованиям.

Мой источник настроен как IP-адрес.

Симптом

Источник настраивается в качестве IP-адреса. Источник работоспособен, но отклоняет запросы из Azure Front Door.

Причина

Azure Front Door использует имя узла источника в качестве заголовка SNI во время подтверждения SSL. Так как источник настроен в качестве IP-адреса, сбой может быть одной из следующих причин:

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

Действия по устранению неполадок

Измените источник из IP-адреса на полное доменное имя, на которое выдан действительный сертификат, соответствующий сертификату источника.

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