Выбираем корпоративный интернет-шлюз

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

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

Аппаратное или программное решение?

В первую очередь, стоит определиться: выбрать аппаратное решение или же программное. Большинство аппаратных решений выпускаются преднастроенными и работают по принципу «поставил и забыл». В условиях ограниченного бюджета и при недостаточной квалификации лучше (от греха подальше) использовать аппаратное решение.

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

Необходимый функционал корпоративного интернет-шлюза

Интернет-шлюз организует бесперебойную работу в интернете всех работников фирмы, поэтому прокси-сервер, на базе которого он выполнен, должен обладать достаточным функционалом, удобным интерфейсом и возможностью гибкой настройки сети и прав доступа: VIP-пользователям обеспечить полный доступ к сети, а рядовым отрубить ВКонтакте и любимые форумы. Также важно легко управлять скоростью пользователей, устанавливать приоритеты для различных видов трафика (например, повысить приоритет IP-телефонии для обеспечения качественной связи и понизить для архивов). Не стоит забывать и о поддержке VPN и NAT. Крайне полезна возможность удаленного администрирования, чтобы львиную долю проблем с сетью можно было решать, не выходя из дома.

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

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

Отдельно стоит сказать о статистике, которая для интернет-шлюза является не «третьим видом лжи», а важным источником информации о поведении пользователя. Благодаря статистике можно в любое время узнать, кто из пользователей забивает Интернет-канал, на каких ресурсах зависают сотрудники и когда пора блокировать сайты и резать лимит трафика.

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

Отдельная тема – наличие сертификатов безопасности, которые, во-первых, определенную безопасность гарантируют (абы кому их не выдают), а во-вторых, в случае наличия сертификата ФСТЭК, интернет-шлюз не вызовет подозрения в ходе «всеми горячо любимых» бюрократических проверок организации.

Основные проблемы сисадминов с интернет-шлюзом

Каждый раз при размещении нового сервера или службы у сисадмина возникает проблема: как «вписать» новую постоянно работающую службу или сервер в уже устоявшуюся сеть.

Как подстроить NAT и другие сетевые службы для ее корректной работы, будет ли данный сервер в AD, могут ли на нем размещаться другие сетевые службы или сервер должен быть выделенным. Это не зависит от способа реализации – это вопрос сетевого планирования.

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

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

Благодарим вас за внимание и ждем ваших комментариев.

Предыдущие посты:

• Сравнение техподдержки крупнейших производителей ПО в сфере сетевой безопасности
• Traffic Inspector: полная перезагрузка

• proxy
• прокси-сервер
• прокси сервер
• прокси сервера
• безопасность в сети
• безопасность
• информационная безопасность и сети
• traffic inspector
• доступ в интернет

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

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

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

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-адреса или перенаправлять запросы на другой порт или внешний сайт.

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

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

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

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

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

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

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

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

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

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

• При использовании пользовательских DNS-серверов с виртуальная сеть Шлюз приложений важно, чтобы все серверы были идентичными и отвечали одинаковыми значениями DNS.
• Пользователи локальных настраиваемых DNS-серверов должны обеспечить подключение к Azure DNS через частный сопоставитель DNS Azure (рекомендуется) или виртуальную машину сервера пересылки 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 с помощью параметра переопределения пути. Тем не менее, если не настроить это, все входящие запросы будут перенаправлены в серверную часть.

Дальнейшие действия

• Дополнительные сведения о компонентах шлюза приложений
• Обзор функций Шлюз приложений Azure

При подготовке материала использовались источники:
https://habr.com/ru/companies/smart_soft/articles/257829/
https://learn.microsoft.com/ru-ru/azure/application-gateway/how-application-gateway-works