Конфигурация параметров HTTP Шлюза приложений Azure
Шлюз приложений направляет трафик на внутренние серверы с помощью указанной здесь конфигурации. После создания параметра HTTP необходимо связать его с одним или несколькими правилами маршрутизации запросов.
Сходство на основе файлов cookie
Шлюз приложений Azure использует управляемые шлюзом файлы cookie для поддержания пользовательских сеансов. Когда пользователь отправляет первый запрос в Шлюз приложений, он задает файл cookie сходства в ответе с хэш-значением, содержащим сведения о сеансе, чтобы последующие запросы, содержащие файлы cookie сходства, перенаправлялись на тот же сервер серверной части для поддержания прилипания.
Эта функция полезна, если необходимо поддерживать сеанс пользователя на том же сервере и сохранить состояние сеанса локально на сервере для сеанса пользователя. Если приложение не может обрабатывать сходство на основе файла cookie, эту функцию использовать нельзя. Для ее использования убедитесь, что клиенты поддерживают файлы cookie.
Примечание.
Некоторые проверки уязвимостей могут пометить файл cookie сходства Шлюз приложений, так как флаги Secure или HttpOnly не заданы. В этих проверках не учитывается, что данные в cookie-файле создаются с использованием одностороннего хэша. Файл cookie не содержит никаких сведений о пользователе и используется исключительно для маршрутизации.
Обновление браузера Chromium версии 80 принесло мандат, в котором HTTP-файлы cookie без атрибута SameSite должны рассматриваться как SameSite=Lax. Для запросов CORS (совместное использование ресурсов между источниками) если файл cookie должен быть отправлен в стороннем контексте, он должен использовать SameSite=None; Безопасные атрибуты и они должны отправляться только по протоколу HTTPS. В противном случае в сценарии только HTTP браузер не отправляет файлы cookie в стороннем контексте. Цель этого обновления Chrome — повышение безопасности и предотвращение атак путем подделки межсайтовых запросов (CSRF).
Для поддержки этого изменения, начиная с 17 февраля 2020 г., в дополнение к существующему файлу cookie ApplicationGatewayAffinity в Шлюзе приложений Azure (все типы SKU) будет добавлен еще один файл cookie с именем ApplicationGatewayAffinityCORS. Файл cookie ApplicationGatewayAffinityCORS имеет два дополнительных атрибута, добавленных в него ("SameSite=None; Secure") таким образом, чтобы липкие сеансы сохранялись даже для запросов между источниками.
Обратите внимание, что имя файла cookie сходства по умолчанию — ApplicationGatewayAffinity, и его можно изменить. Если в топологии сети развернуто несколько шлюзов приложений в строке, необходимо задать уникальные имена файлов cookie для каждого ресурса. Если вы используете пользовательское имя файла cookie сходства, добавляется дополнительный файл cookie с суффиксом CORS
. Например: CustomCookieNameCORS.
Примечание.
Если атрибут SameSite = None установлен, файл cookie обязательно должен содержать флаг Secure, и его необходимо отправлять по протоколу HTTPS. Если для CORS требуется сходство сеансов, необходимо перенести рабочую нагрузку на HTTPS. Ознакомьтесь с документацией по разгрузке TLS и сквозному протоколу TLS для шлюза приложений в следующих статьях: Обзор, Настройка шлюза приложений с завершением TLS с помощью портала Microsoft Azure, Настройка сквозного протокола TLS путем использования шлюза приложений с порталом.
Сток подключений
Очистка подключений помогает корректно удалять члены внутреннего пула во время запланированных обновлений службы. Это относится к экземплярам серверной части, которые являются
- явным образом удален из внутреннего пула или
- сообщается как неработоспособная пробы работоспособности.
Этот параметр можно применить ко всем членам внутреннего пула, включив очистку подключений в параметре серверной части. Это гарантирует, что все экземпляры отмены регистрации в серверном пуле не получают новых запросов и подключений при сохранении существующих подключений до заданного значения времени ожидания. Это также верно для подключений WebSocket.
Тип конфигурации | Значение |
---|---|
Значение по умолчанию, если очистка подключений не включена в параметре серверной части | 30 секунд |
Определяемое пользователем значение при включении очистки подключений в параметре серверной части | От 1 до 3600 секунд |
Единственным исключением из этого являются запросы, связанные с отменой регистрации экземпляров из-за сопоставления сеансов, управляемых шлюзом. Эти запросы продолжают пересылаться в экземпляры отмены регистрации.
Протокол
Шлюз приложений поддерживает http и HTTPS для маршрутизации запросов на внутренние серверы. При выборе HTTP трафик на внутренние серверы незашифрован. Если обмен данными без шифрования неприемлем, выберите HTTPS.
Этот параметр в сочетании с протоколом HTTPS в прослушивателе поддерживает сквозной протокол TLS. Это позволяет безопасно передавать конфиденциальные данные зашифрованными в серверную часть. Каждый сервер серверной части в серверном пуле с включенным сквозным протоколом TLS должен быть настроен с помощью сертификата, чтобы обеспечить безопасное взаимодействие.
Порт
Этот параметр задает порт, в котором серверные серверы прослушивают трафик из шлюза приложений. Можно настроить порты в диапазоне от 1 до 65535.
Доверенный корневой сертификат
При выборе HTTPS в качестве внутреннего протокола Шлюз приложений требуется доверенный корневой сертификат для доверия к внутреннему пулу для сквозного SSL. По умолчанию параметр "Использовать известный сертификат ЦС" имеет значение No. Если вы планируете использовать самозаверяющий сертификат или сертификат, подписанный внутренним центром сертификации, необходимо указать Шлюз приложений соответствующий общедоступный сертификат, используемый серверным пулом. Этот сертификат необходимо передать непосредственно в Шлюз приложений. Формат CER.
Если вы планируете использовать сертификат в серверном пуле, подписанном доверенным общедоступным центром сертификации, можно задать для параметра "Использовать известный сертификат ЦС" значение "Да " и пропускать отправку общедоступного сертификата.
Время ожидания запроса
Этот параметр — это количество секунд, в течение которых шлюз приложений ожидает получения ответа от внутреннего сервера.
Переопределить путь внутреннего сервера
Этот параметр позволяет настроить дополнительный пользовательский путь переадресации, который будет применяться при переадресации запроса в серверную часть. Любая часть входящего пути, соответствующая пользовательскому пути в поле Переопределить путь внутреннего сервера, копируется в перенаправленный путь. В следующей таблице показано, как работает эта функция:
Когда параметр HTTP прикреплен к базовому правилу маршрутизации запросов:
Исходный запрос Переопределить путь внутреннего сервера Запрос перенаправлен в серверную часть /home/ /override/ /override/home/ /home/secondhome/ /override/ /override/home/secondhome/ Когда параметр HTTP прикреплен к правилу маршрутизации запросов на основе пути:
Исходный запрос Правило пути Переопределить путь внутреннего сервера Запрос перенаправлен в серверную часть /pathrule/home/ /pathrule* /override/ /override/home/ /pathrule/home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /home/ /pathrule* /override/ /override/home/ /home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /pathrule/home/ /pathrule/home* /override/ /override/ /pathrule/home/secondhome/ /pathrule/home* /override/ /override/secondhome/ /pathrule/ /pathrule/ /override/ /override/
Использовать пользовательскую пробу
Этот параметр связывает пользовательскую пробу с параметром HTTP. С одним параметром HTTP можно связать только одну пользовательскую пробу. Если пользовательская проба не привязана явно, для мониторинга работоспособности серверной части будет использоваться проба по умолчанию. Рекомендуется создать пользовательскую пробу для улучшения контроля над мониторингом работоспособности серверных частей.
Примечание.
Пользовательская проба не отслеживает работоспособность внутреннего пула, если только соответствующий параметр HTTP явно не связан с прослушивателем.
Настройка имени узла
Шлюз приложений позволяет подключению, установленному к серверной части, использовать другое имя узла, отличное от имени узла, используемого клиентом для подключения к Шлюз приложений. Хотя эта конфигурация может оказаться полезной в некоторых случаях, следует соблюдать осторожность при переопределении имени узла, чтобы оно отличалось от шлюза приложений и клиента по сравнению с целевым объектом серверной части.
В рабочей среде рекомендуется сохранить имя узла, используемое клиентом для шлюза приложений, так же как имя узла, используемое шлюзом приложений для целевого объекта серверной части. Это позволяет избежать потенциальных проблем с абсолютными URL-адресами, URL-адресами перенаправления и файлами cookie, привязанными к узлам.
Прежде чем настроить Шлюз приложений, которые отклоняются от этого, ознакомьтесь с последствиями такой конфигурации, как описано более подробно в Центре архитектуры: сохраните исходное имя узла HTTP между обратным прокси-сервером и его серверным веб-приложением.
Существует два аспекта параметра HTTP, влияющих на Host
заголовок HTTP, используемый Шлюз приложений для подключения к серверной части:
- "Выбор имени узла из серверного адреса"
- "Переопределение имени узла"
Выбор имени узла из внутреннего адреса
Эта возможность динамически задает заголовок узла в запросе на имя узла внутреннего пула. Она использует IP-адрес или полное доменное имя.
Эта функция помогает, когда доменное имя серверной части отличается от DNS-имени шлюза приложений, а серверная часть полагается на конкретный заголовок узла для разрешения в правильную конечную точку.
Например, в качестве серверной части используются службы с несколькими клиентами. Служба приложений — это служба с несколькими клиентами, использующая общее пространство с одним IP-адресом. Таким образом, доступ к службе приложений возможен только через имена узлов, настроенные в параметрах личного домена.
По умолчанию имя личного домена — example.azurewebsites.net. Чтобы получить доступ к службе приложений с помощью шлюза приложений через имя узла, которое не зарегистрировано в службе приложений или через полное доменное имя шлюза приложений, можно переопределить имя узла в исходном запросе на имя узла службы приложений. Для этого включите параметр Выберите имя узла на внутреннем адресе.
Для личного домена, имеющийся пользовательское DNS-имя которого сопоставляется со службой приложений, рекомендуемая конфигурация не включает имя узла выбора из внутреннего адреса.
Примечание.
Этот параметр не является обязательным для среды Службы приложений Azure, которая развертывается отдельно.
Переопределение имени узла
Эта возможность заменяет заголовок host во входящем запросе на шлюзе приложений указанным именем узла.
Например, если www.contoso.com указан в параметре имени узла, исходный запрос * изменяется на *https://appgw.eastus.cloudapp.azure.com/path1
https://www.contoso.com/path1
, когда запрос пересылается на внутренний сервер.