Шлюз приложений Azure: проблема 502 / SNI / SSL?Конфигурация со службой приложений - PullRequest
Новая
       18

Шлюз приложений Azure: проблема 502 / SNI / SSL?Конфигурация со службой приложений

0 голосов
/ 06 декабря 2018

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

Среда:

  • App Gateway v2 (WAF)
  • Служба приложений с настраиваемым доменом
  • Конец 2 Конец SSL

Цели:

  • Управление внешнимSSL-сертификат только для шлюза приложений
  • Самозаверяющий SSL в службе приложений
  • End2End SSL

Настройка:

  • BackendPool настроен на службу приложений (* .azurewebsites.net)
  • FronendIP настроен внешне
  • Пользовательский зонд с заданным внешним именем хоста, Https
  • Прослушиватель SSL с FrontendIp / портом(443), имя хоста и внешний действительный сертификат
  • Импортировал самозаверяющий сертификат (cer) в доверенные корневые органы в шлюзе приложений (powershell)
  • Настройки Http -> Https, порт 443, время ожидания 30, пользовательский зонд, имя хоста установлено на внешний адрес, назначен сертификат TrustedRootCertificate (powershell)
  • Основное правило с SSL listener, бэкэнд-пул, Http-настройка применена (powershell!)
    • Теперь это, вероятно, отталкивает меня, потому что:
      • Powershell говорит, что настройки http-бэкенда применены
      • Портал также говорит об этом на странице «Обзор» правила
      • . Однако при редактировании правила поле «Настройка Http» пустое и красный восклицательный знак:

"Нет настроек http с выбором имени хоста из заданного адреса сервера.Создайте новый параметр http с помощью выбора имени хоста из заданного адреса внутреннего сервера и повторите попытку. "

Однако я не хочу этот параметр, потому что он будет обращаться к фону как" *.azurewebsites.net ", верно? Мне нужен внутренний сервер для доступа к внешнему имени хоста (* .mydomain.com).

Симптомы:

  • Backendработоспособность на портале "Здоровые"
  • Доступ к внешнему имени хоста -> 502 Bad Gateway

У меня это работало с помощью "выбора имени хоста из бэкэнда" и использования имени хоста Azure (*.azurewebsites.net) для внутреннего доступа, к сожалению, нашему приложению действительно нужно внешнее имя (и для контекста: по завершении будет несколько внешних имен, указывающих на одно и то же приложение, и приложение меняет поведение в зависимости от того, какое имя хоста используется)

Дополнительные примечания:

  • Служба приложений настроена с использованием SSL, самозаверяющий сертификат назначается только пользовательскому имени хоста wih "SNI"

Ответы [ 2 ]

0 голосов
/ 13 декабря 2018

Это оказывается побочным эффектом нахождения «V2» в «Предварительном просмотре» (по состоянию на 2018-12-13).Метка «Предварительный просмотр» не сразу видна.Портал Azure ничего не упоминает о том, что он находится в Preview, а во всей Документации говорится о том, что «Autoscale» находится в Preview.

Оказывается, «V2» подразумевается с функцией «Autoscaling», поэтому всеЭлемент «V2» находится в Preview.

Мы заново выполнили ту же настройку с типом шлюза приложения «V1», и он работает, как и ожидалось.

Хотелось бы, чтобы они четко обозначилиПредварительный просмотр вещей на портале тоже ...

0 голосов
/ 12 декабря 2018

Однако при редактировании правила поле «Настройка Http» пустое, и появляется красный восклицательный знак:

Подобный сценарий в Github здесь .Кажется, что WAF_v2 не будет принимать файлы .cer при настройке параметров HTTPS.Когда вы вносите белый список сертификата CER с настройками Http с помощью PowerShell, он не отражается на портале.Возможная причина заключается в том, что шлюз приложения не поддерживает сертификаты аутентификации для уровня WAF_v2.Вы можете прочитать известные проблемы и ограничения в Шлюзе приложений с WAF_v2 и Сквозной конец SSL с SKU v2 .

Если сертификатявляется самоподписанным или подписанным неизвестными посредниками, затем для включения сквозного SSL в SKU v2 должен быть определен доверенный корневой сертификат.Шлюз приложений будет обмениваться данными только с бэкэндами, чей корневой сертификат сертификата сервера соответствует одному из списка доверенных корневых сертификатов в параметре http бэкенда, связанном с пулом.

Помимо соответствия корневого сертификата, шлюз приложений также проверяет, еслиПараметр хоста, указанный в параметре http внутреннего интерфейса, совпадает с параметром общего имени (CN), представленным сертификатом SSL внутреннего сервера.При попытке установить SSL-соединение с бэкендом, Application Gateway устанавливает расширение Показания имени сервера (SNI) на хост, указанный в настройке http бэкенда.

Если выбрать имя хоста из адреса бэкэнда вместо поля «Хост» в настройке http бэкэнда, тогда для заголовка SNI всегда задается полное доменное имя бэкэнд-пула, а CN на сертификате SSL внутреннего сервера должен совпадать с его полным доменным именем.В этом сценарии члены бэкэнд-пула с IP-адресами не поддерживаются.

Об ошибке 502 Bad Gateway, состояние бэкэнда исправно на вашей стороне.Если от ваших бэкэндов нет запроса или ответа брандмауэра о блокировке, я могу предложить проверить ошибку на стороне вашего веб-сервера и убедиться, что бэкэнд отвечает на запрос, отправленный шлюзом приложений, в течение 30 секунд (значение по умолчанию).

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

Надеюсь, это поможет.

...