Принцип работы шлюза приложений
В этой статье объясняется, как шлюз приложений принимает входящие запросы и направляет их в серверную часть.
Как шлюз приложений принимает запрос
Прежде чем клиент отправит запрос к шлюзу приложений, он разрешает доменное имя шлюза приложений с помощью сервера службы доменных имен (DNS). Azure управляет записью DNS, так как все шлюзы приложений находятся в домене azure.com.
Azure DNS возвращает IP-адрес клиенту, который является интерфейсным IP-адресом шлюза приложений.
Шлюз приложений принимает входящий трафик одного или нескольких прослушивателей. Прослушиватель — это логическая сущность, которая проверяет наличие запросов на подключение. Он настроен с использованием внешнего IP-адреса, протокола и номера порта для подключений клиентов к шлюзу приложений.
Если используется брандмауэр веб-приложения (WAF), шлюз приложений проверяет заголовки запросов и текст, если они есть, в соответствии с правилами WAF. Это действие определяет, является ли запрос допустимым или он представляет угрозу безопасности. Если запрос является допустимым, он направляется в серверную часть. Если запрос является недопустимым и WAF находится в режиме предотвращения, он блокируется как угроза безопасности. Если он находится в режиме обнаружения, запрос оценивается и заносится в журнал, но по-прежнему пересылается на внутренний сервер.
Шлюз приложений Azure можно использовать как внутреннюю подсистему балансировки нагрузки приложений или как подсистему балансировки нагрузки приложений для Интернета. Шлюз приложений с выходом в Интернет использует общедоступные IP-адреса. DNS-имя шлюза приложений с выходом в Интернет разрешается в общедоступный IP-адрес. В результате шлюзы приложений с выходом в Интернет могут маршрутизировать клиентские запросы из Интернета.
Внутренние шлюзы приложений используют только частные IP-адреса. Если вы используете пользовательскую или Частная зона DNS зону, доменное имя должно быть внутренне разрешаемым для частного IP-адреса Шлюз приложений. Поэтому внутренние подсистемы балансировки нагрузки могут маршрутизировать запросы только от клиентов с доступом к виртуальной сети для шлюза приложений.
Как шлюз приложений направляет запрос
Если запрос является допустимым и не заблокирован WAF, шлюз приложений оценивает правило маршрутизации запросов, связанное с прослушивателем. Это действие определяет, в какой серверный пул следует направить запрос.
На основе правила маршрутизации запросов шлюз приложений определяет, следует ли перенаправлять все запросы к прослушивателю на определенный серверный пул, маршрутизировать запросы к различным внутренним пулам на основе пути URL-адреса или перенаправлять запросы на другой порт или внешний сайт.
Примечание.
Правила обрабатываются в том порядке, в котором они указаны на портале для SKU версии 1.
Когда шлюз приложений выбирает серверный пул, он отправляет запрос в один из работоспособных внутренних серверов в пуле (y.y.y.y). Работоспособность сервера определяется пробой работоспособности. Если внутренний пул содержит несколько серверов, шлюз приложений использует алгоритм циклического перебора для маршрутизации запросов между работоспособными серверами. Эта нагрузка распределяет запросы на серверах.
После того как шлюз приложений определит внутренний сервер, он откроет новый сеанс TCP с внутренним сервером на основе параметров HTTP. Параметры HTTP указывают протокол, порт и другие параметры, связанные с маршрутизацией, необходимые для создания нового сеанса с внутренним сервером.
Порт и протокол, используемые в параметрах HTTP, определяют, шифруется ли трафик между шлюзом приложений и внутренними серверами (выполняя сквозное шифрование TLS) или не шифруется.
Когда шлюз приложений отправляет исходный запрос на внутренний сервер, он учитывает все пользовательские настройки, внесенные в параметры 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-запрос, он использует значение с сервера, который отвечает первым.
- Пользователи локальных пользовательских 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 с помощью параметра переопределения пути. Тем не менее, если не настроить это, все входящие запросы будут перенаправлены в серверную часть.