Глобальный hairpin NAT

Обсуждение оборудования и его настройки
Ответить
Nimlock
Сообщения: 2
Зарегистрирован: 18 янв 2018, 15:36
Откуда: Екатеринбург

Всем привет!
Хочу обсудить правильность сделанного мной конфига hairpin NAT.
Ситуация такая: есть сеть, построенная на роутере Микротик, в которой присутствует некое количество ip-камер. Камеры позволяют подключаться на 80-ый порт и пользователи это активно используют. Для доступа снаружи применяется классический dstNAT с переназначением порта, провайдер выдаёт белую статику.
Пусть внешний адрес 1.1.1.1, внутренний адрес роутера 192.168.88.1/24, ip-камера первая имеет адрес 192.168.88.101, вторая - 192.168.88.102. Также создана отдельная подсеть для вайфай 192.168.99.1/24.
Имеются правила:

Код: Выделить всё

/ip firewall nat add chain=dstnat dst-address=1.1.1.1 protocol=tcp dst-port=8001 action=dst-nat to-address=192.168.88.101 to-port=80
/ip firewall nat add chain=dstnat dst-address=1.1.1.1 protocol=tcp dst-port=8002 action=dst-nat to-address=192.168.88.102 to-port=80

Согласно мануалу https://wiki.mikrotik.com/wiki/Hairpin_NAT предлагается использовать для hairpin-соединений маскарад, применяемый по условиям определённой (локальной) подсети происхождения пакета, определённого адреса и порта назначения.

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

Мой вариант решения: маркируем соединения по признаку интерфейса происхождения пакета (не внешняя сеть) и адресу назначения, равному внешнему ip. Затем применяем к пакетам с этой меткой соединения маскарад. Всё, готово. Решение уже проверено, доступ к камерам по внешнему адресу получаем и изнутри сети.

Код: Выделить всё

/ip firewall mangle add chain=prerouting dst-address=1.1.1.1 in-interface-list=!WAN action=mark-connection new-connection-mark=hairpin-connection passthrough=no
/ip firewall nat add chain=srcnat out-interface-list=LAN connection-mark=hairpin-connection action=masquerade

Решение добавить во втором правиле параметр out-interface-list взял из упомянутого мануала, хотя смысла в нём не вижу.

Вопросы: 1) насколько надёжен данный подход? Не может ли такая настройка мешать каким-либо службам внутри сети (например STUN) или логике работы роутера?
2) на кой рекомендуется указывать out-interface-list в последнем правиле? Разве пойдут пакеты после маскарада наружу? Или этот параметр и определяет дальнейшее следование пакетов после данной процедуры?
3) для общего понимания подскажите, при написании правил для подразделов /ip firewall стоит ли рассматривать все указываемые параметры только строго как фильтры (признаки) для применения правила (кроме тех что в GUI расположены под вкладкой Action, т.е. action, to-address, to-port)? Или среди них могут попадаться и команды для роутера для изменения пакета или пути его следования?


kt72ru
Сообщения: 141
Зарегистрирован: 23 июн 2017, 07:55

Зачем два правила? Лишняя нагрузка на процессор. Достаточно

Код: Выделить всё

/ip firewall nat add chain=srcnat src-address=192.168.88.0/24 dst-address=192.168.88.101 protocol=tcp dst-port=80 out-interface-list=LAN action=masquerade


1) насколько надёжен данный подход? Не может ли такая настройка мешать каким-либо службам внутри сети (например STUN) или логике работы роутера?

Надежен, но 1 лишняя нагрузка на процессор, 2 лишнее звено при траблшутинге.

2) на кой рекомендуется указывать out-interface-list в последнем правиле? Разве пойдут пакеты после маскарада наружу? Или этот параметр и определяет дальнейшее следование пакетов после данной процедуры?

для того чтобы подставить в адрес источника адрес LAN интерфейса, соответственно определяет дальнейшее следование пакетов после данной процедуры.

