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

Настройка параметров серверной части шлюза приложений

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

Типы параметров серверной части в шлюзе приложений

Хотя пользователи портала увидят только параметр "Параметры серверной части", пользователи API получат доступ к двум типам параметров. В соответствии с протоколом необходимо использовать правильную конфигурацию.

  • Параметры HTTP серверной части — это для конфигураций прокси-сервера уровня 7, поддерживающих протоколы HTTP и HTTPS.
  • Параметры серверной части — это конфигурации прокси-сервера уровня 4 (предварительная версия), поддерживающие протоколы TLS и TCP.

Шлюз приложений Azure использует управляемые шлюзом файлы cookie для поддержания пользовательских сеансов. Когда пользователь отправляет первый запрос шлюзу приложений Application Gateway, он устанавливает 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 для шлюза приложений. Ознакомьтесь с общими сведениями о SSL, настройке шлюза приложений с завершением TLS и настройке сквозного TLS.

Сток подключений

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

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

Тип конфигурации Значение
Значение по умолчанию, если функция поэтапного отключения подключений не включена в настройках серверной части 30 секунд
Определяемое пользователем значение при включении очистки подключений в параметре серверной части От 1 до 3600 секунд

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

Примечание.

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

Протокол

Шлюз приложений поддерживает http и HTTPS для маршрутизации запросов на внутренние серверы. При выборе HTTP трафик на внутренние серверы незашифрован. Если обмен данными без шифрования неприемлем, выберите HTTPS.

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

Порт

Этот параметр задает порт, в котором серверные серверы прослушивают трафик из шлюза приложений. Можно настроить порты в диапазоне от 1 до 65535.

Доверенный корневой сертификат

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

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

Бэкенд параметры проверки HTTPS

При выборе HTTPS в параметрах серверной части шлюза приложений Azure шлюз выполняет полную проверку подтверждения TLS при установке безопасного подключения с внутренними серверами. Эти проверки включают:

  1. Проверка цепочки сертификатов, чтобы убедиться, что сертификат является доверенным.
  2. Проверка имени субъекта сертификата на соответствие идентификатору SNI (индикации имени сервера), отправленному шлюзом приложений.
  3. Проверка срока действия сертификата, чтобы убедиться, что сертификат по-прежнему действителен.

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

Схема, показывающая представление портала элементов управления проверкой TLS, доступных клиентам.

Свойства Ценности
validateCertChainAndExpiry Тип: логическое значение (true или false). Значение по умолчанию — true. Это подтверждает или пропускает как проверку цепочки сертификатов, так и проверку сроку их действия.
validateSNI Тип: логическое значение (true или false). Значение по умолчанию — true. Он проверяет, совпадает ли общее имя сертификата, предоставленного сервером backend, со значением индикации имени сервера (SNI), отправленным шлюзом приложений.
sniName Тип: Строка. Это свойство требуется только в том случае, если параметр validateSNI имеет значение true. Можно указать значение SNI, соответствующее общему имени сертификата на серверной части. По умолчанию шлюз приложений использует заголовок узла входящего запроса в качестве SNI.

Примечание.

  • Рекомендуется сохранять все валидации, включённые в рабочих средах. Отключение некоторых или всех проверок предлагается только для тестирования и разработки, например при использовании самозаверяющих сертификатов.
  • Эти параметры не применяются к функциональности тестовой пробы при добавлении пользовательской пробы контроля работоспособности. В результате вы можете увидеть различия в результатах по сравнению с периодическими пробами работоспособности.
  • В настоящее время неподдерживаемый для прокси-сервера TLS.
  • Поддержка PowerShell и CLI будет предоставлена в ближайшее время.

Время ожидания запроса

Этот параметр — это количество секунд, в течение которых шлюз приложений ожидает получения ответа от внутреннего сервера. Значение по умолчанию — 20 секунд. Однако этот параметр может потребоваться настроить в соответствии с потребностями приложения. Допустимые значения — от 1 секунды до 86400 секунд (24 часа).

Переопределить путь backend

Этот параметр позволяет настроить дополнительный пользовательский путь переадресации, который будет применяться при переадресации запроса в серверную часть. Любая часть входящего пути, соответствующая пользовательскому пути в поле Переопределить путь внутреннего сервера, копируется в перенаправленный путь. В следующей таблице показано, как работает эта функция:

  • Когда параметр HTTP прикреплен к базовому правилу маршрутизации запросов:

    Исходный запрос Переопределить путь backend Запрос перенаправлен в серверную часть
    /дом/ /переопределение/ /override/home/
    /home/secondhome/ /переопределение/ /override/home/secondhome/

  • Когда параметр HTTP прикреплен к правилу маршрутизации запросов на основе пути:

    Исходный запрос Правило пути Переопределить путь backend Запрос перенаправлен в серверную часть
    /pathrule/home/ /pathrule* /переопределение/ /override/home/
    /pathrule/home/secondhome/ /pathrule* /переопределение/ /override/home/secondhome/
    /дом/ /pathrule* /переопределение/ /override/home/
    /home/secondhome/ /pathrule* /переопределение/ /override/home/secondhome/
    /pathrule/home/ /pathrule/дом* /переопределение/ /переопределение/
    /pathrule/home/secondhome/ /pathrule/дом* /переопределение/ /override/secondhome/
    /правило_пути/ /правило_пути/ /переопределение/ /переопределение/

Использовать пользовательский датчик

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

Примечание.

Пользовательская проба не отслеживает работоспособность внутреннего пула, если только соответствующий параметр HTTP явно не связан с прослушивателем.

Настройка имени узла

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

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

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

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

  • "Выбор имени узла из серверного адреса"
  • Переопределение имени узла

Выбор имени узла из серверного адреса

Эта возможность динамически задает заголовок Host в запросе на имя хоста пула серверов бэкенда. Она использует IP-адрес или полное доменное имя.

Эта функция помогает, когда доменное имя серверной части отличается от DNS-имени шлюза приложений, а серверная часть полагается на конкретный заголовок узла для разрешения в правильную конечную точку.

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

По умолчанию имя личного домена — example.azurewebsites.net. Чтобы получить доступ к службе приложений с помощью шлюза приложений через имя узла, которое не зарегистрировано в службе приложений или через полное доменное имя шлюза приложений, можно переопределить имя узла в исходном запросе на имя узла службы приложений. Для этого включите настройку выбрать имя узла из адреса серверной части.

Для пользовательского домена, существующее пользовательское DNS-имя которого сопоставляется со службой приложений, рекомендуемая конфигурация не включает выбор имени узла из адреса бэкенда.

Примечание.

Этот параметр не требуется для среды службы приложений, которая является выделенным развертыванием.

Переопределение имени узла

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

Например, если www.contoso.com задано в параметре имени узла , исходный запрос *https://appgw.eastus.cloudapp.azure.com/path1 изменяется на *https://www.contoso.com/path1 , когда запрос перенаправляется на внутренний сервер.

Выделенное бэкенд-подключение

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

Снимок экрана: сетевой поток через прокси-сервер уровня 7 шлюза приложений.

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

Примечание.

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

Это важно

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

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

Выделенное внутреннее подключение не поддерживается с протоколом HTTP/2.

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

  • Last updated on