+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Hairpin NAT — проще простого

Hairpin NAT — проще простого, RouterOS

erkexzcx

Guest

07.02.2021 14:54:00

Решил написать простой гайд по Hairpin NAT, потому что многие пользователи не могут разобраться, как это настроить. Я не сетевой специалист и открыт к любой критике по поводу того, как это можно сделать лучше. Официальная страница wiki от Mikrotik по Hairpin NAT: https://wiki.mikrotik.com/wiki/Hairpin_NAT

Шаг 1 — добавляем LAN в “address-list”
Перечисляем все свои LAN вот так:
/ip firewall address-list add address=192.168.10.0/24 comment=Management list=LANs
/ip firewall address-list add address=192.168.11.0/24 comment=Work list=LANs
/ip firewall address-list add address=192.168.12.0/24 comment=Security list=LANs
/ip firewall address-list add address=192.168.13.0/24 comment=Home list=LANs
/ip firewall address-list add address=192.168.14.0/24 comment=Guest list=LANs

Шаг 2 — добавляем WAN в “address-list”
Если у вас один динамический IP — добавьте ваш домен из “/ip cloud” в адрес-лист под названием “WANs”, и Mikrotik сам будет разрешать его в IP. Другой вариант — использовать кастомный скрипт в “/ip dhcp-client”, чтобы автоматом обновлять IP WAN в списке.
Если у вас несколько WAN — тут всё немного сложнее. Я написал простое решение для нескольких динамических WAN здесь: http://forum.mikrotik.com/t/hairpin-with-2-wan/145618/1
Перечисляем все WAN вот так:
/ip firewall address-list add address=123.123.123.123 list=WANs

Шаг 3 — отмечаем соединения с LAN на WAN
Используйте это правило:
/ip firewall mangle add action=mark-connection chain=prerouting comment="Mark connections for hairpin NAT" dst-address-list=WANs new-connection-mark="Hairpin NAT" passthrough=yes src-address-list=LANs

Шаг 4 — применяем Hairpin NAT
Правило, которое ставим перед всеми остальными NAT:
/ip firewall nat add action=masquerade chain=srcnat comment="Hairpin NAT" connection-mark="Hairpin NAT" place-before=0

Шаг 5 — проброс портов
Настраиваем проброс портов вот так:
/ip firewall nat add action=dst-nat chain=dstnat comment="Port forward: something1" dst-address-list=WANs dst-port=5001 protocol=tcp to-addresses=192.168.0.8 to-ports=5001
/ip firewall nat add action=dst-nat chain=dstnat comment="Port forward: something2" dst-address-list=WANs dst-port=5002 protocol=tcp to-addresses=192.168.0.9 to-ports=5002

anav

Guest

29.07.2021 14:33:00

Не всё так просто с darknate. Верно, что нужно добавить одно правило source NAT, как описано в вашем линке, в начале цепочки source NAT, но это не обязательно касается связанного правила DSTNAT. Правило DSTNAT зависит от того, статический у провайдера WAN IP или динамический. Абсолютно верно, если WAN IP статический — то достаточно только правила source NAT, но если WAN IP динамический, то есть минимум три варианта. Поэтому я предпочитаю рекомендовать этот линк для читателей (без предвзятости): http://forum.mikrotik.com/t/forward-external-ip-address-of-router-port-22-to-internal-machine/148943/3. Что бы мне хотелось — чтобы rextended развернул этот метод, потому что он не совсем очевиден для таких простых смертных, как мы, кто только учится RoS!

rextended

Guest

29.07.2021 14:50:00

Пожалуйста, игнорируйте грамматические ошибки и любые вопросы, связанные с безопасностью или ограничением доступа.

Пример 1) Внутренний веб-сервер доступен по всему миру через www.vattelappesca.rex. Все публичные DNS разрешают www.vattelappesca.rex в публичный IP 123.45.67.89. Этот IP не находится напрямую на RouterBOARD, а находится >ВНУТРИ< одной из внутренних сетей RouterBOARD. NAT не требуется, так как это публичный IP. Доступ с внутренней локальной сети без NAT: ДА. NAT для этого не нужен.

Пример 2) Внутренний веб-сервер доступен по всему миру через www.vattelappesca.rex. Все публичные DNS разрешают www.vattelappesca.rex в публичный IP 123.45.67.89. Этот IP — один из IP на RouterBOARD, и он перенаправляется через dst-nat на один из внутренних IP RouterBOARD (например, 192.168.68.92). dst-NAT необходим, так как это приватный IP и он не маршрутизируется в публичной сети. Доступ с внутренней локальной сети при использовании DNS или публичного IP без src-NAT: НЕТ, сейчас не время снова объяснять почему, но src-NAT нужен, чтобы веб-сервер корректно отвечал устройству. Доступ с внутренней локальной сети, используя ТОЛЬКО приватный IP без NAT: ДА.

Пример 3) Внутренний веб-сервер доступен по всему миру через www.vattelappesca.rex. Все публичные DNS разрешают www.vattelappesca.rex в публичный IP 123.45.67.89. Этот IP — один из IP на RouterBOARD и перенаправляется через dst-nat на один из внутренних IP RouterBOARD (например, 192.168.68.92). dst-NAT необходим, потому что это приватный IP, который не маршрутизируется в публичной сети. НО внутренний веб-сервер доступен локально через www.vattelappesca.rex без NAT, потому что в локальном DNS домен разрешается в 192.168.68.92. Доступ с внутренней локальной сети без NAT: ДА. Если это моя сеть, я уже настроил на всех машинах через DHCP или вручную, чтобы все DNS разрешались напрямую с RouterBOARD, и добавил статическую регулярную DNS-запись “(^|www.)vattelappesca.rex$” => 192.168.68.92, что решает проблему без использования NAT. И SSL-сертификат не выдает ошибок, так как проверяет домен, а не IP.

anav

Guest

29.07.2021 15:29:00

Ах, ты вспомнил! Был способ направлять запросы внутри сети через DNS прямо на сервер, не используя NAT. Прости, что так смутно объясняю. Значит, есть четвертый способ, давай сосредоточимся на реальной ситуации 2: публичный IP, приватный IP сервера и метод через DNS... Единственное, что я нашел по этому поводу, было вот что: с hairpinNAT никаких сложностей — это всего лишь одно правило. Настроил и забыл. Очень удобно. У тебя есть внутренний сервер, и ты делаешь его доступным всему миру (через dstnat) как somehostname.domain.tld. По умолчанию оно работает для всех, кроме тебя (когда ты в той же локальной сети). Значит, ты либо напрямую подключаешься к внутреннему адресу, либо, если протокол зависит от имени хоста (например, http), нужно добавить переопределение DNS — либо в роутере, либо в локальном hosts файле. Hosts файл — плохое решение, потому что придётся менять его каждый раз, когда переходишь из внешней сети во внутреннюю и обратно. Статическая DNS-запись в роутере чуть лучше, но она работает только если устройство использует роутер как резолвер. А если у тебя устройство с жестко прописанным внешним DNS — опять не работает. Добавляешь еще одно имя хоста на сервер и снова нужно всё менять. Удаляешь имя хоста с сервера, ставишь его куда-то ещё, и в своей локальной сети наблюдай, как всё ломается, потому что забыл удалить статическую запись в роутере, и там всё ещё указывает на старый внутренний сервер. Либо поставь универсальное правило hairpinNAT и забудь обо всех этих заморочках навсегда.

rextended

Guest

29.07.2021 15:40:00

Нет… просто открой, скопируй, измени, сохрани одну статическую DNS-запись. В чём проблема? Я открываю роутер и удаляю статическую запись, я не провожу весь день, перемещая хосты… Если хост исчез из сети, он больше не под моим контролем, так что не важно, смогут ли внутренние ПК к нему подключиться… Просто на NAT я перехватываю все DNS-запросы, которые не направлены на локальный роутер, и перенаправляю их на DNS RouterOS… Это ещё и помогает, если в настройках DNS вручную указаны неправильные адреса…

anav

Guest

11.08.2021 13:52:00

Подытоживая и чтобы было понятнее для новичков… Нельзя менять текущие настройки DNS у DHCP-сервера (обычно это шлюз каждой подсети, как вы и сказали — решается через RouterBOARD, то есть это не работает, если в DHCP-сервере прописаны прямые внешние DNS, например 1.1.1.1 или 8.8.8.8). Неясно, если в IP DNS разрешены удалённые запросы и в поле «Servers» (то, что выше динамических серверов) что-то указано — не отменяет ли это весь этот метод? Нужно создать статическую DNS-запись с использованием REGEX, что бы это ни значило. Сначала казалось, что это нужно делать на уровне Layer 7 в IP-фильтре, но оказалось, что Regexp есть и в настройках IP DNS под кнопкой «Static». Предполагаю, что именно здесь вводится правило/текст. Правило, похоже, гласит: если пользователь вводит указанный адрес (имя dynDNS), он должен разрешаться в приватный IP сервера через DNS (вместо NAT). Потом что-то говорится про ssl безопасность, но как это используется и вызывается — непонятно.

