LINUX.ORG.RU
решено ФорумAdmin

Hairpin NAT: Linux vs. RouterOS, или «что я делаю не так?»

 , ,


0

6

Добрый вечер, суровые админы.

В вики Mikrotik встречается такой термин, как «hairpin NAT». Это когда устройство, сидящее за NAT'ом, обращается к какому-то порту внешнего IP-адреса этого NAT'а, а шлюз (если на нём настроен форвардинг этого порта) перенаправляет запрос обратно во внутреннюю сеть.

(В принципе, это достаточно удобная фича: изнутри сети можно сделать, скажем, ssh domain.tld, и достучаться до SSH-сервера внутри этой самой сети, вместо того, чтобы вспоминать внутренний IP-адрес этого SSH-сервера или же поднимать свой локальный DNS.)

Так вот. Если шлюз — это Mikrotik RouterOS, то этот самый hairpin NAT по умолчанию не работает. Его нужно настраивать, загоняя в таблицы файрволла значительное количество неочевидных правил. С другой стороны, если шлюз — это GNU/Linux (скажем, OpenWRT), то описанный эффект присутствует совершенно из коробки.

Вопрос: почему? У RouterOS и GNU/Linux различные принципы функционирования файрволла? Или я что-то делаю не так? Или hairpin NAT — это моветон, и то, что оно работает в линуксе, является лишь совпадением/недоразумением/etc.?

★★★★★

Последнее исправление: intelfx (всего исправлений: 3)

Я еще нубее, но мне кажется, что разница только в принятости правила «SNAT всего, что изнутри, через какой надо интерфейс». При наличии или отсутствии этого правила и там и там — я не понял, в чем будет разница.

t184256 ★★★★★
()

В цысках, например, оно тоже не работает по-дефолту. Нужно ибаццо и настраивать.

На мой взгляд, никаких минусов особых в том, что оно работает сразу - нет. Меньше гемора админу.

blind_oracle ★★★★★
()

Не относу себя к суровым админам, но выскажу свое мнение.
Начать можно с того что просто «из коробки» hairpinning NAT видимо есть в OpenWRT, в GNU/Linux есть только то, что настроит администратор системы. Сам переводил небольшой офис с роутера Zyxel на софтварный шлюз, в Зухеле hairpinning NAT просто работал, в Linux все пришлось настраивать ручками. У hairpinning NAT определенно есть минусы, в частности весь трафик после него выглядит так, как будто происходит с IP шлюза, а не с IP LAN клиентов. Немого про hairpinning NAT есть здесь http://shorewall.net/FAQ.htm#DNS-DNAT. На мой личный взгляд плюс hairpinning NAT в том что с ним все работает «автомагически», и в этом же его минус, наличие подобной опции включенной по-умолчанию может помешать понять как же в реальности проходит трафик что может привести к проблемам в каких-то ситуациях.

Hatifnatt
()
Ответ на: комментарий от Hatifnatt

весь трафик после него выглядит так, как будто происходит с IP шлюза

Почему? Ведь речь о DNAT (подмене адреса назначения).
Или я не понял о чём речь?

MrClon ★★★★★
()
Ответ на: комментарий от MrClon

...А также SNAT, чтобы сервер отсылал ответ шлюзу, а не исходному хосту (ибо он с ним в одной подсети и имеет полное право так делать).

intelfx ★★★★★
() автор топика
Ответ на: комментарий от Hatifnatt

Начать можно с того что просто «из коробки» hairpinning NAT видимо есть в OpenWRT, в GNU/Linux есть только то, что настроит администратор системы.

В OpenWRT'шных таблицах (nat, mangle) ничего такого нет, но тем не менее оно работает. Может, не туда смотрю?

У hairpinning NAT определенно есть минусы, в частности весь трафик после него выглядит так, как будто происходит с IP шлюза, а не с IP LAN клиентов.

Т. е. вместо этого нужно вынести сервера в отдельную подсеть и всё будет работать? Или локальный DNS всё равно придётся поднимать?

intelfx ★★★★★
() автор топика
Ответ на: комментарий от Hatifnatt

Алсо, немного оффтопик, но связанный вопрос. Так или иначе — и при hairpin NAT, и при выносе сервера в отдельную подсеть — мы теоретически получаем падение производительности ввиду того, что теперь все запросы и ответы роутятся на уровне IP (L3), а не Ethernet (L2).

Это соображение в реальной жизни играет? Или падение производительности не будет заметно? Допустим, у нас есть дохрена быстрый файлсервер и не слишком мощный SOHO-роутер в качестве шлюза. Упрёмся в процессор или системную шину роутера?

intelfx ★★★★★
() автор топика
Ответ на: комментарий от intelfx

В OpenWRT'шных таблицах (nat, mangle) ничего такого нет, но тем не менее оно работает. Может, не туда смотрю?

Не работал с OpenWRT, не знаю как там в деталях все устроено, по логике должны быть правила которые обеспечивают данную функциональность.

