Допустим мы имеем конфигурацию, когда в вашей офисной или домашней сети есть веб-сервер. На него из-вне проброшен 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
Почему в правиле «add chain=srcnat out-interface=bridge action=masquerade» указан «out-interface=bridge», а не «out-interface=WAN», например?
Пакет пришел на роутер (по внешнему IP) что бы сервер его напрямую не отправил (минуя роутер), он пакет, должен дойти до сервака с измененным полем (адрес источника) а выходить он будет с интерфейса бриджа, поэтому при выходе пакета с этого интерфейса у него (у пакета) будет заменяться (адрес источника) на адрес роутера. И когда сервак будет отвечать на запрос он пошлет пакет роутеру а не напрямую компу который делает изначально запрос.
Данное правило добавлено, для получения доступа к внешнему ресурсу 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
А как проделать такой же трюк если внешний IP выдается динамически, на каждую новую сессию соединения роутера с провайдером?
Для решения вашей задачи нужно использовать https://dynv6.com/
И скрипт — https://gist.github.com/stargieg/1b11d3df9cc6f9cb934037e6c474d618
Если нужна помощь в настройке то оставьте заявку на noc@galaxydata.ru
Отлично, помогло, спасибо 🙂
Если я захожу на сайт из вне, то в сё работает хорошо, но если я захожу из локальной сети по внешнему адресу, то всё ужасно тупит. Причём если зайду по локальному адресу, то всё так же прекрасно работает. В чём может быть дело?
Пришлите экспорт вашего конфига. Также какой у вас роутер используется?
Какой роутер у вас используется?
Пришлите ваш конфиг роутера через команду
export compact
А что посоветуете если схема такова.
локальная-сеть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 не работает!
Спасибо, помогли все работает!