Нужно прояснить:
- какие ограничения есть на другие настройки DNS — что можно, а что нельзя менять;
- где именно вводится правило/текст;
- как именно работает и используется ssl безопасность.

rextended

Guest

11.08.2021 14:14:00

Без layer7, hairpin NAT и других наворотов. Просто сделайте вот так, например, RouterBOARD с адресом 192.168.88.1, локальный сервер www.vattelappesca.rex с адресом 192.168.88.68… Это НE ЛАМАЕТ SSL-сертификат.

/ip dns static
add address=192.168.88.68 regexp="(^|www\\.)vattelappesca\\.rex\$" ttl=5m

/ip firewall nat
add chain=dstnat src-address=!192.168.88.1 dst-address=!192.168.88.1 dst-port=53 protocol=udp action=dst-nat to-addresses=192.168.88.1
add chain=dstnat src-address=!192.168.88.1 dst-address=!192.168.88.1 dst-port=53 protocol=tcp action=dst-nat to-addresses=192.168.88.1

Это перехватывает все DNS-запросы, кроме тех, что идут от RouterBOARD или уже адресованы к нему. Такая настройка NAT позволяет использовать любые устройства, даже если у них в настройках DNS прописан неправильный адрес.

anav

Guest

11.08.2021 22:17:00

Хорошо, понял, но ты так и не объяснил ограничения, которые нужны, чтобы это работало с настройками DHCP-сервера для каждой подсети, если это применимо? Разрешить ввод DNS-серверов удалённого DNS-бокса (выше динамических серверов).

rextended

Guest

11.08.2021 22:33:00

Вы можете добавить список адресов вместо одного исключённого IP для перехвата, как источник и как назначение, например, для pihole? Да, вы всё ещё можете добавить это и разрешать внутри pihole DNS с локальным IP, пожалуйста, объясните, я не понимаю. Вы имеете в виду динамический или статический DNS, настроенный в /ip dns? Этот DNS использует цепочки input/output, а не forward, и остаётся без изменений. Статический DNS имеет приоритет над любым другим способом, которым RouterBOARD может получать DNS (сначала статический, затем статический с regex, затем остальные).

anav Guest	#10 0 12.08.2021 01:39:00 Спасибо, теперь понятно! Значит, если у меня такая ситуация: /ip dhcp-server network add address=192.168.0.0/24 dns-server=1.1.1.1 gateway=192.168.0.1 IP static DNS 192.168.0.1 — роутер не будет использовать 1.1.1.1 для DNS-запросов с подсети 192.168.0.1???

rextended

Guest

#11

12.08.2021 07:39:00

В команде /ip dhcp-server network
add address=192.168.0.0/24 dns-server=1.1.1.1 gateway=192.168.0.1 вы указываете DNS 1.1.1.1, который "предлагается" внутреннему DHCP-клиенту и получается им автоматически, вместо того чтобы настраивать вручную, если только клиент не использует жестко прописанный DNS (например, Android использует 8.8.8.8 и 8.8.4.4 вместо DNS, который выдает DHCP, и только если вы заблокируете 8.8.8.8 и 8.8.4.4, он начнёт использовать DNS из DHCP).

Если в параметрах DHCP-сети не указать DNS, при включённой опции "allowed remote request" в /ip dhcp сервер предложит IP роутера (192.168.0.1), иначе предложит DNS, указанные в /ip dns servers.

Единственный способ заставить RouterBOARD использовать 1.1.1.1 — прописать его в /ip dns servers как единственный DNS-сервер.

Нельзя выбрать, какой DNS RouterBOARD будет использовать для каждой подсети.

anav Guest	#12 0 12.08.2021 15:01:00 Из этого сообщения невозможно составить блок-схему, оно разбросано повсюду... Думаю, главный барьер — язык. Напишите это по-итальянски, и я переведу.

rextended

Guest

#13

13.08.2021 20:00:00

