Для публикации серверов 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 — Аутентификация посредством сертификатов, использующих инфраструктуру открытых ключей (PKI).
Профиль клиентского сертификата
При выборе режима аутентификации посредством сертификатовPKI необходимо указать сконфигурированный ранее профиль пользовательских сертификатов.
Важно! Строки с символом '*' в таких списках не работают (игнорируются).
Каждые 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, которые требуется изменить.
Изменить на — домен и/или путь 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/co*
http://test.dev/co*
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.develop
http://test.dev/co
http://test.dev/co*
http://test.dev:<любой порт>/co
http://test.dev/cool*
Правила подмены путей
При срабатывании правила 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.
