Как работает шлюз приложений Azure
Шлюз приложений Azure содержит ряд компонентов, которые объединяются для безопасного маршрутизации и балансировки нагрузки запросов в пуле веб-серверов. Шлюз приложений включает следующие компоненты:
- интерфейсный IP-адрес: клиентские запросы получаются через внешний IP-адрес. Шлюз приложений может иметь общедоступный IP-адрес, частный IP-адрес или оба. Шлюз приложений не может иметь несколько общедоступных IP-адресов и один частный IP-адрес.
- Слушатели: шлюз приложений использует одного или нескольких слушателей для обработки входящих запросов. Прослушиватель принимает трафик, поступающий по указанному сочетанию протокола, порта, узла и IP-адреса. Каждый прослушиватель направляет запросы к внутреннему пулу серверов, следуя заданным правилам маршрутизации. Прослушиватель может быть базовым или для нескольких сайтов. Прослушиватель Базовый направляет запрос только на основе пути в URL-адресе. Прослушиватель многосайтовый также может направлять запросы, используя элемент имени хоста в URL-адресе. Прослушиватели также обрабатывают TLS/SSL-сертификаты для защиты приложения между пользователем и шлюзом приложений.
- правила маршрутизации: правило маршрутизации привязывает прослушиватель к внутренним пулам. Правило указывает, как интерпретировать элементы имени узла и пути в URL-адресе запроса и направлять запрос в соответствующий внутренний пул. Правило маршрутизации также содержит связанный набор параметров HTTP. Эти параметры HTTP указывают, шифруется ли трафик между шлюзом приложений и внутренними серверами. Другие сведения о конфигурации включают протокол, закрепление сеансов, очистку соединений, время ожидания запроса и проверки работоспособности.
Балансировка нагрузки в шлюзе приложений
Шлюз приложений автоматически балансирует нагрузку запросов, отправленных на серверы в каждом серверном пуле с помощью механизма циклического перебора. Балансировка нагрузки работает с маршрутизацией уровня 7 OSI, реализованной маршрутизацией шлюза приложений, что означает, что она балансирует запросы на основе параметров маршрутизации (имен узлов и путей), используемых правилами шлюза приложений. Для сравнения, другие подсистемы балансировки нагрузки, такие как Azure Load Balancer, работают на уровне OSI 4 и распределяют трафик на основе IP-адреса целевого объекта запроса.
Вы можете настроить привязку сеанса, если необходимо убедиться, что все запросы клиента в одном сеансе перенаправляются на один и тот же сервер в пуле серверов обработки.
Брандмауэр веб-приложения
Брандмауэр веб-приложения (WAF) — это необязательный компонент, который обрабатывает входящие запросы, прежде чем они достигают прослушивателя. Брандмауэр веб-приложения проверяет каждый запрос на наличие множества распространенных угроз на основе проекта Open Web Application Security (OWASP). Распространенные угрозы: SQL-инъекции, межсайтовый скриптинг, инъекция команд, подделка HTTP-запросов, разделение ответа HTTP, включение удаленных файлов, боты, поисковые роботы и сканеры, а также нарушения протокола HTTP и аномалии.
OWASP определяет набор универсальных правил для обнаружения атак. Эти правила называются набором основных правил (CRS). Наборы правил находятся на постоянном пересмотре, поскольку атаки становятся более изощрёнными. WAF поддерживает четыре набора правил: CRS 3.2, 3.1, 3.0 и 2.2.9. CRS 3.1 — это значение по умолчанию. При необходимости можно выбрать только определенные правила в наборе правил, нацелив на определенные угрозы. Кроме того, можно настроить брандмауэр, чтобы указать элементы в запросе для проверки, а также ограничить размер сообщений, чтобы предотвратить перегрузку серверов крупными загрузками.
Серверные пулы
Серверный пул — это коллекция веб-серверов, которые могут быть состоят из: фиксированного набора виртуальных машин, масштабируемого набора виртуальных машин, приложения, размещенного службами приложений Azure, или коллекции локальных серверов.
Каждый серверный пул имеет связанный балансировщик нагрузки, который распределяет работу по пулу. При настройке пула укажите IP-адрес или имя каждого веб-сервера. Все серверы в серверном пуле должны быть настроены одинаково, включая их параметры безопасности.
Если вы используете TLS/SSL, внутренний пул имеет параметр HTTP, который ссылается на сертификат, используемый для проверки подлинности внутренних серверов. Шлюз повторно шифрует трафик с помощью этого сертификата перед отправкой его на один из серверов в серверном пуле.
Если вы используете службу приложений Azure для размещения серверного приложения, вам не нужно устанавливать сертификаты в шлюзе приложений для подключения к внутреннему пулу. Все сообщения шифруются автоматически. Шлюз приложений доверяет серверам, так как Azure управляет ими.
Шлюз приложений использует правило для того, чтобы указать, как направлять сообщения, которые он получает на входящем порту, на серверы в серверном пуле. Если серверы используют TLS/SSL, необходимо настроить правило, чтобы указать следующее:
- Что серверы ожидают трафика через протокол HTTPS.
- Какой сертификат используется для шифрования трафика и проверки подлинности подключения к серверу.
Маршрутизация шлюза приложений
Когда шлюз направляет запрос клиента на веб-сервер в серверном пуле, он использует набор правил, настроенных для шлюза, чтобы определить, где должен идти запрос. Существует два основных метода маршрутизации трафика запроса клиента: маршрутизация на основе маршрута и маршрутизация для нескольких сайтов.
Маршрутизация на основе пути
Маршрутизация на основе пути отправляет запросы с различными путями URL-адресов в разные пулы внутренних серверов. Например, можно направлять запросы с помощью пути /video/* во внутренний пул, содержащий серверы, оптимизированные для обработки потоковой передачи видео, и направлять запросы /images/* к пулу серверов, обрабатывающему запросы на извлечение изображений.
Маршрутизация между несколькими сайтами
Настройка маршрутизации нескольких сайтов обеспечивает конфигурацию более одного веб-приложения в одном экземпляре шлюза приложений. В конфигурации с несколькими сайтами необходимо зарегистрировать несколько DNS-имен (CNAMEs) для IP-адреса шлюза приложений, указав имя каждого сайта. Шлюз приложений использует отдельные прослушиватели для ожидания запросов для каждого сайта. Каждый прослушиватель передает запрос другому правилу, которое может направлять запросы на серверы в другом серверном пуле. Например, можно направлять все запросы на http://contoso.com на серверы в одном внутреннем пуле, а запросы на http://fabrikam.com — в другой внутренний пул. На следующей схеме показана эта конфигурация:
Конфигурации с несколькими сайтами полезны для поддержки мультитенантных приложений, где каждый клиент имеет собственный набор виртуальных машин или других ресурсов, в которых размещено веб-приложение.
Маршрутизация шлюза приложений также включает следующие функции:
- перенаправление. Перенаправление можно использовать на другом сайте или из HTTP на HTTPS.
- Переписывание заголовков HTTP. Заголовки HTTP позволяют клиенту и серверу передавать сведения о параметрах с помощью запроса или ответа.
- пользовательские страницы ошибок. Шлюз приложений позволяет создавать пользовательские страницы ошибок вместо отображения страниц ошибок по умолчанию. Вы можете использовать собственную фирменную символику и макет с помощью настраиваемой страницы ошибок.
Завершение TLS/SSL
При завершении подключения 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.