Сравнение Закладки
Бесплатно по России:
8 800 700 97 66
Санкт-Петербург:
8 812 385 40 55
Перезвонить вам?

NAT. Часть 2.

Итак, мы с Вами добрались до настройки 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. В общем и целом для реализации п. 1 достаточно создать правило вида:

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

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

2. Теперь опубликуем 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

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

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, которое сообщает маршрутизатору, что необходимо кроме адреса, так же изменить порт назначения.

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

  • /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

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

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 в качестве фильтра пакетов.

Например, мы хотим чтобы 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)

Другие статьи цикла:

13405
Комментарии (3)

Дмитрий28.12.2015

а чем плоха смена адреса отправителя на адрес микротика?

ответить
Сменить картинку

Евгений13.03.2016

А зачем это делать внутри локальной сети? Например, при просмотре списка папок с соседнего компа... Не говоря уже о СИЛЬНО возросшей нагрузке на аппарат.

ответить
Сменить картинку

Илья Князев23.03.2016

Вот представьте ситуацию.
У вас опубликован SMTP-сервер. И вы написали некорректный masquerade
Тогда ваш сервер будет получать все запросы с адреса роутера. И, если у вас вклюен релей на локальную сеть, вы получите Open Relay.

ответить
Сменить картинку
Комментировать
Сменить картинку
все события