Предыдущий

Следующая

Планирование и реализация Шлюза приложений Azure

Завершено

Шлюз приложений Azure – это балансировщик нагрузки веб-трафика (уровень 7 в модели OSI), позволяющий управлять трафиком ваших веб-приложений. Традиционные подсистемы балансировки нагрузки работают на транспортном уровне (уровень 4 OSI — протоколы TCP и UDP) и маршрутизируют трафик к IP-адресу и порту назначения в зависимости от исходного IP-адреса и порта.

Шлюза приложений умеет принимать решения о маршрутизации на основе дополнительных атрибутов HTTP-запроса, например пути URI или заголовков узла. Например, вы можете маршрутизировать трафик на основе входящего URL-адреса. Таким образом, если во входящем URL-адресе есть элемент /images, вы можете направлять трафик к определенной группе (пулу) серверов, настроенных для изображений. Если в URL-адресе есть элемент /video, этот трафик направляется в другой пул, оптимизированный для видео.

Этот тип маршрутизации называется балансировкой нагрузки на уровне приложения (уровень 7 OSI). Шлюз приложений Azure может выполнять маршрутизацию на основе URL-адреса и многие другие действия.

Компоненты шлюза приложений

Шлюз приложений выступает в качестве единой точки контакта для клиентов. Он распределяет входящий трафик приложений между несколькими внутренними пулами, включая виртуальные машины Azure, масштабируемые наборы виртуальных машин, Службу приложений Azure, а также локальные и внешние серверы.

Инфраструктура

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

Интерфейсный IP-адрес

Вы можете настроить Шлюз приложений таким образом, чтобы он использовал общедоступный IP-адрес и (или) частный IP-адрес. Общедоступный IP-адрес нужен для размещения внутренней части, к которой клиенты будут обращаться через Интернет по виртуальному IP-адресу с выходом в Интернет.

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

Поддерживаются только один общедоступный IP-адрес и один частный IP-адрес. При создании шлюза приложений вы выбираете внешний IP-адрес.

Примечание.

Интерфейс Шлюз приложений поддерживает IP-адреса с двумя стеками (общедоступная предварительная версия). Вы можете создать до четырех интерфейсных IP-адресов. Два — IPv4-адреса (общедоступные и частные), а два — IPv6-адреса (общедоступные и частные).

• Если вы предпочитаете общедоступный IP-адрес, можно создать новый или использовать тот, который уже существует в том же расположении, что и шлюз приложений. Дополнительные сведения см. в статье "Статический и динамический общедоступный IP-адрес".
• В качестве частного IP-адреса можно указать любой адрес из подсети, в которой создан шлюз приложений. Для развертываний SKU версии 2 Шлюз приложений статический IP-адрес необходимо определить при добавлении частного IP-адреса в шлюз. При развертывании SKU версии Шлюз приложений версии 1, если не указать IP-адрес, из подсети автоматически выбирается доступный IP-адрес. Выбранный тип IP-адреса (статический или динамический) нельзя изменить позже.

Внешний IP-адрес связан с прослушивателем, который проверка для входящих запросов на интерфейсном IP-адресе.

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

Правило для входящего трафика:

• Источник: в соответствии с вашим требованием
  
• Назначение: общедоступные и частные IP-адреса шлюза приложений.
• Порт назначения: в соответствии с настроенными прослушивателями
• Протокол: TCP

Правило исходящего трафика: нет определенного требования

Прослушиватели

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

При создании шлюза приложений с помощью портала Azure также создается прослушиватель по умолчанию, который выбирает протокол и порт для прослушивателя. По желанию для прослушивателя можно включить поддержку HTTP2. После создания шлюза приложений можно изменить параметры этого прослушивателя по умолчанию (appGatewayHttpListener) или создать новые прослушиватели.

Тип прослушивателя

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

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

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

Прослушиватели поддерживают следующие порты и протоколы.

Порты

Порт — это место, в котором прослушиватель прослушивает запрос клиента. Вы можете настроить порты для номеров SKU версии 1 и версии 2, как показано ниже.

SKU	Поддерживаемый диапазон портов	Исключения
V2	От 1 до 64999	22
V1	От 1 до 65502	3389

Протоколы

Шлюз приложений поддерживает протоколы HTTP, HTTPS, HTTP/2 и WebSocket.

Примечание.

