Hairpin nat что это

База знаний

Hairpin NAT можно использовать для доступа к узлу за NAT, находясь за этим же NAT.

В данной инструкции рассмотрена настройка Hairpin NAT на Edge Gateway через интерфейс VMware Cloud Director.

Рассмотрим пример настройки доступа по внешнему IP адреса с Workstation к Web Server, где Workstation и Web Server находятся за одним NAT. Веб-трафик между Workstation и Web Server будет проходить через Edge Gateway. На схеме ниже изображены 4 этапа передачи пакетов.

Как это работает

Stage 1: Workstation отправляет пакет с своего локального адреса 192.168.255.2 на внешний адрес Edge Gateway 176.53.180.81;

Stage 2: Edge Gateway заменяет адрес источника SrcIP Workstation 192.168.255.2 на адрес Edge Gateway 192.168.2.1, а адрес назначения DstIP Web Server на адрес Web Server 192.168.255.10;

Stage 3: Web Server, получив пакет с адреса Edge Gateway 192.168.2.1, отправляет ответ на адрес Edge Gateway 192.168.2.1;

Stage 4: Edge Gateway с помощью Connection Tracker подменяет замененные на Stage 2 адреса на изначальные и отправляет ответ от Web Server на Workstation.

Настройка Firewall на Edge Gateway

Пример настройки правил Firewall на скриншоте ниже.

Для доступа к Web Server с Workstation используется правило № 3.

Для доступа к Web Server из Интернет используется правило № 4.

Настройка NAT на Edge Gateway

Пример настройки NAT на скриншоте ниже.

Правила NAT, примененные (Applied on) к Uplink интерфейсу Edge Gateway, используемые для доступа к Web Server из Интернет и доступа с Web Server и с Workstation в Интернет:

196609 – SNAT – для доступа в Интернет с машин в локальной сети;

196610 – DNAT – проброс 80/tcp порта из Интернет;

196611 – DNAT — проброс 443/tcp порта из Интернет;

Правила, примененные (Applied on) к локальному интерфейсу Edge Gateway, используемые для Hairpin NAT:

196612 – SNAT – подмена адреса Workstation на адрес Edge Gateway в локальной сети (между Stage 1 и Stage 2);

196613 – DNAT – подмена внешнего IP на адрес Web Server (между этапами 1 и 2) для http трафика (80/tcp);

196614 – DNAT – подмена внешнего IP на адрес Web Server (между этапами 1 и 2) для https трафика (443/tcp);

В графе Applied on для «Hairpin-правил» нужно указать локальный интерфейс Edge Gateway.

Проброс других портов

Вы также можете сделать Hairpin NAT для других портов/протоколов, создав дополнительные DNAT правила, аналогичные правилам для HTTP и HTTPS.

• NAT, Hairpin NAT, Cloud, Director
• 2 Пользователи нашли это полезным

Связанные статьи

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

В данной статье мы рассмотрим возможность проводить захват сетевых пакетов на EDGE с дальнейшим.

Балансировщик нагрузки, встроенный в advanced edge, принимает UDP, TCP, HTTP, HTTPS запросы и.

Сетевая настройка VMware инфраструктуры (NAT, DHCP, Firewall, Static Routing, VPN). После того.

Edge Load Balancer, по сути, является HAProxy и поддерживает различные способы балансировки.

Настройка NAT: Hairpin

г. Санкт-Петербург, Крестовский остров, Северная дорога, дом 12.

Офис компании «SPW»

г. Санкт-Петербург, ст. м. «Василеостровская»,
ул. Уральская, д. 17, корпус 3, этаж 2

Hairpin NAT — примерно 10% запросов в нашу техподдержку так или иначе связаны с темой этой статьи.

Комментариев: 10 Просмотров: 65977
20 августа 2015

Введение

Примерно 10% запросов в нашу техподдержку таки или иначе связаны с темой этой статьи.

Итак, что такое Hairpin NAT и зачем он нужен.

Данная конфигурация обычно требуется, если Вы опубликовали на внешнем адресе (dst-nat) сервер, и Вам необходимо чтобы он был доступен по внешнему адресу изнутри сети.

Начнем с базовой конфигурации сети.

