This version of the page http://www.dlink.ua/dfl_sat (0.0.0.0) stored by archive.org.ua. It represents a snapshot of the page as of 2015-07-11. The original page over time could change.
Настройка перенаправления TCP/UDP портов через WAN, использование действий SAT и SLB SAT. | http://dlink.ua/ru
  

Настройка перенаправления TCP/UDP портов через WAN, использование действий SAT и SLB SAT.

Часто бывает необходимость предоставить доступ из Internet к внутренним рессурсам локальной сети.  Для проброса соединений со стороны Internet  во внутреннею сеть в устройствах серии DFL используется технология SAT (Static Address Translation).  В правилах файрвола («Rules») необходимо создавать действия «SAT» или «SLB SAT».

ВАЖНО!!! В отличии от остальных действий (например «Allow», «NAT», «Deny»), действия «SAT» или «SLB SAT» не являются разрешающими или запрещающими. Они говорят о необходимости модифицировать пакет, но после попадания в это правило пакет продолжает сверяться с остальными правилами. Т.е. после действий «SAT» или «SLB SAT» у Вас должно идти какое-либо разрешающее правило (например «Allow»).

ВАЖНО!!! Разрешающее правило должно быть сделано для не модифицированного пакета.

Пример №1. Простой пример использования SAT. Проброс службы SSH (TCP порт 22). Запросы будут приходить на интерфейс WAN1 на IP-адрес привязанный к этому интерфейсу. Проброс трафика выполняется на внутренний IP 192.168.10.15.

1. Создаём правило SAT, которое будет реагировать на трафик входящий на интерфейс WAN1 на IP-адрес привязанный к WAN1.

Действие выбираем «SAT», сервис «ssh». В качестве источника трафика выбираем интерфейс, с которого трафик будет приходить и группу или единичный IP-адрес. В моём примере я не ставлю ограничений, поэтому выбираю группу «all-nets». В качестве назначения выбираю интерфейс «core» и в поле «Network» указываю IP на который будут приходить запросы «wan1_ip».

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

Получаем созданное правило «SAT», которое обязано модифицировать приходящие пакеты. 

Создаём второе правило, которое будет разрешать наши пакеты.

Действие выбираем «Allow», все остальные поля заполнены так же как и в предыдущем правиле.

Получаем 2 правила. Не забывайте, что правило SAT должно находиться выше разрешающего правила. Это связано с тем, что пакет, попадая в разрешающее или запрещающее правило, дальше не идёт по таблице «Rules».

Кроме того, обратите внимание, что бы параметры протокола, интерфейсов и сетей в разрешающем правиле были такие же, как и в правиле с действием «SAT».

Пример №2. Публикация сервиса на не стандартном порту. Проброс службы SSH (TCP порт 22). Запросы будут приходить на интерфейс WAN1 на IP-адрес привязанный к этому интерфейсу на TCP порт 20022. Проброс выполняется на внутренний IP 192.168.10.15 на порт 22.

Такая конфигурация может быть необходима в 2 случаях:

  1. Безопасность – сервис, расположенный на стандартном порту, легко поддаётся обнаружению при сканировании. Кроме того номер порта сразу скажет о типе расположенного сервиса, что значительно упростит задачу злоумышленнику.
  2. Если у вас несколько аналогичных сервисов, например, несколько сервисов SSH – расположить их на одном порту технически не возможно. Необходимо разбросать их по разным портам.

Последовательность действий:

1. Создаём не стандартный сервис в разделе «Objects» подраздел «Services». В нашем примере назовём его «ssh20022» с параметрами: протокол TCP, исходящий порт любой, порт назначения 20022. 

2. Создаём правило SAT как в предыдущем примере.

Отличие в том, что Вы используете не стандартный  протокол, а созданный Вами. После этого, при прохождении пакета через правило SAT Вы меняете не только адрес назначения, но порт назначения.

3. Создаём правило с действием «Allow».

Отличие от предыдущего примера, опять же, только используемый протокол.

4. В результате мы получаем 2 правила.

Пример №3. (дополнение к примеру №2) Если у Вас несколько сервисов расположенных на разных серверах – Вы можете для упрощения правил объединить несколько правил Allow. Однако правила SAT объединению не поддаются. Для примера добавим ещё один сервис SSH, который будет расположен на IP 192.168.10.16. Публиковать его будем на порту 20023.

1. Добавляем ещё 1 сервис, который назовём «ssh20023» и объединим его в группу «ssh200xx_in» с предыдущим сервисом.

2. Создаём ещё одно правило с действием SAT. В этом правиле будет использован протокол ssh20023, а менять адрес назначения будем на 192.168.10.16.

Не забудьте разместить все правила с действием SAT выше разрешающих правил Allow, FastForward или NAT, к которым они относятся. Располагать правила SAT выше всех разрешающих правил не обязательно.

