Работа с NAT на маршрутизаторах Mikrotik
Общие моменты
Пример стандартной настройки
Частные случаи и ошибки
Netmap и с чем его едят
Hairpin NAT что за зверь?
Итак, добрый дядя Провайдер выделил нам неразумным несколько IP-адресов, которые мы спешим повесить на WAN-интерфейс нашего Микротика. Но большая сила - это и большая ответственность. Как правильно использовать данное нам свыше?
Допустим, пров выделил нам следующие IP:
И оба адреса мы назначили WAN-интерфейсу. Помимо прочего в нашем распоряжении две локальные подсетки с пулами 192.168.0.0/24 и 192.168.1.0/24, которые висят на интерфейсах LAN и DMZ.
Представим, что у вас просто необъяснимое желание использовать оба внешних IP-адреса для выхода из вашей локальной сети в интернет. Очевидно, что Action=masquerade для этих целей нам уже не подойдет, потому что данное действие будет использовать только один из адресов назначенных интерфейсу. Используем для решения данной задачки действие Action=same, а правило с ним будет выглядеть так:
Маршрутизатор в этом случае будет сначала использовать свободные порты для адреса 1.1.1.1, а когда они закончатся, то примется за свободные порты адреса 1.1.1.2
Необходимость в такой схеме может возникнуть, если в вашей локальной сети активно работает большое количество хостов.
Окей, с этим понятно. Теперь давайте перейдем к варианту посложнее. К примеру, мы хотим, чтобы компьютеры из локалки ходили в интернет через IP 1.1.1.1, а вся хостятина из DMZ - через 1.1.1.2.
В этом случае правил в NAT придется создать два:
Когда вы касаетесь работы с Destination NAT, то всегда учитывайте, что правило без явного указания адреса назначения будет обрабатывать любые пакеты, без учета на какой внешний адрес он придет.
Вот допустим, мы запиливаем web-сервер с локальным IP 192.168.1.2 и создаем следующее правило:
Теперь пакеты пришедшие на любой из ваших внешних адресов по порту TCP80 будут обработаны вашим локальным web-сервером. А если у вас есть еще один сервак с IP 192.168.1.3? Тогда следует сделать например так, что сервак на локальном адресе 192.168.1.2 будет доступен по IP 1.1.1.1, а висящий на 192.168.1.3 - через 1.1.1.2
Как-то так:
И в этом случае потребуются два правила:
Учтите, что в случае с dst-nat нужно самым что ни на есть явным образом указывать либо входящий интерфейс (in-interface), либо адрес назначения (dst-address). Можно указывать и то, и другое.
Если не устанавливать подобное ограничение и создать что-то вроде:
То теперь любой ПК из вашей локальной сети обращаясь опять таки к любому серверу в интернете по 80-му порту попадет на 80-ый порт вашего же веб-сервера.
Еще интереснее будет, если вы не укажете интерфейс в правиле Source NAT с действием Action=masquerade.
А приведет это к тому, что все пакеты будут иметь адрес источника тождественный адресу интерфейса маршрутизатора, из которого вышел этот пакет. И если у вас в сети проживает, например, опубликованный в интернет почтовый сервер поддерживающий релей для адресов из локальной сети, то вы получите натуральный Open Relay (привет спам-боты) просто накосячив в src-nat. Такое получится с SMTP-сервером 192.168.1.4 при следующей настройке NAT:
Следуя данному примеру, если маршрутизатор имеет IP 192.168.1.1, то SMTP-сервер будет воспринимать любые внешние подключения как локальные, что грозит вам скорым попадание в спам-листы.
А если вы таким образом откроете в интернет IP-АТС, то с большой долей вероятности получите бешеный счет на международную связь.
Общие моменты
Пример стандартной настройки
Частные случаи и ошибки
Netmap и с чем его едят
Hairpin NAT что за зверь?
Пример стандартной настройки
Частные случаи и ошибки
Netmap и с чем его едят
Hairpin NAT что за зверь?
Итак, добрый дядя Провайдер выделил нам неразумным несколько IP-адресов, которые мы спешим повесить на WAN-интерфейс нашего Микротика. Но большая сила - это и большая ответственность. Как правильно использовать данное нам свыше?
Допустим, пров выделил нам следующие IP:
1.1.1.1/24 и 1.1.1.2/24И оба адреса мы назначили WAN-интерфейсу. Помимо прочего в нашем распоряжении две локальные подсетки с пулами 192.168.0.0/24 и 192.168.1.0/24, которые висят на интерфейсах LAN и DMZ.
Source NAT
Представим, что у вас просто необъяснимое желание использовать оба внешних IP-адреса для выхода из вашей локальной сети в интернет. Очевидно, что Action=masquerade для этих целей нам уже не подойдет, потому что данное действие будет использовать только один из адресов назначенных интерфейсу. Используем для решения данной задачки действие Action=same, а правило с ним будет выглядеть так:
/ip firewall nat add action=same chain=srcnat out-interface=WAN to-addresses=1.1.1.1-1.1.1.2Маршрутизатор в этом случае будет сначала использовать свободные порты для адреса 1.1.1.1, а когда они закончатся, то примется за свободные порты адреса 1.1.1.2
Необходимость в такой схеме может возникнуть, если в вашей локальной сети активно работает большое количество хостов.
Окей, с этим понятно. Теперь давайте перейдем к варианту посложнее. К примеру, мы хотим, чтобы компьютеры из локалки ходили в интернет через IP 1.1.1.1, а вся хостятина из DMZ - через 1.1.1.2.
В этом случае правил в NAT придется создать два:
/ip firewall nat
add action=src-nat chain=srcnat out-interface=WAN src-address=192.168.0.0/24 \
to-addresses=1.1.1.1
add action=src-nat chain=srcnat out-interface=WAN src-address=192.168.1.0/24 \
to-addresses=1.1.1.2Destination NAT
Когда вы касаетесь работы с Destination NAT, то всегда учитывайте, что правило без явного указания адреса назначения будет обрабатывать любые пакеты, без учета на какой внешний адрес он придет.
Вот допустим, мы запиливаем web-сервер с локальным IP 192.168.1.2 и создаем следующее правило:
/ip firewall nat
add action=dst-nat chain=dstnat dst-port=80 in-interface=WAN protocol=tcp \
to-addresses=192.168.1.2Теперь пакеты пришедшие на любой из ваших внешних адресов по порту TCP80 будут обработаны вашим локальным web-сервером. А если у вас есть еще один сервак с IP 192.168.1.3? Тогда следует сделать например так, что сервак на локальном адресе 192.168.1.2 будет доступен по IP 1.1.1.1, а висящий на 192.168.1.3 - через 1.1.1.2
Как-то так:
И в этом случае потребуются два правила:
/ip firewall nat
add action=dst-nat chain=dstnat dst-address=1.1.1.1 dst-port=80 protocol=tcp \
to-addresses=192.168.1.2
add action=dst-nat chain=dstnat dst-address=1.1.1.2 dst-port=80 protocol=tcp \
to-addresses=192.168.1.3Учтите, что в случае с dst-nat нужно самым что ни на есть явным образом указывать либо входящий интерфейс (in-interface), либо адрес назначения (dst-address). Можно указывать и то, и другое.
Если не устанавливать подобное ограничение и создать что-то вроде:
/ip firewall nat add action=dst-nat chain=dstnat dst-port=80 protocol=tcp to-addresses=192.168.1.2То теперь любой ПК из вашей локальной сети обращаясь опять таки к любому серверу в интернете по 80-му порту попадет на 80-ый порт вашего же веб-сервера.
Еще интереснее будет, если вы не укажете интерфейс в правиле Source NAT с действием Action=masquerade.
А приведет это к тому, что все пакеты будут иметь адрес источника тождественный адресу интерфейса маршрутизатора, из которого вышел этот пакет. И если у вас в сети проживает, например, опубликованный в интернет почтовый сервер поддерживающий релей для адресов из локальной сети, то вы получите натуральный Open Relay (привет спам-боты) просто накосячив в src-nat. Такое получится с SMTP-сервером 192.168.1.4 при следующей настройке NAT:
/ip firewall nat
add action=dst-nat chain=dstnat dst-port=25 in-interface=WAN protocol=tcp to-addresses=\ 192.168.1.4
add action=masquerade chain=srcnatСледуя данному примеру, если маршрутизатор имеет IP 192.168.1.1, то SMTP-сервер будет воспринимать любые внешние подключения как локальные, что грозит вам скорым попадание в спам-листы.
А если вы таким образом откроете в интернет IP-АТС, то с большой долей вероятности получите бешеный счет на международную связь.
Общие моменты
Пример стандартной настройки
Частные случаи и ошибки
Netmap и с чем его едят
Hairpin NAT что за зверь?