1. Вы имеете IP адрес 1.1.1.1/24 на интерфейсе WAN вашего маршрутизатора
2. Вы имеете IP адрес 192.168.0.1/24 на интерфейсе LAN вашего маршрутизатора.
3. Вы имеете www-сервер с адресом 192.168.0.10 в LAN сегменте.
4. Адрес вашего компьютера находится в диапазоне адресов LAN. Для примера пусть это будет 192.168.0.5

Вам помогла эта статья?

Приглашаем пройти обучение в нашем тренинг-центре и научиться настраивать оборудование MikroTik на профессиональном уровне! Узнайте расписание ближайших курсов и бронируйте место!

Вполне логично? что для того, чтобы опубликовать web-сервер на внешнем интерфейсе, Вы создаете правило dst-nat следующего вида:

/ip firewall nat add action=dst-nat chain=dstnat dst-address=1.1.1.1 dst-port=80 protocol=tcp \ to-addresses=192.168.0.10

Обратите внимание, что в правиле не указан in-interface, так как правило должно срабатывать при обращении на 80 порт адреса 1.1.1.1 с любого интерфейса.

Вы это делаете и..
И у вас все замечательно работает снаружи сети (при обращении из Интернет), но обращение с вашего компьютера по адресу http://1.1.1.1 говорит «Нет ответа от сервера». Для того, чтобы понять, что же происходит, рисуем схему прохождения и преобразования пакета:

Теперь распишем что происходит на каждом этапе.

Этап 1
Компьютер с адреса 192.168.0.5 пытается установить соединение с адресом 1.1.1.1 по 80 порту и отправляет пакет на маршрутизатор.

Этап 2
На маршрутизаторе срабатывает правило dst-nat, в результате чего адрес назначения пакета меняется на 192.168.0.10, и пакет отправляется на www-сервер 192.168.0.10.

Этап 3
Узел 192.168.0.10 получив пакет с адресом источника 192.168.0.5, определяет, что они оба находятся в одной локальной сети и отвечает ему напрямую, минуя маршрутизатор.

Проблема
Компьютер, отправив пакет на адрес 1.1.1.1, вдруг получает ответ с адреса 192.168.0.10. Естественно этот пакет он игнорирует и соединение не устанавливается.

Решение
Чтобы решить эту проблему, необходимо, чтобы www-сервер получил пакет у которого адрес источника будет равен адресу маршрутизатора.
Добавляем к нашей конфигурации правило, которое заменит адрес отправителя, адресом интерфейса маршрутизатора и получаем следующую конфигурацию:

/ip firewall nat 
add action=dst-nat chain=dstnat dst-address=1.1.1.1 dst-port=80 protocol=tcp to-addresses=192.168.0.10 
add action=masquerade chain=srcnat dst-address=192.168.0.10 dst-port=80 protocol=tcp src-address=192.168.0.0/24

Теперь у нас из конфигурация работает правильно. Схема для понимания:

Работа схемы

Этап 1
Компьютер с адреса 192.168.0.5 пытается установить соединение с адресом 1.1.1.1 по 80 порту и отправляет пакет на маршрутизатор.

Этап 2
На маршрутизаторе срабатывает правило dst-nat, в результате чего адрес назначения пакета меняется на 192.168.0.10 и правило src-nat, где адрес источника пакета меняется на адрес интерфейса маршрутизатора (192.168.0.1). После чего пакет отправляется на www-сервер 192.168.0.10.

Этап 3
Узел 192.168.0.10 получив пакет с адресом источника 192.168.0.1 (адрес маршрутизатора), определяет, что они оба находятся в одной локальной сети и отвечает ему. В результате чего пакет попадает на маршрутизатор

Этап 4
Connection Tracker маршрутизатора получив такой пакет выполняет обратное преобразование адресов. Компьютер получает ожидаемый ответ с адреса 1.1.1.1

Вот такая схема трансляции адресов и является Hairpin NAT.

Нужно отметить что у схемы есть недостаток. Заключается он в том, что публикуемый сервер будет получать запросы от хостов локальной сети с адреса маршрутизатора. Что не всегда хорошо. Например, если Вы так опубликуете прозрачный proxy-сервер, вряд ли у вас получится собрать нормальную статистику.