/ip dhcp-server network
add address=192.168.0.0/24 dns-server=1.1.1.1 gateway=192.168.0.1

Нельзя указать с помощью этой команды, какой DNS должен использовать Routerboard для каждой подсети. Если DNS-сервер не указан, через DHCP всё равно отправляется один из тех, что уже прописаны в разделе “/ip dns” на роутерборде. Если включена опция “allowed-remote-request” в “/ip dns”, то в отсутствии указанного dns-server RouterBOARD отправляет свой собственный IP.

Эта команда просто сообщает компьютерам, которые получают DHCP, какой DNS им использовать, но они не обязаны это делать. Например, в Android встроены DNS 8.8.8.8 и 8.8.4.4, и единственный способ заставить их использовать ваши DNS — заблокировать 8.8.8.8 и 8.8.4.4 в файрволе, если запросы приходят из локальной сети.

Единственный способ заставить RouterBOARD использовать IP 1.1.1.1 в качестве DNS — задать его в “/ip dns servers” как единственный DNS.

anav Guest	#14 0 16.08.2021 10:00:00 Хорошо, позвольте задать вопрос иначе. Какая настройка DNS, сделанная администратором, помешала бы работе вашего метода hairpin NAT?

rextended

Guest

#15

16.08.2021 13:04:00

Поскольку это не метод hairpin NAT, а просто лучший способ настроить сеть, когда возникает такая необходимость (обратиться к внутреннему серверу, находящемуся в другой подсети, через действительный публичный DNS), единственное, что может помешать — это SSH-сертификат, основанный на IP-адресе (вместо сертификата на имя хоста). Или какое-то устройство, использующее внешний DoH или DoT, но поскольку речь идет о сознательном усложнении доступа к собственному адресу, я не думаю, что кто-то сам себе ставит палки в колёса…

anav

Guest

#16

11.09.2021 12:48:00

/ip dns static add address=192.168.88.68 regexp="(^|www\.)vattelappesca\.rex$" ttl=5m
/ip firewall nat add chain=dstnat src-address=!192.168.88.1 dst-address=!192.168.88.1 dst-port=53 protocol=udp action=dst-nat to-addresses=192.168.88.1
add chain=dstnat src-address=!192.168.88.1 dst-address=!192.168.88.1 dst-port=53 protocol=tcp action=dst-nat to-addresses=192.168.88.1

Хорошо, я понял часть, выделенную зелёным. Это, по сути, значит, что любой запрос из локальной сети на поиск этого домена должен быть перенаправлен на сервер. Но зачем, черт побери, ты добавил эту правило NAT ниже? Они меня просто напросто сбивают с толку.

Halfeez92

Guest

#17

21.02.2021 17:33:00

Спасибо за инструкцию, но я сделал это немного по-другому, поэтому мне не нужен hairpin nat. Моя конфигурация выглядит так:
/ip firewall nat add action=dst-nat chain=dstnat comment="Port forward" dst-port=5001 protocol=tcp dst-address-type=local dst-address-list=!router to-addresses=192.168.0.8 to-ports=5001

При этом список адресов под названием «router» — это адреса шлюза вашего роутера из /ip address. С такой настройкой правило hairpin nat вообще не требуется.

anav

Guest

#18

25.02.2021 17:39:00

Существует несколько способов решения проблемы hairpin NAT. Поймите, что hairpin NAT — это ситуация, когда администратор хочет, чтобы локальные пользователи, находящиеся В ТОЙ ЖЕ подсети LAN, что и сервер, обращались к серверу НЕ по его LAN IP-адресу, а по публичному IP-адресу роутера. Простое и удобное решение этой проблемы (часто называемой loopback на других устройствах) — просто разместить сервер в отдельной подсети. {решено}. Обычные правила destination NAT при этом будут прекрасно работать.

DarkNate Guest	#19 0 27.07.2021 11:39:00 Зачем делать такую запутанную конфигурацию? Один NAT-правило вполне способно эффективно выполнять hairpin NAT.

rextended Guest	#20 0 27.07.2021 11:54:00 Я предпочитаю перехватывать все DNS-запросы (или использовать по умолчанию DNS на Routerboard) для «www.mypublicinternalserver.net» и сразу отвечать внутренним IP-адресом. Также там, где используется прямой публичный IP, его меняют на приватный. Всё готово, никаких проблем с NAT. Моя сеть, мои правила…

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры