Публикация ресурсов с помощью reverse-прокси при использовании двух провайдеров

ID статьи: 37
Последнее обновление: 12 янв, 2023
KnowledgeBase:
Product: UserGate NGFW
Version: 6.1.8, 6.1.9

image202

Необходимо выполнить настройку UserGate для публикации веб-сервера для сетей 172.30.160.0/30, подключённой к UserGate через port1 с адресом 172.30.160.2, и 172.30.160.4/30, подключённой к UserGate через port2 с адресом 172.30.160.6. Веб-сервер находится в локальной сети (192.168.14.0/24), подключённой к UserGate через port0 с адресом 192.168.14.27; IP-адрес публикуемого сервера: 192.168.14.209; домен - itme.local.

В разделе Сеть ➜ Шлюзы были добавлены шлюзы с IP-адресами 172.30.160.1 и 172.30.160.5. Шлюз с адресом 172.30.160.1 указан как шлюз по умолчанию.

  1. В разделе Сеть ➜ Зоны создайте зоны, с которых будет разрешён доступ к публикуемому ресурсу, например, ISP-1 - зона для провайдера 1; ISP-2 - зона для провайдера 2. Для обеих зон во вкладке Контроль доступа разрешите сервис Reverse-прокси.

image203

  1. Перейдите в раздел Сеть ➜ Интерфейсы, выберите интерфейс port1 и назначьте ему соответствующую первому провайдеру зону, созданную на шаге 1 (в данном примере: зону ISP-1).

image204

Выберите интерфейс port2 и назначьте ему соответствующую второму провайдеру зону, созданную на шаге 1 (в данном примере: зону ISP-2).

image205

  1. Создайте сервер reverse-прокси. Для этого перейдите в раздел Глобальный портал ➜ Серверы reverse-прокси веб-интерфейса UserGate и нажмите Добавить. В настройках сервера укажите:

    • Название сервера.

    • Описание (опционально).

    • Адрес сервера - 192.168.14.209.

    • Порт: 80 (при использовании HTTP) или 443 (при использовании HTTPS).

    • Отметьте чекбокс HTTPS до сервера, если необходимо использовать HTTPS-соединение между UserGate и публикуемым сервером.

    • Отметьте чекбокс Проверять SSL-сертификат, при необходимости проверки сертификата сервера.

    • Отметьте чекбокс Не изменять IP-адрес источника, если на веб-сервере необходимо видеть реальные IP-адреса, с которых происходит подключение.

Был создан сервер reverse-прокси со следующими настройками:

image206

  1. Создайте правило reverse-прокси. Чтобы создать правило, перейдите в раздел Глобальный портал ➜ Правила reverse-прокси веб-интерфейса UserGate и нажмите Добавить. Далее необходимо настроить правило reverse-прокси. Во вкладке Общие:

    • Отметьте чекбокс Включено.

    • Название правила.

    • Описание (опционально).

    • Сервер reverse-прокси, созданный на шаге 3.

    • Порты: 80 (при использовании HTTP) или 443 (при использовании HTTPS).

    • Отметьте чекбокс Использовать HTTPS, если необходимо использовать HTTPS-соединение.

При использовании соединения по протоколу необходимо указать:

  • Профиль SSL, определяющий протоколы SSL, алгоритмы шифрования и цифровой подписи. Создание и настройка профилей SSL доступны в разделе Библиотеки ➜ Профили SSL.

  • Сертификат, используемый для поддержки HTTPS-соединения.

Также в правилах reverse-прокси доступна настройка авторизации по сертификату.

image207

В данном примере используется HTTPS-соединение, для которого необходимо наличие сертификата. Сертификат itme.local был сгенерирован и загружен в UserGate в разделе UserGate ➜ Сертификаты. Сертификату была назначена роль: Правила reverse-прокси.

Во вкладке Источник укажите зоны или адреса, с которых необходимо разрешить доступ к публикуемым ресурсам (в примере необходимо разрешить доступ из зон ISP-1 и ISP-2):

image208

Во вкладке Назначение можно указать адрес публикуемого сервера, если их несколько.

Во вкладке Useragents можно указать Useragent пользовательских браузеров, с которых будет доступен публикуемый сервер.

Во вкладке Подмена путей в поле Изменить с укажите домен или путь URL, которые требуется изменить; в поле Изменить на укажите домен или путь URL, на которые требуется изменить.

Для примера был использован вариант - без подмены путей:

image209

Проверка. На пользовательских компьютерах должно резолвиться доменное имя сервера. Выполните обращение к серверу с использованием утилиты cURL:

ruser@ubuntu:~$ curl -k -I https://itme.local
HTTP/1.1 200 OK
X-Tracking-Ref: <0.8355.5>
X-Execution-Time: 489418
Connection: keep-alive
Keep-Alive: timeout=3, max=5
Date: Fri, 01 Apr 2022 06:40:51 GMT
Server: Apache/2.4.29 (Ubuntu)
Keep-Alive: timeout=5, max=100
Content-Type: text/html; charset=UTF-8
Access-Control-Allow-Origin: *
Transfer-Encoding: chunked

В соответствии с данными настройками, если запрос будет приходить на UserGate (port1 или port2), то ответ будет отправлен через порт первого провайдера (port1), т.к. первый провайдер указан в качестве шлюза по умолчанию. В таком случае первый провайдер при наличии защиты от антиспуфинга может отбросить пакет, т.к. он ожидает ответ от 172.30.160.2, а получает от 172.30.160.6. Чтобы исключить возникновение такой ситуации, необходимо настроить правила типа Policy-based routing. Т.к. в данном примере один из шлюзов указан в качестве шлюза по умолчанию, то достаточно настроить одно правило PBR. Если шлюз по умолчанию не обозначен, то необходимо настроить соответствующее правило и для другого провайдера.

Настройте правило для провайдера 2. Для этого перейдите в раздел Политики сети ➜ NAT и маршрутизация и нажмите Добавить. Во вкладке Общие укажите:

  • Отметьте чекбокс Включено.

  • Название правила.

  • Описание (опционально).

  • Тип: Policy-based routing.

  • Шлюз: выберите шлюз провайдера 2 (в примере: ISP-2).

image210

Во вкладке Источник на панели Адрес источника необходимо добавить IP-адрес интерфейса, к которому подключён провайдер 2. IP-адрес интерфейса должен быть добавлен в список IP-адресов, который можно создать в разделе Библиотеки ➜ IP-адреса или при настройке правила (для этого нажмите Создать и добавить новый объект и укажите название списка и адрес).

image211

Проверка. Для проверки использовалась программа-анализатор Wireshark.

Обратный пакет клиент из подсети 192.168.0.0/24 получает от port1 (172.30.160.2).

image212

Клиент из подсети 192.168.1.0/24 получает обратный пакет от port2 с IP-адресом 172.30.160.6.

image213

Эта статья была:   Полезна | Не полезна
Сообщить об ошибке
ID статьи: 37
Последнее обновление: 12 янв, 2023
Ревизия: 3
Просмотры: 4638
Комментарии: 0
Теги