Альтернативой такой схемы могут служить.
1. Вынос публикуемых, или вообще всех серверов в отдельную подсеть. 2. Использование так называемого split-dns. Когда компьютер находясь снаружи сети на запрос www.mydomain.com получит адрес 1.1.1.1, а находясь внутри сети на этот же запрос получит адрес 192.168.0.10.

На этом я заканчиваю цикл статей про NAT на MikroTik. Надеюсь, что сумел описать все основные моменты работы NAT на маршрутизаторах MikroTik. Буду рад комментариям!

Статья написана сертифицированным тренером MikroTik Князевым И.Н., технический директор.

Hairpin NAT — делаем доступными одни сервисы из LAN другим, используя внешний IP

Hairpin NAT очень полезная штука в случае когда надо дать доступ внутренним сервисам (находящимся в LAN) друг к другу, используя внешний IP адрес (например, “для единообразия” или если не хочется заморачиваться с DNS).

Делается это просто:

iptables -t nat -A PREROUTING -d $ -p tcp -m tcp --dport $ -j DNAT --to-destination $ iptables -t nat -A POSTROUTING -s $ -d $ -p tcp -m tcp --dport $ -j MASQUERADE 

• extip — внешний IP адрес.
• extport — внешний порт.
• intport — порт сервера в локальной сети.
• localhostip — IP адрес сервера в локальной сети.
• intnet — внутренняя подсеть (например, 192.168.0.0/24).

Не добавляйте соответствие интерфейсов (параметр -i ) в правило, это сделает Hairpin NAT нерабочим в большинстве случаев!

Wanna discuss? Write me a mail!

© pztrn’s Wiki. Все права защищены. При использовании материалов с этого сайта действующая обратная ссылка обязательна.

Записки IT специалиста

Проброс портов — на первый взгляд тривиальная повседневная задача, которая не должна вызывать никаких затруднений. Действительно, в бытовых роутерах это так, но если речь идет об оборудовании Mikrotik, то сложности могут не заставить себя ждать. А все потому, что RouterOS дает в руки администратора богатые сетевые возможности, требуя в ответ понимания работы сетей хотя бы на базовом уровне. Конечно, можно настроить все по готовой инструкции, но гораздо лучше понимать каждое свое действие, и именно для тех, кто хочет разобраться предназначена эта статья.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Проброс портов

Проброс, он же форвардинг, портов — что это такое? Это технология, которая позволяет обращаться к узлам, находящимся за маршрутизатором путем перенаправления трафика для определенных портов с внешнего адреса маршрутизатора на внутренний адрес узла в локальной сети. Это становится возможным благодаря технологии NAT.

Давайте рассмотрим небольшую схему, которая поможет понять принцип действия проброса портов.

Допустим, некий удаленный ПК хочет обратиться к нашему веб-серверу, который находится за маршрутизатором в локальной сети. Но обратиться он может только по внешнему адресу маршрутизатора (в нашем примере 192.168.3.113), на который мы пробросили порт 80 веб-сервера. Поэтому он формирует пакет, в котором адресом назначения выступает маршрутизатор и отправляет его получателю, в качестве адреса источника он указывает собственный адрес.

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

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

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

На первый взгляд все понятно, поэтому перейдем к практике. В RouterOS в качестве сетевого фильтра используется iptables, поэтому далее мы будем оперировать его терминами. В таблице NAT используются две цепочки: PREROUTING — в которую попадают все пришедшие на маршрутизатор пакеты и POSTROUTING — через нее проходят все прошедшие через устройство пакеты. В PREROUTING нам доступно действие dst-nat (DNAT), которое позволяет изменить адрес назначения пакета, в POSTROUTING будут доступны src-nat (SNAT) и masquerade, которые позволяют изменить адрес источника пакета.

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

Так для пакета от клиента к веб-серверу и обратно порядок прохождения цепочек будет следующим:

PREROUTING -> FORWARD -> POSTROUTING

Обратите внимание, что пакет не попадает в цепочки INPUT и OUTPUT, которые используются для собственных пакетов маршрутизатора.

