Примерно 10% запросов в нашу техподдержку таки или иначе связаны с темой этой статьи.
Итак, что такое Hairpin NAT и зачем он нужен.
Данная конфигурация обычно требуется, если Вы опубликовали на внешнем адресе (dst-nat) сервер, и Вам необходимо чтобы он был доступен по внешнему адресу изнутри сети.
Начнем с базовой конфигурации сети.
- Вы имеете IP адрес 1.1.1.1/24 на интерфейсе WAN вашего маршрутизатора
- Вы имеете IP адрес 192.168.0.1/24 на интерфейсе LAN вашего маршрутизатора.
- Вы имеете www-сервер с адресом 192.168.0.10 в LAN сегменте.
- Адрес вашего компьютера находится в диапазоне адресов LAN. Для примера пусть это будет 192.168.0.5
Схема
Вполне логично? что для того, чтобы опубликовать web-сервер на внешнем интерфейсе, Вы создаете правило dst-nat следующего вида:
/ip firewall nat add action=dst-nat chain=dstnat dst-address=1.1.1.1 dst-port=80 protocol=tcp \ to-addresses=192.168.0.10
Обратите внимание, что в правиле не указан in-interface, так как правило должно срабатывать при обращении на 80 порт адреса 1.1.1.1 с любого интерфейса.
Вы это делаете и..
И у вас все замечательно работает снаружи сети (при обращении из Интернет), но обращение с вашего компьютера по адресу http://1.1.1.1 говорит «Нет ответа от сервера». Для того, чтобы понять, что же происходит, рисуем схему прохождения и преобразования пакета:
Теперь распишем что происходит на каждом этапе.
Этап 1
Компьютер с адреса 192.168.0.5 пытается установить соединение с адресом 1.1.1.1 по 80 порту и отправляет пакет на маршрутизатор.
Этап 2
На маршрутизаторе срабатывает правило dst-nat, в результате чего адрес назначения пакета меняется на 192.168.0.10, и пакет отправляется на www-сервер 192.168.0.10.
Этап 3
Узел 192.168.0.10 получив пакет с адресом источника 192.168.0.5, определяет, что они оба находятся в одной локальной сети и отвечает ему напрямую, минуя маршрутизатор.
Проблема
Компьютер, отправив пакет на адрес 1.1.1.1, вдруг получает ответ с адреса 192.168.0.10. Естественно этот пакет он игнорирует и соединение не устанавливается.
Решение
Чтобы решить эту проблему, необходимо, чтобы www-сервер получил пакет у которого адрес источника будет равен адресу маршрутизатора.
Добавляем к нашей конфигурации правило, которое заменит адрес отправителя, адресом интерфейса маршрутизатора и получаем следующую конфигурацию:
/ip firewall nat add action=dst-nat chain=dstnat dst-address=1.1.1.1 dst-port=80 protocol=tcp to-addresses=192.168.0.10 add action=masquerade chain=srcnat dst-address=192.168.0.10 dst-port=80 protocol=tcp src-address=192.168.0.0/24
Теперь у нас из конфигурация работает правильно. Схема для понимания:
Работа схемы
Этап 1
Компьютер с адреса 192.168.0.5 пытается установить соединение с адресом 1.1.1.1 по 80 порту и отправляет пакет на маршрутизатор.
Этап 2
На маршрутизаторе срабатывает правило dst-nat, в результате чего адрес назначения пакета меняется на 192.168.0.10 и правило src-nat, где адрес источника пакета меняется на адрес интерфейса маршрутизатора (192.168.0.1). После чего пакет отправляется на www-сервер 192.168.0.10.
Этап 3
Узел 192.168.0.10 получив пакет с адресом источника 192.168.0.1 (адрес маршрутизатора), определяет, что они оба находятся в одной локальной сети и отвечает ему. В результате чего пакет попадает на маршрутизатор
Этап 4
Connection Tracker маршрутизатора получив такой пакет выполняет обратное преобразование адресов. Компьютер получает ожидаемый ответ с адреса 1.1.1.1
Вот такая схема трансляции адресов и является Hairpin NAT.
Нужно отметить что у схемы есть недостаток. Заключается он в том, что публикуемый сервер будет получать запросы от хостов локальной сети с адреса маршрутизатора. Что не всегда хорошо. Например, если Вы так опубликуете прозрачный proxy-сервер, вряд ли у вас получится собрать нормальную статистику.
Альтернативой такой схемы могут служить.
1. Вынос публикуемых, или вообще всех серверов в отдельную подсеть. 2. Использование так называемого split-dns. Когда компьютер находясь снаружи сети на запрос www.mydomain.com получит адрес 1.1.1.1, а находясь внутри сети на этот же запрос получит адрес 192.168.0.10.
На этом я заканчиваю цикл статей про NAT на MikroTik. Надеюсь, что сумел описать все основные моменты работы NAT на маршрутизаторах MikroTik. Буду рад комментариям!
Статья написана сертифицированным тренером MikroTik Князевым И.Н., технический директор.