3. Изменяем правило с действием Allow так, что бы оно работало с группой сервисов:

4. Получаем меньшее количество правил, которые более в большинстве случаев более организованы и удобнее читаются.

Пример №4: использование действия «SLB SAT». Это действие используется, когда один и тот же порт необходимо пробросить на несколько разных серверов. Например, у Вас есть «ферма» из 3  терминальных (RDP) серверов, на которые заходят и работают пользователи.

Важно! Модели DFL-210, DFL-260, DFL-260E (младшие модели) не обладают функционалом SLB SAT.

Для пример сервера будут находиться в DMZ зоне, за интерфейсом роутера DMZ. Сервера будут иметь адреса 172.16.100.100, 172.16.100.103 и 172.16.100.108. В настройках пользователей в клиенте будем указывать ip-адрес нашего файрвола на интерфейсе wan1. Соединение на сервера может быть как со стороны локальной сети, так и со стороны Internet с интерфейса wan1.

Настройка:

1. Сервис rdp с параметрами: протокол TCP, исходящий порт 0-65535, порт назначения 3389 у нас уже есть в сервисах «по умолчанию».  Будем использовать его.

2. Создаю в объектах 3 новых объекта с ip-адресами серверов и именами «rdp_server_».

3. Т.к. запросы будут идти с нескольких интерфейсов, то можно использовать в правилах при выборе интерфейса-источника «any». Однако в этом случае могут пройти запросы с нежелательных интерфейсов (например, в нашем случае с «wan2»). Что бы ни писать несколько правил – сделаем группу из разрешённых интерфейсов. Назовём её «RDP_client_int».

4. Создаём в разделе «Rules» правило с действием «SLB SAT».

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

Далее есть 2 закладки, которые нам необходимо настроить: «SLB SAT» и «SLB Monitoring».

На закладке «SLB SAT» есть несколько важных разделов.

В разделе «Server Addresses» выбираем сервера входящие в наш кластер.

В разделе «Monitorig» можно выбрать таблицу маршрутизации, которая будет использоваться для мониторинга доступности серверов. Это актуально если у нас на файрволе используется несколько таблиц маршрутизации. Обратите внимание, что таблица маршрутизации для мониторинга и таблица маршрутизации по которой пользователи будут получать доступ к серверам – могут быть разными. В данном разделе указывается таблица маршрутизации ТОЛЬКО для мониторинга.

В разделе «Distrivution» можно выбрать принцип распределения между серверами. Доступно 2 варианта: Round-robin – каждое новое соединение на следующий сервер, Connection-rate – в пределах указанного временного окна все соединения идут на один сервер.

В разделе «Stickiness» можно настроить привязку соединений к одному серверу. Это важно для сложных протоколов, где между клиентом и сервером может порождаться много соединений и необходимо, что бы все соединения шли на один физический сервер. Например, в протоколе SIP есть управляющий поток SIP (стандартный порт 5060) и голосовой поток RTP. Необходимо что бы они пришли на один сервер. Привязывать можно по ip-адресам или маске сети.

Закладка «SLB Monitoring» служит для настройки мониторинга серверов находящихся в правиле. На сервера, которые не прошли тестирование, не будут передаваться запросы. Для тестирования доступны 3 метода: ICMP ping, TCP Syn запросы и HTTP запросы. В нашем примере наиболее оптимален метод TCP запросы на установку соединения. При настройках указанных в примере каждые 10 секунд будет посылаться по 10 запросов на соединение. Допускается не более 2 отказов от соединения, причём ответ должен вернуться не позже 0,8 сек.

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

5. Создаём в разделе «Rules» правило с действием «Allow».

6. Получаем 2 правила, которые обеспечивают нам работу кластера.

Примечание (Несколько замечаний по описанным примерам):

  1. Метод «SLB SAT» не обеспечит Вам полноценной балансировки, какую могут обеспечить специализированные средства, например, кластер поднятый средствами Microsoft NLB cluster. Однако кластер запущенный средствами «SLB SAT» может обеспечить работу кластера там, где он не предусмотрен средствами производителя оборудования или ПО. Кроме того «SLB SAT» значительно проще в настройке, чем большинство стандартных аналогичных систем.
  2. В примерах 1,2 и 3 локальные пользователи не смогут получить доступ к сервису указав у себя в настройках внешний IP и порт. Это бывает неудобно, особенно если это мобильный клиент и может часто менять своё положение. Такому клиенту придётся иметь 2 набора настроек, для внутренней сети и для внешней. Что бы этого избежать – можно сделать дополнительные настройки. Пример описан в инструкции на сайте dlink.ua:

http://dlink.ua/sites/default/files/dfl/How%20to%20make%20port%20mapping%20%28SAT%29%20from%20LAN%20to%20LAN%20through%20WAN.pdf