Как правильно выполнить настройку? Перейдем в IP — Firewall — NAT и добавим следующее правило: Chain — dstnat (читай PREROUTING), Dst. Address — 192.168.1.113 — внешний IP-адрес нашего роутера, Protocol — tcp — используемый протокол, если сервис может использовать несколько протоколов, скажем TCP и UDP — потребуется создать отдельное правило для каждого протокола, Dst. Port — 80 — порт, на котором маршрутизатор будет принимать внешние соединения.

На закладке Action укажите: Action — dst-nat — выполняем замену адреса получателя, To Addresses — 192.168.186.195 — внутренний адрес веб-сервера, To Ports — 80 — порт, на котором веб-сервер принимает соединения. Если внешний и внутренний порт совпадают, то последний можно не указывать.

Либо выполните в терминале:

/ip firewall nat 
add action=dst-nat chain=dstnat dst-address=192.168.3.113 dst-port=80 protocol=tcp to-addresses=192.168.186.195 to-ports=80

Но это еще не все, после PREROUTING пакет попадет в цепочку FORWARD, в которой, если вы настраивали роутер по нашей инструкции, запрещены любые внешние пакеты, кроме инициированных из локальной сети соединений.

Создадим новое правило. IP — Firewall — Filter Rules, где добавим: Chain — forward — цепочка FORWARD, Protocol — tcp, Dst. Port — 80 — протокол и порт, In. Interface — ether5 — внешний интерфейс вашего роутера. Так как по умолчанию в новых правилах стоит действие accept, на закладку Action можно не переходить.

Располагаться данное правило должно выше правила, запрещающего транзитный трафик из внешней сети во внутреннюю.

Обратите внимание, что если вы пробрасываете порт с изменением номера, скажем внутренний 3389 (RDP) на внешний 3390, то в правиле брандмауэра вы всегда должны указывать внутренний порт, т.е. 3389, так как пакет уже прошел цепочку PREROUTING и данные о получателе в нем уже изменены на адрес и порт внутреннего сервера.

Из терминала это можно сделать командами:

/ip firewall filter
add action=accept chain=forward dst-port=80 in-interface=ether5 protocol=tcp

Осталось только проверить работу наших правил, попробуем получить доступ к веб-серверу со внешнего узла:

Как видим, все прекрасно работает.

Hairpin NAT

Все это хорошо, но ровно до тех пор, пока мы не попытаемся получить доступ по внешнему адресу из внутренней сети. Вообще, таких ситуаций следует избегать, предпочтительно использовать для доступа доменные имена и двойной горизонт DNS, когда для внешних пользователей одно и тоже имя разрешается во внешний адрес, а для внутренних — во внутренний. Но это возможно не всегда. Попробовав же обратиться изнутри по внешнему адресу, мы получим ошибку соединения:

Почему так происходит? Давайте рассмотрим еще одну схему:

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

Что же делать? Очевидно, что нужно каким-то образом заставить веб-сервер отвечать не напрямую клиенту, а пересылать пакет обратно маршрутизатору. Здесь нам на помощь придет действие src-nat (SNAT), которое позволяет изменить адрес отправителя, находящееся в цепочке POSTROUTING. В терминах Mikrotik данная настройка носит наименование Hairpin NAT.

Чтобы понять, как это работает мы подготовили следующую схему:

Теперь наш маршрутизатор не только изменяет адрес назначения, но и адрес источника, указывая в его качестве собственный внутренний IP. Обработав такой пакет веб-сервер отправит его обратно к маршрутизатору, который выполнит обратные преобразования (согласно таблице трансляции) и оправит его получателю. А так как отвечать будет именно тот узел, к которому был отправлен запрос, то в данном случае все будет работать.

Для настройки на Mikotik перейдем в IP — Firewall — NAT и добавим: Chain — src-nat (POSTROUTING), Src. Address — 192.168.186.0/24 — диапазон вашей локальной сети, Dst. Address — 192.168.186.195 — внутренний адрес веб-сервера, Protocol — tcp, Dst. Port — 80 — протокол и порт.

Обратите внимание, что в качестве адреса и порта назначения мы указываем внутренние адрес и порт, так как пакет уже прошел цепочку PREROUTING, где данные получателя были изменены. К сожалению, не все это понимают, во многих инструкциях в сети в данном правиле фигурирует внешний адрес, стоит ли говорить, что такое правило работать не будет.

