Настройка NAT: Часть 2

Рассмотрим базовый сценарий настройки NAT.

Нет комментариев Просмотров: 754
19марта 2015
все статьи

Введение

Итак, мы с Вами добрались до настройки NAT. Давайте рассмотрим базовый сценарий настройки. Для этого предположим что:

  1. Маршрутизатор подключен к сети Интернет через интерфейс с именем WAN и имеет адрес 1.1.1.1
  2. Маршрутизатор подключен к локальной сети через интерфейс LAN и имеет адрес 192.168.88.1/24
  3. Необходимо опубликовать (сделать видимым из Интернет) web-сервер с адресом 192.168.88.2, протоколом tcp и портом 80.
  4. Необходимо опубликовать (сделать видимым из Интернет) терминал сервер с адресом 192.168.88.3. С целью безопасности заменить внешний порт на порт 53389, оставив внутренний порт 3386 (ассиметричная публикация порта).
  5. Необходимо опубликовать (сделать видимым из Интернет) телефонный сервер имеющий адрес 192.168.88.4, работающий по протоколу UDP с диапазонами портов 5060-5070 и 10000-20000
  6. Так как в сети возможно появление пользователей с произвольно настроенными DNS-серверами, независимо от настроек, распознаванием имен должен заниматься маршрутизатор.

Итак поехали.

В общем и целом для реализации п. 1 достаточно создать правило вида:

/ip firewall nat
add action=masquerade chain=srcnat out-interface=WAN
 

Суть правила. Если исходящий интерфейс=WAN, то заменить адрес отправителя первым адресом интерфейса, назначив порт динамически. Весьма универсально, особенно, если у вас адрес на WAN выдается динамически.

Теперь опубликуем web-сервер. Это работа с цепочкой dst-nat.

/ip firewall nat
add action=dst-nat chain=dstnat dst-port=80 in-interface=WAN protocol=tcp to-addresses=192.168.88.3
 

Так как у нас один внешний адрес, нам для однозначного определения пакета достаточно знать порт, протокол и с какого интерфейса пакет пришел.

Усложненный вариант п.2. Публикация терминального сервера с изменением порта назначения.

/ip firewall nat
add action=dst-nat chain=dstnat dst-port=53389 in-interface=WAN protocol=tcp to-addresses=192.168.88.4 to-ports=3389
 

Обратите внимание, что добавляется поле to-ports, которое сообщает маршрутизатору, что необходимо кроме адреса, так же изменить порт назначения.

Теперь еще более сложная задача. Нужно опубликовать два больших диапазона портов. Решение, как ни странно простое.

/ip firewall nat
add action=dst-nat chain=dstnat dst-port=5060-5070,10000-20000 in-interface=WAN protocol=udp to-addresses=192.168.88.5
 

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

Ну и наконец принудительно заставляем всех пользоваться DNS-сервером маршрутизатора.

/ip firewall nat
add action=redirect chain=dstnat dst-port=53 in-interface=LAN protocol=udp
 

Основной ошибкой при настройке NAT является отсутствие указания адреса и/или интерфейса, с которого приходит пакет в случае dst-nat или с которого уходит пакет в случае src-nat.

Например, правило указанное в п.1, если из него убрать out-interface будет выглядеть так:

/ip firewall nat
add action=masquerade chain=srcnat
 

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

Вторым вариантом не столько ошибки, сколько потенциальной ошибкой, является использование NAT в качестве фильтра пакетов.

Вторым вариантом не столько ошибки, сколько потенциальной ошибкой, является использование NAT в качестве фильтра пакетов.

Например, мы хотим чтобы web-сервер опубликованный в п.2 был доступен только с адреса 2.2.2.2 и как следствие создаем правило:

/ip firewall nat
add action=dst-nat chain=dstnat dst-port=80 in-interface=WAN protocol=tcp src-address=2.2.2.2 to-addresses=192.168.88.3
 

С точки зрения работы, в этом правиле будет все корректно. Но вот вероятность ошибки в сложных конфигурациях возрастет. Так как вам придется учитывать, что кроме фильтров файрволла, Вы еще дополнительно фильтруете трафик в NAT.

Кроме того, в первой части статьи посвященной NAT, я обратил Ваше внимание, что NAT обрабатывает только первый пакет соединения.

В этой статье мы рассмотрели наиболее типичные конфигурации NAT. В следующих частях статьи мы рассмотрим более сложные варианты конфигураций.

Технический директор Илья Князев (MTCNA, MTCWE, MTCTCE)

поделиться материалом:

Читайте также

комментарии — 0