Допустим мы имеем конфигурацию, когда в вашей офисной или домашней сети есть веб-сервер. На него из-вне проброшен 80 порт. Ваши клиенты могут заходить на ваш домен domain.ru, который имеет внешний IP185.173.153.2 с переадресацией через Mikrotik на web-сервер 192.168.1.99. Визуально такое правило выглядит так:

/ip firewall nat
add chain=dstnat dst-address=185.173.153.2 protocol=tcp dst-port=22 action=dst-nat to-address=192.168.1.99

Все запросы с внешнего IP 1.1.1.1 на 80 порт направлять на наш веб-сервер. Второе правило – обычный NAT для нашей внутренный сети:

add chain=srcnat out-interface=bridge action=masquerade

Когда внешний клиент с WAN-интерфейса совершает подключение к нашему веб-серверу это выглядит так:

Внешний клиент посылает пакет с IP-адресом источника 2.2.2.2 (IP внешнего клиента) на IP-адрес назначения 185.173.153.2 (IP резольва нашего ресурса domain.ru) на порт TCP / 22 для запроса веб-ресурса.
Пакет попадает в NAT маршрутизатора, роутер заменяет IP назначения на 192.168.1.99. Источник IP-адрес остается прежним: 2.2.2.2.
Сервер отвечает на запрос клиента. Пакет имеет IP-адрес источника 192.168.1.99 и IP-адрес назначения 2.2.2.2.
Маршрутизатор определяет, что пакет является частью предыдущего соединения, применяет NAT (помещает исходный IP-адрес назначения в поле IP-адрес источника). IP-адрес назначения 2.2.2.2, а источник IP-адре с185.173.153.2 .

Клиент получает ответный пакет который он ожидает – соединение установлено. Такая схема рабочая.

Проблемы начинаются тогда, когда клиент (источник пакета) находится внутри вашей сети. Например, на ваш веб-сервер, на домен domain.ru, который разрешается DNS как 185.173.153.2 хочет зайти клиент с адресом 192.168.1.10, который находится в одной подcети с нашим веб-сервером, который имеет IP 192.168.1.99 (подсеть 192.168.1.0/24).

Клиент посылает пакет с IP-источником 192.168.1.10 на IP-адрес назначения 1.1.1.1 на порт TCP / 80 для запроса веб-ресурса.
В NAT маршрутизатор пакет назначения заменяет на 192.168.1.2, IP-адрес источника остается прежним: 192.168.1.10.
Сервер отвечает на запрос клиента. Так как IP-адрес источника запроса находится в той же подсети, что и веб-сервер, веб-сервер не отправляет ответ обратно к маршрутизатору, а отправляет его непосредственно на 192.168.1.10 с исходным IP-адресом в ответе – 192.168.1.2.
Фактически, клиент получает ответ не от того отправителя, от которого ожидает. Он отправлял пакет на маршрутизатор с IP 1.1.1.1 и должен получить от IP 1.1.1.1, а получил от IP 192.168.1.2. Этот пакет считается недействительным и связь не устанавливается, а страничка domain.ru не открывается.

Что-бы решить эту проблему нужно добавить еще одно правило в Mikrotik, для того что-бы весь ответ на нужных нам портах проходил через маршрутизатор.

/ip firewall nat
add chain=srcnat src-address=192.168.1.0/24 dst-address=192.168.1.99 protocol=tcp dst-port=22 out-interface=bridge action=masquerade

Рассмотрим этот вариант:
Клиент посылает пакет с IP-источником 192.168.1.10 на IP-адрес назначения 185.173.153.2 на порт TCP / 80 для запроса веб-ресурса.
В NAT маршрутизатор пакет назначения заменяет на 192.168.1.99. IP-адрес источника заменяет на IP-адрес LAN-порта маршрутизатора: 192.168.1.1.
Веб-сервер отвечает на запрос и отправляет ответ с источником 192.168.1.99 обратно в LAN интерфейс маршрутизатора – на 192.168.1.1.
Маршрутизатор определяет, что пакет является частью предыдущего соединения, разрешает NAT, помещает в источник IP 1.1.1.1 и отправляет пакет на 192.168.1.10.
Клиент получает ответный пакет тот, который он ожидает – соединение будет установлено. Нужно учитывать, что при такой схеме ваш веб-сервер всегда видит IP-источника 192.168.1.1 при подключении к нему внутренних клиентов из вашей сети.

Так же, стоит сказать, если вы в Mikrotik в статические записи ДНС добавите правило:

/ip dns static
add address=192.168.1.99 name=domain.ru

И ваши клиенты будут использовать роутер как DNS-сервер, то все пакеты, которые будут отправлены на domain.ru сразу зарезольвятся на адрес 192.168.1.2. Таким образом они попадут на веб-сервер минуя маршрутизатор, и ваш веб-сервер ответит напрямую компьютеру из сети, и пакет тоже отлично пройдет, и сайт откроется. Недостатком такого метода можно считать то, что большое количество сайтов добавлять в статический записи неудобно. Плюс при такой схеме обязательно нужно использовать Mikrotik как главный и единственный DNS-сервер.

В примере приведен образец с WEB-сервером, хотя эту схему можно использовать и для других сервисов и портов (например ftp, ssh и т.д.).

 

Большое спасибо блогу: http://mikrotik-ukraine.blogspot.ru/2016/11/hairpin-nat-ip.html

11 комментариев для “NAT MikroTik доступ к WAN из локальной сети, Hairpin NAT – доступ через внешний IP на свои ресурсы, находясь внутри сети.”
    1. Пакет пришел на роутер (по внешнему IP) что бы сервер его напрямую не отправил (минуя роутер), он пакет, должен дойти до сервака с измененным полем (адрес источника) а выходить он будет с интерфейса бриджа, поэтому при выходе пакета с этого интерфейса у него (у пакета) будет заменяться (адрес источника) на адрес роутера. И когда сервак будет отвечать на запрос он пошлет пакет роутеру а не напрямую компу который делает изначально запрос.

  1. Данное правило добавлено, для получения доступа к внешнему ресурсу IP адреса сервера в этой же локальной сети.

    К примеру наш IP компьютера: 192.168.1.10
    IP адрес сервера: 192.168.1.99

    На сервере 192.168.1.99 открыли 22 порт ssh.

    Мы хотим подключится к серверу не по локальному IP, а по внешнему к примеру 185.167.44.41. Тогда без правила
    /ip firewall nat
    add chain=srcnat src-address=192.168.1.0/24 dst-address=192.168.1.99 protocol=tcp dst-port=22 out-interface=bridge action=masquerade

    Мы не получим доступ к нашему внешнему IP в нашей локальной сети 192.168.1.0/24

  2. А как проделать такой же трюк если внешний IP выдается динамически, на каждую новую сессию соединения роутера с провайдером?

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

  4. А что посоветуете если схема такова.
    локальная-сеть1 – 192.168.1.0/24
    локальная-сеть2 – 192.168.2.0/24
    веб-сервер – 192.168.2.100
    внешний ИП 1.1.1.1

    Созданные правила :
    ;;; проброс портов 80,443
    chain=dstnat action=dst-nat to-addresses=192.168.2.100 protocol=tcp
    dst-address=1.1.1.1 dst-port=80,443 log=yes log-prefix=””

    ;;; scrnat
    chain=dstnat action=dst-nat to-addresses=192.168.2.100 protocol=tcp
    src-address=192.168.1.0/22 dst-address=1.1.1.1 dst-port=80,443 log=no
    log-prefix=””

    ;;; masquerade
    chain=srcnat action=masquerade protocol=tcp src-address=192.168.1.0/22
    dst-address=192.168.2.100 dst-port=443,80 log=no log-prefix=””

    При таком раскладе из подсети 192.168.2.0/24 пользователи могут зайти на веб-сайт по внешнему ИП, вто время как из 192.168.1.0/24 не работает!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.