Поддержка протокола HTTP/2 доступна только для клиентов, подключающихся к прослушивателям шлюза приложений. Подключение к внутренним пулам серверов осуществляется по протоколу HTTP/1.1. Поддержка HTTP/2 отключена по умолчанию. Тут можно его включить.

• Укажите между протоколами HTTP и HTTPS в конфигурации прослушивателя.
• Поддержка WebSockets и протоколов HTTP/2 предоставляется нативно. По умолчанию включена WebSocket. Настраиваемый пользователем параметр для выборочного включения или отключения поддержки WebSocket отсутствует. Используйте сокеты WebSocket с прослушивателями HTTP и HTTPS.

Используйте прослушиватель HTTPS для завершения сеанса TLS. Прослушиватель HTTPS разгружает работу по шифрованию и расшифровке для шлюза приложений, поэтому веб-серверы не перегружаются.

Правила маршрутизации запросов

При создании шлюза приложений с помощью портала Azure создается правило по умолчанию (rule1). Это правило привязывает прослушиватель по умолчанию (appGatewayHttpListener) с серверным пулом по умолчанию (appGatewayBackendPool) и параметрами HTTP серверной части по умолчанию (appGatewayBackendHttp Параметры). После создания шлюза можно изменить параметры правила по умолчанию или создать новые правила.

Тип правила

При создании правила необходимо выбрать его тип (базовый или на основе пути).

• Выберите базовый вариант, если вы хотите перенаправлять все запросы на связанный прослушиватель (например, blog.contoso.com/*) в один внутренний пул.
  
• Выберите путь на основе пути, если вы хотите маршрутизировать запросы из определенных ПУТЕЙ URL-адресов в определенные серверные пулы. Шаблон пути применяется только к пути URL-адреса, а не к его параметрам запроса.

Связанный прослушиватель

Свяжите прослушиватель с правилом, чтобы правило маршрутизации запросов, связанное с прослушивателем, вычислялось, чтобы определить серверный пул для маршрутизации запроса.

Связанный серверный пул

Свяжите правило с серверным пулом, который содержит целевые объекты серверной части, обслуживающие запросы, получаемые прослушивателем.

• Для базового правила допускается только один внутренний пул. Все запросы связанного прослушивателя перенаправляются в этот внутренний пул.
  
• Для правила на основе пути добавьте несколько внутренних пулов, соответствующих каждому URL-пути. Запросы, соответствующие заданному URL-пути, перенаправляются в соответствующий внутренний пул. Кроме того, добавьте внутренний пул по умолчанию. Запросы, которые не соответствуют ни одному из URL-путей в правиле, будут перенаправляться в этот пул.
  

Связанный параметр HTTP серверной части

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

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

Для правила на основе пути добавьте несколько параметров HTTP серверной части, соответствующих каждому URL-пути. Запросы, соответствующие URL-пути в этом параметре, перенаправляются в соответствующие целевые объекты серверной части с помощью параметров HTTP, соответствующих каждому URL-пути. Кроме того, добавьте параметр HTTP по умолчанию. Запросы, которые не соответствуют ни одному URL-пути в этом правиле, перенаправляются в внутренний пул по умолчанию с помощью параметра HTTP по умолчанию.

Параметр перенаправления

Если для базового правила настроено перенаправление, все запросы к связанному прослушивателю перенаправляются на целевой объект. Это глобальное перенаправление. Если перенаправление настроено для правила на основе пути, перенаправляются только запросы в определенной области сайта. Примером является область корзины для покупок, которая обозначается /cart/*. Это перенаправление на основе пути.

Средство прослушивания

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

Внешний сайт

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

Перезапись заголовков HTTP и URL-адреса

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

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

Параметры HTTP

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

Сходство на основе файлов cookie

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

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

Примечание.

Некоторые проверки уязвимостей могут пометить файл cookie сходства Шлюз приложений, так как флаги Secure или HttpOnly не заданы. В этих проверках не учитывается, что данные в cookie-файле создаются с использованием одностороннего хэша. Файл cookie не содержит никаких сведений о пользователе и используется исключительно для маршрутизации.

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

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

• явным образом удален из внутреннего пула,
  
• удален во время операций масштабирования или
• сообщается как неработоспособная пробы работоспособности.

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

Тип конфигурации	Value
Значение по умолчанию, если очистка Подключение ion не включена в параметре серверной части	30 секунд
Определяемое пользователем значение при включении очистки Подключение ion в параметре серверной части	От 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, влияющих на заголовок HTTP узла, используемый Шлюз приложений для подключения к серверной части:

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

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

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

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

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

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

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

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

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

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

Внутренний пул

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

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

Зонды работоспособности

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

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

Поведение проб

Исходный IP-адрес

Исходный IP-адрес проб зависит от типа серверного сервера:

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

Операции пробы

Шлюз запускает пробы сразу после настройки правила, связав его с серверным параметром и серверным пулом (и прослушивателем, конечно). На рисунке показано, что шлюз независимо проверяет все серверы внутреннего пула. Входящие запросы, которые начинают поступать, отправляются только на здоровые серверы. Сервер серверной части по умолчанию помечается как неработоспособный до получения успешного ответа пробы.

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

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

Примечание.

Отчет о работоспособности серверной части обновляется на основе интервала обновления соответствующей пробы и не зависит от запроса пользователя.

Проверка работоспособности по умолчанию

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

Например, вы настраиваете шлюз приложений для использования внутренних серверов A, B и C для получения сетевого трафика HTTP через порт 80. Мониторинг работоспособности по умолчанию проверяет три сервера каждые 30 секунд для работоспособного HTTP-ответа с 30-секундным тайм-аутом для каждого запроса. HTTP-ответ, подтверждающий работоспособность, имеет код состояния от 200 до 399. В этом случае http-запрос GET для пробы работоспособности выглядит следующим http://127.0.0.1/образом. Также см. коды http-ответов в Шлюз приложений.

Если проба работоспособности по умолчанию для сервера А завершается сбоем, шлюз приложений перестает пересылать запросы на этот сервер. Проверка работоспособности по умолчанию по-прежнему продолжает проверять сервер A каждые 30 секунд. Когда сервер A успешно отвечает на запрос пробы работоспособности по умолчанию, шлюз приложений снова начинает пересылать запросы на этот сервер.

Параметры проверки работоспособности по умолчанию

Свойство Пробы	Value	Description
URL-адрес проверки	<protocol>://127.0.0.1:<port>/	Протокол и порт берутся из параметров HTTP серверной части, с которыми связана проба.
Интервал	30	Количество времени (в секундах) ожидания перед отправкой следующей пробы работоспособности.
Время ожидания	30	Количество времени (в секундах), в течение которого Шлюз приложений ожидает ответа пробы, прежде чем пометить ее как неработоспособную. Если проба возвращается как работоспособная, соответствующая серверная часть сразу же обозначается как работоспособная.
Порог состояния неработоспособности	3	Управляет количеством проб, которые нужно отправить в случае сбоя стандартной пробы работоспособности. В версии 1 SKU эти дополнительные пробы работоспособности отправляются быстро и последовательно, чтобы оперативно определить работоспособность серверной части, не дожидаясь интервала пробы. Для SKU версии 2 пробы работоспособности ожидают интервала. Сервер серверной части помечается после того, как число последовательных сбоев пробы достигает порогового значения неработоспособного.

Проба по умолчанию смотрит только на <протокол>://127.0.0.1:<port> для определения состояния работоспособности. Если необходимо настроить пробу работоспособности для перехода на настраиваемый URL-адрес или изменить любые другие параметры, используйте пользовательские пробы.

Пользовательская проверка работоспособности

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

Параметры пользовательской проверки работоспособности

В следующей таблице приведены описания свойств из пользовательской пробы работоспособности.

Свойство Пробы	Description
Имя.	Имя проверки. Это имя используется для идентификации и ссылки на пробу в параметрах HTTP серверной части.
Протокол	Протокол, используемый для проверки. Это должен соответствовать протоколу, определенному в параметрах HTTP серверной части, с которыми он связан.
Хост	Имя узла, на который отправляется проба. В номере SKU версии 1 это значение используется только для заголовка узла запроса пробы. В SKU версии 2 он используется как заголовок узла, так и SNI
Путь	Относительный путь проверки. Путь должен начинаться с "/".
Порт	Если этот параметр задан, он используется в качестве порта назначения. В противном случае он использует тот же порт, что и параметры HTTP, с которыми он связан. Это свойство доступно только в версии 2 SKU.
Интервал	Интервал проверки в секундах. Это значение означает интервал времени между двумя последовательными пробами.
Время ожидания	Время ожидания проверки в секундах. Если ответ о работоспособности не получен в течение этого времени ожидания, то проба считается неудачной.
Порог состояния неработоспособности	Количество повторных попыток проверки. Сервер серверной части помечается после того, как число последовательных сбоев пробы достигает порогового значения неработоспособного значения.

Соответствие проб

По умолчанию ответ HTTP(S) с кодом состояния 200–399 указывает на работоспособность. Настраиваемые пробы работоспособности поддерживают два критерия соответствия. Критерий соответствия можно использовать, чтобы дополнительно изменить стандартную интерпретацию содержимого ответа, указывающего на работоспособность.

Эти критерии соответствия приведены ниже.

• Соответствие кода состояния ответа HTTP. Критерий соответствия пробы для приема определенного пользователем отдельного кода ответа HTTP или их диапазонов. Поддерживаются отдельные коды состояния ответа, разделенные запятыми, и диапазоны кодов состояния.
  
• Соответствие текста ответа HTTP. Критерий соответствия пробы, позволяющий проверять текст ответа HTTP и сопоставлять его с указанной пользователем строкой. Возможен только поиск указанной пользователем строки в тексте ответа, но не полного регулярного выражения. Указанное совпадение должно иметь 4090 символов или меньше.

Критерий соответствия можно задать с помощью командлета New-AzApplicationGatewayProbeHealthResponseMatch.

Пример.

Azure PowerShell

$match = New-AzApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399

$match = New-AzApplicationGatewayProbeHealthResponseMatch -Body "Healthy"

Критерии соответствия можно подключить к конфигурации пробы с помощью -Match оператора в PowerShell.

Варианты использования пользовательской пробы

• Если сервер серверного сервера разрешает доступ только к прошедшим проверку подлинности пользователям, пробы шлюза приложений получат код ответа 403 вместо 200. Так как клиенты (пользователи) привязаны к проверке подлинности для динамического трафика, можно настроить трафик пробы, чтобы принять 403 в качестве ожидаемого ответа.
• Если внутренний сервер имеет дикий сертификат карта (*.contoso.com) для обслуживания разных поддоменов, можно использовать пользовательскую пробу с определенным именем узла (требуется для SNI), который принимается для установки успешной проверки TLS и сообщить о том, что сервер работает как работоспособный. При переопределении имени узла в параметре серверной части задано значение NO, разные входящие имена узлов (поддомены) передаются в серверную часть.

Рекомендации по группе безопасности сети (NSG)

Точный контроль над подсетью Шлюз приложений через правила NSG можно использовать в общедоступной предварительной версии. Дополнительные сведения можно найти здесь.

При использовании текущих функциональных возможностей существуют некоторые ограничения:

Необходимо разрешить входящий трафик Интернета через TCP-порты 65503–65534 для номера SKU шлюза приложений версии 1, а также через TCP-порты 65200–65535 для номера SKU версии 2 с целевой подсетью Любая и источником GatewayManager (тег службы источника). Такой диапазон портов требуется для обмена данными в рамках инфраструктуры Azure.

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

Принцип работы шлюза приложений

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

1. Прежде чем клиент отправит запрос к шлюзу приложений, он разрешает доменное имя шлюза приложений с помощью сервера службы доменных имен (DNS). Azure управляет записью DNS, так как все шлюзы приложений находятся в домене azure.com.
2. Azure DNS возвращает IP-адрес клиенту, который является интерфейсным IP-адресом шлюза приложений.
   
3. Шлюз приложений принимает входящий трафик одного или нескольких прослушивателей. Прослушиватель — это логическая сущность, которая проверяет наличие запросов на подключение. Он настроен с использованием внешнего IP-адреса, протокола и номера порта для подключений клиентов к шлюзу приложений.
   
4. Если используется брандмауэр веб-приложения (WAF), шлюз приложений проверяет заголовки запросов и текст, если они есть, в соответствии с правилами WAF. Это действие определяет, является ли запрос допустимым или он представляет угрозу безопасности. Если запрос является допустимым, он направляется в серверную часть. Если запрос является недопустимым и WAF находится в режиме предотвращения, он блокируется как угроза безопасности. Если он находится в режиме обнаружения, запрос оценивается и заносится в журнал, но по-прежнему пересылается на внутренний сервер.
   

Шлюз приложений Azure можно использовать как внутреннюю подсистему балансировки нагрузки приложений или как подсистему балансировки нагрузки приложений для Интернета. Шлюз приложений с выходом в Интернет использует общедоступные IP-адреса. DNS-имя шлюза приложений с выходом в Интернет разрешается в общедоступный IP-адрес. В результате шлюзы приложений с выходом в Интернет могут маршрутизировать клиентские запросы из Интернета.

Внутренние шлюзы приложений используют только частные IP-адреса. Если вы используете пользовательскую или Частная зона DNS зону, доменное имя должно быть внутренне разрешаемым для частного IP-адреса Шлюз приложений. Поэтому внутренние подсистемы балансировки нагрузки могут маршрутизировать запросы только от клиентов с доступом к виртуальной сети для шлюза приложений.

Как шлюз приложений направляет запрос

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

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

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

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

Порт и протокол, используемые в параметрах HTTP, определяют, шифруется ли трафик между шлюзом приложений и внутренними серверами (выполняя сквозное шифрование TLS) или не шифруется.

Примечание.

Правила обрабатываются в том порядке, в котором они указаны на портале для SKU версии 1.

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

Если внутренний пул:

• Является общедоступной конечной точкой, шлюз приложений использует его интерфейсный общедоступный IP-адрес для доступа к серверу. Если общедоступный IP-адрес внешнего интерфейса отсутствует, он назначается для исходящих внешних подключений.
• Содержит внутренне разрешаемое полное доменное имя или частный IP-адрес, шлюз приложений направляет запрос на внутренний сервер с помощью его частных IP-адресов.
• Содержит внешнюю конечную точку или внешнее разрешаемое полное доменное имя, шлюз приложений направляет запрос на внутренний сервер с помощью его внешнего общедоступного IP-адреса. Если подсеть содержит конечные точки службы, шлюз приложений перенаправит запрос в службу через частный IP-адрес. Разрешение DNS основано на частной зоне DNS или пользовательском DNS-сервере, если он настроен, или использует dns, предоставленный по умолчанию. Если общедоступный IP-адрес внешнего интерфейса отсутствует, он назначается для исходящих внешних подключений.

Разрешение DNS серверного сервера

Если сервер внутреннего пула настроен с полным доменным именем (FQDN), Шлюз приложений выполняет поиск DNS для получения IP-адресов доменного имени. Значение IP-адреса хранится в кэше шлюза приложений, чтобы обеспечить доступ к целевым объектам быстрее при обслуживании входящих запросов.

Шлюз приложений сохраняет эти кэшированные сведения в течение периода, эквивалентного сроку жизни записи DNS (время жизни) и выполняет свежий поиск DNS после истечения срока действия TTL. Если шлюз обнаруживает изменение IP-адреса для последующего DNS-запроса, он начнет маршрутизацию трафика в это обновленное место назначения. В случае проблем, таких как поиск DNS, не удалось получить ответ или запись больше не существует, шлюз продолжает использовать последний известный IP-адрес(es). Это обеспечивает минимальное влияние на путь к данным.

• При использовании пользовательских DNS-серверов с виртуальная сеть Шлюз приложений крайне важно, чтобы все серверы были идентичными и отвечают согласованно с одинаковыми значениями DNS.
• Пользователи локальных пользовательских DNS-серверов должны обеспечить подключение к Azure DNS через частный сопоставитель Azure DNS (рекомендуется) или виртуальную машину пересылки DNS при использовании зоны Частная зона DNS для частной конечной точки.

Изменения в запросе

Шлюз приложений вставляет шесть дополнительных заголовков ко всем запросам, прежде чем пересылать запросы на серверную часть. Эти заголовки : x-forwarded-for, x-forwarded-port, x-forwarded-proto, x-original-host, x-original-url и x-appgw-trace-id. Формат заголовка x-forwarded-for — это разделенный запятыми список IP:port.

Допустимые значения для заголовка X-Forwarded-Proto — HTTP или HTTPS. Заголовок X-Forwarded-Port указывает порт, в котором запрос достигает шлюза приложений. Заголовок x-original-host содержит исходный заголовок узла, с которым поступил запрос. Этот заголовок полезен в случае интеграции веб-сайта Azure, при которой заголовок узла входящих запросов изменяется, прежде чем трафик направляется к серверной части. Если сходство сеансов включено в качестве варианта, то добавляется файл cookie сходства, управляемый шлюзом.

X-appgw-trace-id — это уникальный guid, созданный шлюзом приложений для каждого клиентского запроса и представленный в переадресованном запросе в член внутреннего пула. Guid состоит из 32 буквенно-цифровых символов, представленных без дефисов (например, ac882cd65a2712a0fe1289ec2bb6aee7). Этот guid можно использовать для сопоставления запроса, полученного шлюзом приложений и инициированного членом внутреннего пула с помощью свойства transactionId в журналах диагностики.

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

Продолжить