Принципы работы Шлюза приложений Azure
Шлюз приложений Azure имеет ряд компонентов, которые объединяются для безопасного маршрутизации и балансировки нагрузки запросов в пуле веб-серверов. Шлюз приложений включает в себя следующие компоненты:
- Внешний IP-адрес: запросы клиентов получаются через внешний IP-адрес. Вы можете настроить Шлюз приложений таким образом, чтобы он имел общедоступный IP-адрес, частный IP-адрес или же их оба. Шлюз приложений не может иметь больше одного общедоступного и одного частного IP-адреса.
- Прослушиватели: Шлюз приложений использует один или несколько прослушивателей для получения входящих запросов. Прослушиватель принимает трафик, поступающий на указанное сочетание протокола, порта, узла и IP-адреса. Каждый прослушиватель направляет запросы в пул серверов, следуя заданным вами правилам маршрутизации. Прослушиватель может быть Базовым или Многосайтовым. Прослушиватель уровня "Базовый" направляет запрос только на основе пути в URL-адресе. Прослушиватель с несколькими сайтами также может направлять запросы с помощью элемента имени узла URL-адреса. Для обеспечения безопасности приложения между пользователем и Шлюзом приложений прослушиватели также обрабатывают TLS/SSL-сертификаты.
- Правила маршрутизации. Правило маршрутизации привязывает прослушиватель к внутренним пулам. Правило указывает, как интерпретировать элементы имени узла и пути в URL-адресе запроса и направлять запрос в соответствующий внутренний пул. Правило маршрутизации также имеет сопутствующий набор параметров HTTP. Эти параметры HTTP указывают, зашифрован ли (и каким образом) трафик между Шлюзом приложений и серверами. Прочие сведения о конфигурации включают протокол, закрепление сеанса, сток подключений, время ожидания запроса и пробы работоспособности.
Балансировка нагрузки в Шлюзе приложений
Шлюз приложений автоматически балансирует нагрузку на запросы, отправленные серверам в каждом серверном пуле с помощью механизма циклического перебора. Во время балансировки нагрузки используется маршрутизация 7 уровня OSI, реализованная с помощью маршрутизации Шлюза приложений, а значит, что распределение запросов выполняется на основе параметров маршрутизации (имен узлов и путей), используемых правилами Шлюза приложений. Другие же подсистемы балансировки нагрузки, такие как Azure Load Balancer, функционируют на уровне 4 уровне модели OSI и распределяют трафик на основе IP-адреса целевого объекта запроса.
Если вам необходимо убедиться, что все запросы к клиенту в одном сеансе направляются на один и тот же сервер в серверном пуле, можно настроить закрепление сеанса.
Брандмауэр веб-приложения
Брандмауэр веб-приложения — это дополнительный компонент, который обрабатывает входящие запросы, прежде чем они достигнут прослушивателя. Брандмауэр веб-приложения проверка каждый запрос для многих распространенных угроз на основе проекта Open Web Application Security (OWASP). Распространенные угрозы: внедрение SQL,межсайтовый скрипт, внедрение команд, контрабанда HTTP-запросов, разделение ответа HTTP, включение удаленных файлов, боты, обходчики и сканеры, а также нарушения протокола HTTP и аномалии.
OWASP определяет набор универсальных правил для обнаружения атак. Эти правила служат базовым набором правил. Наборы правил постоянно пересматриваются, так как атаки приобретают все более сложный характер. Брандмауэр веб-приложения поддерживает четыре набора правил: CRS 3.2, 3.1, 3.0 и 2.2.9. По умолчанию используется CRS 3.1. При необходимости вы можете выбирать определенные правила в наборе правил, предназначенные для определенных угроз. Кроме того, вы можете настроить брандмауэр, чтобы указать, какие элементы в запросе следует проверять, и ограничить размер сообщений, чтобы избежать перегрузки своих серверов.
Серверные пулы
Внутренний пул — это коллекция веб-серверов, которые можно создать: фиксированный набор виртуальных машин, масштабируемый набор виртуальных машин, приложение, размещенное приложение Azure Services, или коллекцию локальных серверов.
Каждый серверный пул содержит соответствующую подсистему балансировки нагрузки, которая распределяет работу по всему пулу. При настройке пула указывается IP-адрес или имя каждого веб-сервера. Все серверы во внутреннем пуле должны быть настроены одинаково, включая параметры безопасности.
При использовании TLS/SSL у внутреннего пула есть параметр HTTP, который определяет сертификат для проверки подлинности внутренних серверов. Шлюз повторно зашифровывает трафик с помощью этого сертификата перед его отправкой на один из серверов во внутреннем пуле.
Если внутреннее приложение размещается в Службе приложений Azure, для подключения к внутреннему пулу не требуется устанавливать сертификаты в Шлюзе приложений. Все связи автоматически шифруются. Шлюз приложений доверяет серверам, так как ими управляет Azure.
Шлюз приложений использует правило, чтобы указать, как следует перенаправлять сообщения, получаемые через его входящий порт, на серверы во внутреннем пуле. Если серверы используют TLS/SSL, необходимо настроить правило, чтобы указать:
- Что серверы ожидают трафика через протокол HTTPS.
- Какой сертификат использовать для шифрования трафика и проверки подлинности подключения к серверу.
Маршрутизация Шлюза приложений
Когда шлюз направляет запросы клиента на веб-сервер из пула серверов, он использует набор заданных для шлюза правил, чтобы определить, куда должен поступить запрос. Существует два основных метода маршрутизации трафика этого запроса клиента — маршрутизация на основе пути и маршрутизация нескольких сайтов.
Маршрутизация на основе пути
Маршрутизация на основе пути отправляет запросы с разными URL-путями разным пулам внутренних серверов. Например, запросы с путем /video/* можно направить в пул серверов, содержащий оптимизированные для обработки потокового видео серверы, а запросы /images/* — в пул серверов, обрабатывающих извлечение изображений.
Маршрутизация нескольких сайтов
Маршрутизация с несколькими сайтами настраивает несколько веб-приложений в одном экземпляре Шлюз приложений. В конфигурации с несколькими сайтами регистрируются несколько DNS-имен (CNAME) для IP-адреса Шлюза приложений, которые определяют имя каждого сайта. Шлюз приложений использует отдельные прослушиватели для ожидания поступления запросов для каждого сайта. Каждый прослушиватель передает запрос на отдельный фильтр, который может направлять запросы на свой серверный пул. Например, все запросы http://contoso.com можно направлять на серверы одного пула, а запросы http://fabrikam.com — на серверы другого. На схеме ниже показана эта конфигурация.
Конфигурации с несколькими сайтами полезны для поддержки мультитенантных приложений, где каждый клиент имеет собственный набор виртуальных машин или других ресурсов, в которых размещено веб-приложение.
Шлюз приложений маршрутизация также включает следующие функции:
- Перенаправление. Перенаправлять можно на другой сайт или с протокола HTTP на протокол HTTPS.
- Перезапись заголовков HTTP Заголовки HTTP позволяют клиенту и серверу передавать информацию о параметрах вместе с запросом или ответом.
- Пользовательские страницы ошибок. Шлюз приложений позволяет создавать пользовательские страницы ошибок вместо отображения страниц ошибок по умолчанию. На пользовательской странице ошибок вы можете использовать собственные символику и макет.
Завершение TLS/SSL-запросов
Шлюз приложений позволяет избавить ваши серверы от необходимости выполнять операции завершения TLS/SSL-запросов, требующие интенсивного использования ЦП. Кроме того, на серверах не нужно устанавливать сертификаты и настраивать TLS/SSL.
Если требуется сквозное шифрование, Шлюз приложений может расшифровать трафик на шлюзе с помощью закрытого ключа, а затем повторно зашифровать с помощью открытого ключа службы, работающей в серверном пуле.
Трафик поступает в шлюз через внешний порт. Вы можете открыть несколько портов, и Шлюз приложений сможет получать сообщения через любой из них. Прослушиватель — это первый компонент, который обрабатывает трафик, поступающий в шлюз через порт. Прослушиватель настроен для прослушивания определенного имени узла и определенного порта для определенного IP-адреса. Прослушиватель может использовать TLS/SSL-сертификат для расшифровки поступающего в шлюз трафика. Затем прослушиватель использует правило, которое вы определили, для направления входящих запросов во внутренний пул.
Предоставление доступа к веб-сайту или веб-приложению через Шлюз приложений также означает, что серверы не подключаются напрямую к Интернету. Вы предоставляете шлюзу приложений только порт 80 или порт 443, который затем перенаправляется на сервер внутреннего пула. В этой конфигурации веб-серверы недоступны напрямую из Интернета, благодаря чему сокращаются направления атак на инфраструктуру.
Зонды работоспособности
Пробы работоспособности определяют, какие серверы доступны для балансировки нагрузки во внутреннем пуле. Шлюз приложений использует пробу работоспособности для отправки запроса на сервер. Если сервер возвращает HTTP-ответ с кодом состояния от 200 до 399, сервер считается работоспособным. Если не настроить проверку работоспособности, Шлюз приложений создаст проверку по умолчанию, которая по прошествии 30 секунд будет считать сервер недоступным. Пробы работоспособности гарантируют, что трафик не направляется в неответственное или неисправное веб-конечную точку в серверном пуле.
Автомасштабирование
Шлюз приложений поддерживает автомасштабирование и может увеличивать или уменьшать масштаб на основе изменения шаблонов нагрузки трафика. Кроме того, автоматическое масштабирование позволяет не выбирать размер развертывания или количество экземпляров во время подготовки.
Трафик WebSocket и HTTP/2
Шлюз приложений обеспечивает встроенную поддержку протоколов WebSocket и HTTP/2. Протоколы WebSocket и HTTP/2 обеспечивают полную дуплексную связь между клиентом и сервером через длительное TCP-подключение. Этот тип взаимодействия более интерактивный между веб-сервером и клиентом, и может быть двунаправленным без необходимости опроса в реализации на основе HTTP. Эти протоколы имеют низкие затраты (в отличие от HTTP) и могут повторно использовать одно и то же TCP-подключение для нескольких запросов и ответов, что приводит к более эффективному использованию ресурсов. Эти протоколы предназначены для работы через традиционные HTTP-порты 80 и 443.