3) для общего понимания подскажите, при написании правил для подразделов /ip firewall стоит ли рассматривать все указываемые параметры только строго как фильтры (признаки) для применения правила (кроме тех что в GUI расположены под вкладкой Action, т.е. action, to-address, to-port)? Или среди них могут попадаться и команды для роутера для изменения пакета или пути его следования?

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


Nimlock
Сообщения: 2
Зарегистрирован: 18 янв 2018, 15:36
Откуда: Екатеринбург

Спасибо за быстрый ответ!
Зачем два правила? Лишняя нагрузка на процессор. Достаточно

Код: Выделить всё

/ip firewall nat add chain=srcnat src-address=192.168.88.0/24 dst-address=192.168.88.101 protocol=tcp dst-port=80 out-interface-list=LAN action=masquerade

Вероятно, на самом деле в данном случае эти два правила можно объединить в одно, только вот в указанном Вами коде, как мне кажется, пропала сама цель скомпоновать правила для каждой камеры в одно универсальное. Такой вывод я сделал, так как увидел параметр dst-address=192.168.88.101, что будет активировать маскарад только для одной камеры. Также правило не сработает, если попытаемся подключиться из подсетки для вайфая (192.168.99.0/24). Для данной задачи не требуется ограничение по доступу (скорее наоборот), а ради этого создавать address list и следить за его актуальностью не хочется. Может быть тогда надо так? Проверить пока не смогу - выходные.

Код: Выделить всё

/ip firewall nat add chain=srcnat dst-address=1.1.1.1 in-interface-list=!WAN out-interface-list=LAN action=masquerade

Я же разделил процесс на два правила следуя логике диаграммы, представленной тут - https://wiki.mikrotik.com/wiki/Manual:Packet_Flow. Если конкретно, то srcnat выполняется на цепочке postrouting, но у меня есть опасение, что на более ранней процедуре routing decision пакет будет направлен на шлюз провайдера, ведь у него стоит dst-address=1.1.1.1 - это ip из провайдерской подсети. А так я сперва в prerouting гарантированно отмечаю желаемые для дальнейшей обработки пакеты. Хотя тут логика даёт сбой, ведь метка никак не влияет в этом случае на прохождение процедуры выбора маршрута, а второе правило выполняет маскарад всё на том же этапе srcnat в postrouting. Нужна помощь с пониманием этого.

2) на кой рекомендуется указывать out-interface-list в последнем правиле? Разве пойдут пакеты после маскарада наружу? Или этот параметр и определяет дальнейшее следование пакетов после данной процедуры?
для того чтобы подставить в адрес источника адрес LAN интерфейса, соответственно определяет дальнейшее следование пакетов после данной процедуры.

А вот об этом и был мой третий вопрос, давайте разберём на этом самом примере. Вы пишете про параметр out-interface-list "чтобы подставить в адрес...", но в графическом интерфейсе при выборе действия masquerade мы не можем выбирать что и куда он должен подставлять - это как бы уже готовая процедура, да и поле исходящего интерфейса не является обязательным к заполнению (иначе была бы ошибка при сохранении). Так вот точно ли можно говорить о том, что этот параметр "определяет дальнейшее следование пакетов", а не обуславливает применимость правила к тому или иному пакету в соответствии с его заголовоком? Тем более, что, опять же, согласно упомянутой схеме, это действие происходит уже после и выбора маршрута и выбора моста (порта моста). Т.е. вроде бы исходящий интерфейс к этому моменту уже выбран и сменить его в процессе postrouting не получится, а вот модифицировать пакет используя назначенный ранее исходящий интерфейс как один из признаков целевых пакетов - можно. Но допускаю что я не так интерпретировал схему. Верны ли мои рассуждения?

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

Абсолютно согласен и поэтому я и решил выставить вопрос на обсуждение. Ведь для составления корректного "необходимо и достаточно" в описании правил нужно ясно понимать логику системы.


Ответить