|
|
Публикация HTTP/HTTPS-ресурсов с помощью reverse-прокси
Для публикации серверов HTTP/HTTPS рекомендуется использовать публикацию с помощью правил reverse-прокси.
В отличие от публикации с помощью правил DNAT, публикация с использованием reverse-прокси предоставляет следующие преимущества:
-
Публикация по HTTPS серверов, работающих по HTTP и наоборот.
-
Балансировка запросов на ферму веб-серверов.
-
Возможность ограничения доступа к публикуемым серверам с определенных Useragent.
-
Возможность подмены доменов и путей публикуемых серверов.
Чтобы опубликовать сервер, используя reverse-прокси, необходимо выполнить следующие шаги:
|
Наименование
|
Описание
|
|
Шаг 1. Создать сервер reverse-прокси.
|
В разделе Глобальный портал ➜ Серверы reverse-прокси нажать на кнопку Добавить и создать один или более публикуемых веб-серверов.
|
|
Шаг 2. Создать правило балансировки на серверы reverse-прокси (опционально).
|
В случае, если требуется балансировка на ферму публикуемых серверов, создать в разделе Политики сети ➜ Балансировка нагрузки балансировщик reverse-прокси. В качестве серверов используются серверы reverse-прокси, созданные на предыдущем шаге.
|
|
Шаг 3. Создать правило reverse-прокси.
|
В разделе Глобальный портал ➜ Правила reverse-прокси создать правило, которое будет задавать условия публикации серверов или фермы серверов.
Важно! Правила публикации применяются сверху вниз в списке правил. Срабатывает только первое правило публикации, для которого совпали все условия, указанные в настройках правила.
|
|
Шаг 4. Разрешить сервис Reverse-прокси на зоне, с которой необходимо разрешить доступ к внутренним ресурсам.
|
В разделе Сеть ➜ Зоны разрешите сервис Reverse-прокси для зоны, с которой необходимо разрешить доступ к внутренним ресурсам (обычно зона Untrusted).
|
Создание сервера reverse-прокси
Для создания сервера reverse-прокси разделе Глобальный портал ➜ Серверы reverse-прокси необходимо нажать на кнопку Добавить и заполнить следующие поля:
|
Наименование
|
Описание
|
|
Название
|
Название публикуемого сервера.
|
|
Описание
|
Описание публикуемого сервера.
|
|
Адрес сервера
|
IP-адрес публикуемого сервера.
|
|
Порт
|
TCP-порт публикуемого сервера.
|
|
HTTPS до сервера
|
Определяет, требуется ли использовать протокол HTTPS до публикуемого сервера.
|
|
Проверять SSL-сертификат
|
Включает/отключает проверку валидности SSL-сертификата, установленного на публикуемом сервере.
|
|
Не изменять IP-адрес источника
|
Оставляет оригинальный IP-адрес источника в пакетах, пересылаемых на публикуемый сервер. Если отключено, то IP-адрес источника заменяется на IP-адрес NGFW.
|
Балансировка серверов reverse-прокси
Для создания правила балансировки на серверы reverse-прокси в разделе Политики сети ➜ Балансировка нагрузки необходимо выбрать Добавить ➜ Балансировщик reverse-прокси и заполнить следующие поля:
|
Наименование
|
Описание
|
|
Включено
|
Включает или отключает правило.
|
|
Название
|
Название правила.
|
|
Описание
|
Описание правила.
|
|
Серверы reverse-прокси
|
Созданный на предыдущем шаге список серверов reverse-прокси, на которые будет распределяться нагрузка.
|
Создание правила публикации reverse-прокси
Для создания правила reverse-прокси необходимо нажать на кнопку Добавить в разделе Глобальный портал ➜ Правила reverse-прокси и заполнить необходимые поля.
Примечание Правила применяются поочередно сверху вниз в том порядке, в котором они указаны в списке. Выполняется только первое правило, для которого совпали все указанные в нём условия. Это значит, что более специфические правила должны быть выше в списке, чем более общие правила. Используйте кнопки Выше/Ниже, Наверх/Вниз или перетаскивание мышью для изменения порядка применения правил.
Примечание Флажок Инвертировать меняет действие условия на противоположное, что соответствует логическому «НЕ» (отрицание).
|
Наименование
|
Описание
|
|
Включено
|
Включает или отключает правило.
|
|
Название
|
Название правила.
|
|
Описание
|
Описание правила.
|
|
Сервер reverse-прокси
|
Сервер reverse-прокси или балансировщик reverse-прокси, куда NGFW будет пересылать запросы.
|
|
Порт
|
Порт, на котором NGFW будет слушать входящие запросы.
|
|
Использовать HTTPS
|
Включает поддержку HTTPS.
|
|
Профиль SSL
|
Профиль SSL позволяет указать протоколы SSL или отдельные алгоритмы шифрования и цифровой подписи.
|
|
Сертификат
|
Сертификат, используемый для поддержки HTTPS-соединения.
|
|
Авторизовать по сертификату
|
Для выбора доступны следующие опции:
|
|
Профиль клиентского сертификата
|
При выборе режима аутентификации посредством сертификатов PKI необходимо указать сконфигурированный ранее профиль пользовательских сертификатов.
|
|
Источник
|
Зона, списки IP-адресов, списки гео IP-адресов, списки URL источника трафика.
Список URL должен включать только имена доменов.
Важно! Строки с символом '*' в таких списках не работают (игнорируются).
Каждые 5 минут NGFW производит разрешение доменных имен в IP-адреса и хранит полученный результат во внутреннем кэше на время жизни DNS-записи. По истечении времени жизни NGFW автоматически обновляет значение IP-адреса.
Важно! Существует ограничение на количество GeoIP, которое может быть указано: не более 15.
Важно! Обработка трафика происходит по следующей логике:
-
условия объединяются по ИЛИ, если указаны несколько списков IP-адресов и/или доменов;
-
условия объединяются по И, если указаны GeoIP и списки IP-адресов и/или доменов.
|
|
Пользователи
|
Список пользователей и групп, для которых применяется данное правило. Могут быть использованы пользователи типа Any, Unknown, Known. Для применения правил к конкретным пользователям или к пользователям типа Known необходимо настроить идентификацию пользователей.
Данная вкладка доступна только при использовании HTTPS и авторизации пользователя по сертификату.
|
|
Назначение
|
Адрес назначения должен быть назначен на интерфейс, на который приходит входящее соединение.
Важно! Существует ограничение на количество GeoIP, которое может быть указано: не более 15.
Важно! Обработка трафика происходит по следующей логике:
-
условия объединяются по ИЛИ, если указаны несколько списков IP-адресов и/или доменов;
-
условия объединяются по И, если указаны GeoIP и списки IP-адресов и/или доменов.
|
|
Useragent
|
UserAgent пользовательских браузеров, для которых будет применено данное правило.
С помощью флажка Инвертировать можно заблокировать доступ к сервису, опубликованному через правило reverseproxy, для указанных в этом поле UserAgent.
|
|
Подмена путей
|
Подмена домена и/или пути в URL в запросе пользователя. Например, позволяет преобразовать запросы, приходящие на http://www.example.com/path1 в http://www.example.loc/path2
Изменить с — домен и/или путь URL, которые требуется изменить.
Изменить на — домен и/или путь URL, на которые требуется заменить старые.
Если указан домен в поле Изменить с, то правило публикации будет применено только для запросов, которые пришли именно на этот домен. То есть в данном случае это будет являться условием срабатывания правила.
|
Подмена путей в правилах reverse-прокси
В данном разделе рассматривается порядок работы функции подмены путей в правилах reverse-прокси для релиза ПО 7.2.0.
Подмена путей в правилах reverse-прокси используется для перенаправления HTTP-запроса пользователя на иной путь. Например, пользователь выполнил запрос на example.com/path1, а обратный прокси перенаправляет запрос на example.local/path2.
Настройка правил reverse-прокси в веб-консоли администратора происходит в разделе Глобальный портал ➜ Правила reverse-прокси:
Подмена путей настраивается на одноименной вкладке настроек правила:
На основании паттерна в поле Изменить с выбирается правило reverse-прокси, по которому будет перенаправлен трафик.
Если запрос пользователя не попадет ни под одно правило reverse-прокси, то в ответ на него будет получена ошибка: 403 Forbidden.
Правила проверки соответствия
Синтаксис HTTP-запроса представляет собой следующую последовательность: <scheme>://<host>:<port>/<path>.
Паттерн в поле Изменить с состоит из последовательности <host>/<path>. Элементы последовательности HTTP-запроса <scheme> и <port> в текущей реализации игнорируются.
-
<host> — обязательный параметр. Совпадение строгое, наличие и отсутствие символа "/" в конце названия хоста без пути равнозначно. Все названия хостов приводятся к нижнему регистру.
-
<path> — необязательный параметр. Без него будет выбираться любой путь. Совпадение префиксное (не строгое).
При совпадении запроса и исходного паттерна правило считается сработавшим.
Примеры:
|
Исходный паттерн в правиле reverse-прокси
|
Примеры запросов, на которые правило сработает
|
Примеры запросов, на которые правило не сработает
|
|
test.dev
|
-
test.dev
-
test.dev/
-
test.dev/*
-
http://test.dev
-
test.dev:<любой порт>
|
-
abc.com
-
test.develop
-
test.dev.lol
|
|
tesT.deV
|
-
test.deV
-
tesT.deV/
-
TEST.dev
|
-
abc.com
-
test.develop
-
test.dev.lol
|
|
test.dev/co
|
|
-
test.dev.lol/co*
-
test.dev/kool*
|
|
http://test.dev
|
-
http://test.dev
-
http://test.dev/*
-
http://test.dev:<любой порт>
-
http://test.dev:<любой порт>/
-
http://test.dev:<любой порт>/*
|
|
|
http://test.dev/co
|
|
|
Правила подмены путей
При срабатывании правила reverse-прокси происходит подмена пути в HTTP-запросе. Паттерн из поля Изменить с меняется на паттерн из поля Изменить на.
-
Паттерн из поля Изменить с и паттерн из поля Изменить на должны оба либо заканчиваться на символ "/", либо нет. В противном случае подмена путей сработает некорректно.
-
Схема (<scheme>) запроса игнорируется и не изменяется.
-
Порт запроса игнорируется и не изменяется.
Рассмотрим детальнее логику работы подмены путей.
Для этого создадим правило test.dev/exa ➜ test.dev/ad/test и сделаем несколько запросов:
1) Запрос на test.dev/exalala.
В данном примере параметр path = /exalala. Из него убирается path шаблона для замены (Изменить с), в данном примере убирается /exa. Оставшаяся часть: lala.
При дальнейшей конвертации берется полученный остаток lala и добавляется концу path из шаблона Изменить на, то есть: /ad/test + lala. В итоге, после преобразования, параметр path получает значение: /ad/testlala.
Таким образом, конечный запрос будет отправлен по адресу: test.dev/ad/testlala.
2) Запрос на test.dev/exa/vvv.
В данном примере параметр path = /exa/vvv. Из него убирается path шаблона для замены (Изменить c), в данном примере убирается /exa. Оставшаяся часть: /vvv.
При дальнейшей конвертации берется полученный остаток /vvv и добавляется к концу path из шаблона Изменить на, то есть: /ad/test + /vvv. В итоге, после преобразования, параметр path получает значение: ad/test/vvv.
Таким образом, конечный запрос будет отправлен по адресу: test.dev/ad/test/vvv.
Веб-портал позволяет предоставить доступ к внутренним веб-ресурсам, терминальным и ssh-серверам компании для удаленных или мобильных пользователей, используя при этом только протокол HTTPS. Данная технология не требует установки специального клиента VPN, достаточно обычного браузера.
ПримечаниеЕсли на целевых HTTP-ресурсах настроена аутентификация Kerberos или NTLM, то NGFW может производить аутентификацию по технологии SSO (необходим настроенный LDAP-коннектор с загруженным keytab-файлом).
Для настройки веб-портала необходимо выполнить следующие шаги:
|
Наименование
|
Описание
|
|
Шаг 1. Включить и настроить веб-портал.
|
В разделе Настройки ➜ Веб-портал включить и настроить параметры веб-портала. Подробные значения настроек будут описаны далее в этой главе.
|
|
Шаг 2. Разрешить доступ к сервису веб-портала на необходимых зонах.
|
В разделе Сеть ➜ Зоны разрешить сервис веб-портала для выбранных зон (обычно зона Untrusted). Данное разрешение откроет доступ к порту сервиса, который был указан в настройках веб-портала на предыдущем шаге.
|
|
Шаг 3. Добавить внутренние ресурсы в веб-портал.
|
В разделе Глобальный портал ➜ Веб-портал добавить URL внутренних ресурсов, к которым необходим доступ пользователей. Подробные значения настроек будут описаны далее в этой главе.
|
При настройке веб-портала (раздел Настройки ➜ Веб-портал) необходимо заполнить следующие поля:
|
Наименование
|
Описание
|
|
Включено
|
Включает/Выключает веб-портал.
|
|
Имя хоста
|
Имя хоста, которое пользователи должны использовать, чтобы подключаться к сервису веб-портала. Данное имя должно резолвиться службами DNS в IP-адрес интерфейса NGFW, входящего в зону, на которой разрешен сервис веб-портала.
|
|
Порт
|
Порт TCP, который будет использоваться сервисом веб-портала. Порт вместе с именем хоста образуют URL для подключения пользователей в виде:
https://имя_хоста:порт.
|
|
Профиль аутентификации
|
Профиль аутентификации пользователей, который будет использоваться для аутентификации пользователей, подключающихся к веб-порталу. Профиль аутентификации задает метод аутентификации, например, AD-коннектор или локальный пользователь. Также в профиле аутентификации можно указать требование использовать мультифакторную аутентификацию для доступа к веб-порталу.
Более подробно о профилях аутентификации смотрите раздел руководства Профили аутентификации.
|
|
Шаблон страницы аутентификации
|
Выбрать шаблон страницы аутентификации, который будет использоваться для отображения формы для ввода логина и пароля. Создать свою страницу аутентификации можно в разделе Шаблоны страниц.
|
|
Шаблон портала
|
Выбрать шаблон веб-портала, который будет использоваться для отображения ресурсов, доступных через веб-портал. Создать свою страницу аутентификации можно в разделе Шаблоны страниц.
|
|
Предлагать выбор домена AD/LDAP на странице аутентификации
|
Показывать выбор домена на странице аутентификации веб-портала.
|
|
Показывать CAPTCHA
|
При включении данной опции пользователю будет предложено ввести код, который ему будет показан на странице аутентификации веб-портала. Рекомендуемая опция для защиты от ботов, подбирающих пароли пользователей.
|
|
Профиль SSL
|
Выбор профиля SSL для построения защищенного канала для отображения веб-портала. Подробно о профилях SSL смотрите в главе Профили SSL.
|
|
Сертификат
|
Сертификат, который будет использоваться для создания HTTPS-соединения. Если выбран режим Автоматически, то используется сертификат, выпущенный сертификатом SSL дешифрования для роли SSL Captive-портала. Более подробно о ролях сертификатов смотрите в разделе руководства Управление сертификатами.
|
|
Аутентификация пользователя по сертификату
|
Если выбрано, то требует предъявления пользовательского сертификата браузером. Для этого пользовательский сертификат должен быть добавлен в список сертификатов NGFW, ему должна быть назначена роль Пользовательский сертификат и назначен соответствующий пользователь NGFW. Более подробно о пользовательских сертификатах читайте в разделе Управление сертификатами.
|
Настройке веб-портала (раздел Глобальный портал ➜ Веб портал) сводится к тому, что необходимо создать записи публикации URL внутренних веб-ресурсов. Для каждого URL необходимо создать закладку и заполнить следующие поля:
|
Наименование
|
Описание
|
|
Включено
|
Включает или отключает закладку.
|
|
Название
|
Название закладки.
|
|
Описание
|
Описание закладки.
|
|
URL
|
URL ресурса, который необходимо опубликовать через веб-портал. Указывайте полный URL, начиная с http://, https://, ftp://, ssh:// или rdp://.
Важно! Для публикации терминальных серверов необходимо отключить опцию, требующую Network Level Authentication в свойствах RDP доступа на серверах терминального доступа. Аутентификацию пользователей для доступа к серверам в данном случае будет выполнять веб-портал в соответствии со своими настройками.
|
|
Домен прямого доступа
|
При указанном значении Домена прямого доступа пользователь может получить доступ к публикуемому ресурсу, минуя веб-портал, подключаясь к указанному домену. Обязательно должен быть указан протокол (HTTP или HTTPS) и домен.
|
|
Проверять авторизацию для RDP-сессий
|
Разрывать сессию RDP по завершению аутентификации на веб-портале на стороне сервера.
|
|
Включить прозрачную аутентификацию
|
Прозрачная аутентификация позволяет аутентифицировать пользователя на опубликованном для него приложении. Для аутентификации будут использованы те же данные, что пользователь ввел при входе на веб-портал. Для успешной работы этой опции необходимо, чтобы опубликованное приложение поддерживало прозрачную аутентификацию.
|
|
Профиль SSL
|
Выбор профиля SSL для построения защищенного канала для отображения веб-портала. Подробно о профилях SSL смотрите в главе Профили SSL.
|
|
Сертификат
|
Сертификат, который будет использоваться для для создания HTTPS-соединения между UserGate и сервером. Если выбран режим Выбрать сертификат, то используется сертификат, выпущенный сертификатом SSL дешифрования для роли SSL Captive-портала. Более подробно о ролях сертификатов смотрите в разделе руководства Управление сертификатами.
|
|
Иконка
|
Иконка, которая будет отображаться на веб-портале для данной закладки. Возможно указать одну из предопределенных иконок, указать внешний URL, по которому доступна иконка или загрузить свою иконку.
|
|
Вспомогательные URL
|
Вспомогательные URL, необходимые для работы основного URL, но которые нет необходимости публиковать для пользователей. Например, основной URL http://www.example.com получает часть медиаконтента со вспомогательного URL http://cdn.example.com.
|
|
Пользователи
|
Список пользователей и/или групп пользователей, которым разрешено отображение закладки на веб-портале и которым разрешен доступ к основному и вспомогательным URL.
|
Очередность закладок веб-портала определяет порядок отображения их пользователю. Администратор может менять очередность закладок с помощью кнопок Выше/Ниже, Наверх/Вниз или перетаскивая закладки с помощью мыши.
Веб-портал и reverse-прокси, наряду с правилами DNAT/Порт-форвардинга, позволяют опубликовать ресурсы, находящиеся внутри компании, пользователям из интернета.
При наличии публикаций внутренних ресурсов с помощью DNAT/Порт-форвардинга, reverse-прокси и веб-портала порядок обработки правил следующий:
-
Правила DNAT/Порт-форвардинга.
-
Правила веб-портала. Если имя хоста в запросе совпало с именем хоста веб-портала, и номер порта в запросе совпал с номером порта, указанного для работы веб-портала, то отрабатывают правила веб-портала.
-
Правила Reverse-прокси.
|