Затем переходим на закладку Action и указываем: Action — src-nat (SNAT), To Addresses — 192.168.186.1 — указываем внутренний адрес нашего маршрутизатора.

Через терминал данное правило можно создать следующим образом:

/ip firewall nat
add action=src-nat chain=srcnat dst-address=192.168.186.195 dst-port=80 protocol=tcp src-address=192.168.186.0/24 to-addresses=192.168.186.1

Во многих иных статьях для данного правила используется действие masquerade, давайте разберемся в чем разница. В первом приближении оба действия делают одно и тоже — изменяют адрес источника пакета, но src-nat работает только со статическими адресами, зато позволяет указать в качестве источника любой адрес, masquerade работает с динамическими адресами, но в качестве адреса источника может использовать только адрес того интерфейса, с которого уходит пакет. За счет того, что masquerade при каждом запросе определяет адрес интерфейса — это действие требует больше вычислительных ресурсов, нежели src-nat.

В нашем случае все адреса статические, поэтому использование src-nat здесь будет более уместно.

Правило создано, проверим его работу:

Если вы нигде не допустили ошибок — все будет работать, как и предполагалось.

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Дополнительные материалы:

Mikrotik

1. Оборудование MikroTik класса SOHO. Общий обзор и сравнение возможностей
2. Производительность младших моделей Mikrotik hEX и hAP. Экспресс-тестирование
3. Базовая настройка роутера MikroTik
4. Расширенная настройка DNS и DHCP в роутерах Mikrotik
5. Автоматическое резервное копирование настроек Mikrotik на FTP
6. Проброс портов и Hairpin NAT в роутерах Mikrotik
7. Настройка IPTV в роутерах Mikrotik на примере Ростелеком
8. Настройка VPN-подключения в роутерах Mikrotik
9. Настройка черного и белого списков в роутерах Mikrotik
10. Настройка выборочного доступа к сайтам через VPN на роутерах Mikrotik
11. Настройка OpenVPN-сервера на роутерах Mikrotik
12. Безопасный режим в Mikrotik или как всегда оставаться на связи
13. Настройка Proxy ARP для VPN-подключений на роутерах Mikrotik
14. Настраиваем Port Knocking в Mikrotik
15. Резервирование каналов в Mikrotik при помощи рекурсивной маршрутизации
16. Настраиваем родительский контроль на роутерах Mikrotik
17. Настраиваем IKEv2 VPN-сервер на роутерах Mikrotik с аутентификацией по сертификатам
18. Расширенная настройка Wi-Fi на роутерах Mikrotik. Режим точки доступа
19. Mikrotik CHR — виртуальный облачный роутер
20. Настройка контроллера CAPsMAN (бесшовный Wi-Fi роуминг) на Mikrotik
21. Настройка VPN-подключения на роутерах Mikrotik если подсети клиента и офиса совпадают
22. Настраиваем использование DNS over HTTPS (DoH) на роутерах Mikrotik
23. Настройка PPTP или L2TP VPN-сервера на роутерах Mikrotik
24. Установка Mikrotik CHR на виртуальную машину Proxmox
25. Защита RDP от перебора паролей при помощи оборудования Mikrotik
26. Настройка SSTP VPN-сервера на роутерах Mikrotik
27. Настройка выборочного доступа к сайтам через VPN с автоматическим получением маршрутов по BGP на роутерах Mikrotik
28. Особенности эксплуатации CA на роутерах Mikrotik: резервное копирование, экспорт и импорт сертификатов
29. Настройка туннелей GRE и IPIP на роутерах Mikrotik
30. Правильное использование Fast Path и FastTrack в Mikrotik
31. DHCP Snooping — настройка защиты от неавторизованных DHCP-серверов на оборудовании Mikrotik
32. Работа оборудования Mikrotik в режиме беспроводной станции (клиента)
33. Используем режим ARP reply-only для повышения безопасности сети на оборудовании Mikrotik

The Dude

1. The Dude. Установка и быстрое начало работы
2. Централизованное управление обновлением RouterOS при помощи The Dude
3. Централизованный сбор логов Mikrotik на сервер The Dude

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал: