Остановка веб-сайта IIS по умолчанию вызывает ошибку 502 Bad Gateway в шлюзе приложений Azure для ВСЕХ веб-сайтов в IIS
У меня проблема с размещением нескольких веб-сайтов.NET на Windows Server/IIS и шлюзе приложений Azure.
Мы размещаем несколько сайтов на одной виртуальной машине Azure Windows под управлением IIS, расположенной за шлюзом приложений Azure WAFv2. Виртуальная машина подключается к шлюзу приложений с помощью внутреннего пула, настроенного для указания на частный IP-адрес виртуальной машины, при этом пиринг виртуальных сетей настроен между шлюзом приложений и виртуальными сетями виртуальных машин.
Когда я останавливаю веб-сайт по умолчанию в IIS, ВСЕ веб-сайты затем возвращают ошибку "502 Bad Gateway" из шлюза приложений Azure, а статус работоспособности серверной части меняется на "Неработоспособный" для внутреннего пула, в котором находится виртуальная машина.
Может ли кто-нибудь сказать мне, почему остановка сайта по умолчанию может вызвать ошибку шлюза приложений для всех сайтов?
РЕДАКТИРОВАТЬ:снимок экрана привязок IIS по запросу
РЕДАКТИРОВАТЬ 2: По-видимому, я не могу ответить на свой вопрос, однако, проработав это с нашим CSP, у меня есть ответ. По умолчанию проверка работоспособности серверной части шлюза приложений смотрит на сайт IIS по умолчанию. Если вы остановите это, проверка работоспособности серверной части завершится ошибкой и перейдет в состояние "Неработоспособное". На этом этапе шлюз APP больше не будет даже ПЫТАТЬСЯ на маршрутизацию любых запросов, независимо от URL-адреса этого внутреннего пула.
3 ответа
Нашел ответ на этот вопрос после многих месяцев возни!
В шлюзе приложений Azure по умолчанию проверяется работоспособность для каждого пинга внутреннего пула и ищется ответ на настроенном IP-адресе или полном доменном имени в самом внутреннем пуле.
В моем случае это установлено на локальный IP-адрес виртуальной машины (когда я настраивал это 18–24 месяца назад, я помню, как наш Azure CSP сообщал мне, что произошла ошибка с использованием FQDN в конфигурации внутреннего пула).
Это означает, что когда Health Probe пытается связаться с виртуальной машиной, веб-сайт по умолчанию в IIS - единственное, что настроено для ответа на любые запросы по этому IP-адресу.
Если вы остановите сайт по умолчанию, зонд работоспособности не получит ответа на свои запросы, а статус внутреннего пула перейдет в состояние «Неработоспособно», как и следовало ожидать.
Здесь действительно интересно то, что как только статус подтверждения работоспособности внутреннего пула становится Неработоспособным, шлюз приложений Azure перестает даже пытаться направить любой трафик в затронутый серверный пул. Вместо этого он немедленно сообщает об ошибке 502 Bad Gateway и будет продолжать делать это до тех пор, пока состояние Health Probe не будет исправлено и не вернется в нормальное состояние!
Если на шлюзе приложений нет виртуальных машин или масштабируемого набора виртуальных машин, настроенного в пуле внутренних адресов, он не может маршрутизировать запросы клиентов и отправляет ошибку неверного шлюза. Следуя приведенной ниже команде, вы увидите результат JSON пула внутренних адресов.
Get-AzApplicationGateway -Name "SampleGateway" -ResourceGroupName "ExampleResourceGroup"
Вот официальное руководство по устранению ошибки 502.
https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-troubleshooting-502
Кроме того, вот простое средство устранения неполадок.
https://support.microsoft.com/en-us/help/4504111/azure-application-gateway-with-bad-gateway-502-errors
Если бы я попытался устранить эту неполадку, я бы, вероятно, начал с совершенно нового "тестового" экземпляра IIS и настроил обратный прокси-сервер на порту 80, единственная задача которого - прослушивать входящие запросы на порт 80. Эти запросы тогда будут перенаправляется вашим обратным прокси на ваши реальные веб-сайты, привязанные к разным портам (например, 81, 82, 83 и т. д.).
Идея состоит в том, чтобы все ваши веб-сайты работали на разных портах, чтобы, когда вы останавливаете один из своих сайтов, другие продолжали работать без проблем.
Учитывая вашу настройку, включающую до 40 сайтов, размещенных в одном экземпляре IIS, я бы попытался устранить неполадки этого типа только с совершенно новым "тестовым" экземпляром IIS.
- Создайте новый "тестовый" экземпляр IIS.
- Создайте обратный прокси. Для этого создайте новый сайт и назовите его (например, rev-proxy) и дайте ему привязку к порту 80.
- Разверните один реальный сайт (например, myfirstsite). Дайте ему привязку к порту, отличную от 80 (например, 81).
- Дважды щелкните свой сайт rev-proxy и добавьте URL Rewrite -> Inbound Rules -> Пустое правило. См. Прикрепленное изображение. Добавьте правило, чтобы, когда пользователь запрашивает "myfirstsite", этот запрос пересылается на порт 81. Используйте кнопку "Тестовый шаблон", чтобы проверить свой шаблон. Изображение является всего лишь предложением, и ваш шаблон должен соответствовать URL-адресу, который ваши пользователи используют для запроса вашего сайта, а не обязательно имени, которое вы даете своему сайту в IIS.