Т. е. вместо этого нужно вынести сервера в отдельную подсеть и всё будет работать? Или локальный DNS всё равно придётся поднимать?

Я недостаточно суровый админ, поэтому в голове симулировать со 100% верностью хождение пакетов затрудняюсь. Но по идее если сервера будут в отдельной сети, то пакеты для «чужих» сетей будут уходить в маршрут по-умолчанию, а там уже шлюз отправит их куда надо.

Hatifnatt
()
Ответ на: комментарий от intelfx

теперь все запросы и ответы роутятся на уровне IP (L3), а не Ethernet (L2).

Это в любом случае быстрее чем NAT, но естественно каждое промежуточное звено через которое проходит трафик как минимум добавляет задержку.
А вообще все зависит от условий, если у вас на файлсервере гигабитный линк и он реально загружен, то поставив между ним и клиентами шлюз со 100 мбит линками вы естественно потеряете в производительности, даже если на шлюзе будут гигабитные линки, они все равно будут забиты трафиком с файлсервера. Если же у вас средний трафик с файлсервера 10 мбит, то особой разницы будет ли он ходить через коммутатор напрямую или делать дополнительный прыжок через шлюз не должно быть.

Hatifnatt
()
Ответ на: комментарий от intelfx

Дополнение

Т. е. вместо этого нужно вынести сервера в отдельную подсеть и всё будет работать? Или локальный DNS всё равно придётся поднимать?

Если «port forwarding» настроен на интерфейсе, а не на IP адресе, то все равно нужны будут правила для файрвола, но достаточно будет только DNAT см. [1] [2]. Все из за того что если «port forwarding» настроен с указанием интерфейса, то он не сработает т.к. трафик из локальной сети адресованый на публичный IP не пройдет через внешний интерфейс, а просто будет принят шлюзом «для себя».

Hatifnatt
()
Ответ на: комментарий от Hatifnatt

Отлично. Собственно, DNAT-правила уже и так есть по условию задачи.

Пойду перенастраивать и вытаскивать сервера в отдельную подсеть.

intelfx ★★★★★
() автор топика
Ответ на: комментарий от snaf

Потому что domain.tld:22 форвардится на одну машину, domain.tld:8080 — на другую и так далее. Средствами DNS это не решается.

intelfx ★★★★★
() автор топика
Последнее исправление: intelfx (всего исправлений: 1)

Я отнюдь не суровый админ и я уверен, что правила должны быть прописаны в OpenWRT, но я убей не пойму кто же может знать заранее порты и ip на которые надо, что то пробросить. Значит OpenWRT работает как то не совсем правильно с точки зрения hairpin NAT и пакеты все таки с внешнего ip роутера (wan) перебрасываются на внутренний IP роутера (lan) тогда понятное дело, что возвращаются они без проблем тем же путем. Но это должны быть другие правила не те, что требуется прописать в микротике.

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

alex_sim ★★★★
()
Последнее исправление: alex_sim (всего исправлений: 1)
Ответ на: комментарий от alex_sim

В OpenWRT я указываю правила форвардинга (т. е. -t nat -A PREROUTING -i <WAN> ... -j DNAT) и врубаю маскарад (-t nat -A POSTROUTING -o <WAN> -j MASQUERADE). И оно работает. Плюс ещё фильтры, разумеется, но там тоже всё самоочевидно.

В то время как в RouterOS нужно устраивать свистопляску вокруг адресов (как описано вот здесь), хотя в принципе это те же самые два правила (DNAT и SNAT).

В принципе, в этом весь вопрос: какого хрена в ROS нужно свистоплясать вокруг конкретных адресов? Что я понял не так? Почему правила для [hairpin] NAT в OpenWRT и RouterOS не идентичны с точностью до синонимов/терминологии?

intelfx ★★★★★
() автор топика
Последнее исправление: intelfx (всего исправлений: 3)
Ответ на: комментарий от intelfx

Они идентичны, просто в OpenWRT побольше магии, скрытой от ваших глаз, а в ROS - поменьше. Каждая фирмварь сама находит баланс между двумя крайностями:

1) Давайте дадим юзеру одну кнопку: «Сделать ЗБС!», мы-то всяко лучше знаем, чего ему надо хехехе.

2) Не, давайте не давать, видите какой он шибко-умный-очки-одел, пускай сам колупается, посмотрим насколько его хватит гыгыгы.

Как делается NAT reflection в OpenWRT (и к каким проблемам приводит много магии) написано здесь:

https://dev.openwrt.org/ticket/18057#comment:28

А когда магии недовкладывают, тоже много недовольных. То и это хорошо, то и это плохо.

rubic
()
18 июня 2017 г.
Ответ на: комментарий от TOXA

Что люди не делают, чтобы не настраивать DNS...

а если у меня два сервера с сайтами? поддомены? DESGUSTANG!!

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.