Допустим мы имеем конфигурацию, когда в вашей офисной или домашней сети есть веб-сервер. На него из-вне проброшен 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 и т.д.).
ps не смог почему то вставить ссылку... пришлось скопировать текст - ссылка на оригинал хтппс: galaxydata.ru/community/nat-mikrotik-dostup-k-wan-iz-lokalnoy-seti-hairpin-nat-dostu-577
