Публикация ресурсов компании посредством Checkpoint

И так, у нас есть конфигурация из двух устройств Checkpoint, объединённых в отказоустойчивый кластер высокой доступности ClusterXL.

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

И так, два устройства Checkpoint. У каждого есть свой внутренний IP адрес и внешний IP адрес.

Устройства объединены в кластер и по технологии имеют еще виртуальный внутренний IP адрес и виртуальный внешний IP адрес.

Назовём устройства CP1 и CP2.

CP1:
Внешний IP: 1.1.1.1
Внутренний IP: 192.168.1.1

CP2:
Внешний IP: 1.1.1.2
Внутренний IP: 192.168.1.2

ClusterXL:
Внешний IP: 1.1.1.3
Внутренний IP: 192.168.1.3

Возможно, рисунок будет нагляднее:

И так, если тупой, можно опубликовать ресурс на IP адресе одного из устройств и получить закономерный отказ когда оно выйдет из строя или будет выключено.
А можно опубликовать на IP адресе кластера, тогда будет соблюдена отказоустойчивость решения.
Но что делать, если порт, который слушает наш ресурс уже занят на IP адресе кластера?
Для этого необходимо иметь в запасе белый IP адрес, арендованный у провайдера.

Значит, надо настроить Checkpoint на обработку подобных запросов. Напоминаю, что этот метод касается Gaia R80.10, на более старых версиях это делается иначе.

И так, для наглядности решим, что мы заявляем новый виртуальный IP адрес 1.1.1.4
Интерфейс, на который физически подключен кабель интернет, на обоих устройствах checkpoint одинаковый и называется eth1.

С начала настраиваем ARP Proxy на устройствах.
Для этого заходим в Web-интерфейс устройств CP1 и CP2 и идём в раздел ARP Proxy.

IPv4 Address – виртуальный IP адрес, который мы заявляем.
Interface Name – по какому интерфейсу адрес будет слушаться.
Real IP Address – Реальный IP адрес устройства на этом интерфейсе. На втором устройстве он будет другой!

Для применения конфигурации ARP Proxy требуется установка политики.

Далее идём в SmartConsole и создаём объекты:

– Хост олицетворяющий виртуальный IP адрес 1.1.1.4. Называем, как считаете нужным, например MyVIP-4. В свойствах указываем его IP адрес, конечно.
– Хост олицетворяющий реальный сервер в сети компании, который мы публикуем. OrgSrv1
-Протокол, если требуется или сервис, как это называется в Checkpoint.

Затем создаём правила в Security Policy, которое разрешит входящие подключения из интернета на виртуальный IP адрес по нужному протоколу.
Например:
Name:Publish FTP – Source: Internet – Dest:MyVIP-4 Services:FTP

Затем создаём правила NAT
1. Org.Source: Any – Org. Dst: MyVIP-4 – Org.Services:FTP – TransSource:Original – TransDest: OrgSrv1 -TransServices: Original
Это правило описывает маршрут из Интернет на наш внутренний сервер по протоколу FTP.
2. Org.Source: OrgSrv1 – Org. Dst: Any – Org.Services:FTP – TransSource:MyVIP-4 – TransDest: Original -TransServices: Original
Это правило описывает обратный маршрут от сервера в интернет, представляясь адресом MyVIP-4

Усложним схему. Добавим сервер OrgSrv2 и представим что это DNS сервер.
Для этого потребуется только дать разрешения на соединения в Access Control Policy и добавить правила NAT с уточнением, что используем протокол DNS.
И нет ни каких противоречий в правилах. Если запросы DNS – отправляем на OrgSrv2, если FTP – на OrgSrv1.
Если запросы по портам пересекаются – разносим на разные IP адреса.

Добавить комментарий