Firewall (или пакетный фильтр) — это большая и сложная тема как в теоретическом, так и в практическом плане. Пакетный фильтр в различных операционных системах может иметь свои плюсы и минусы по сравнению с другими реализациями. В данной статье я буду рассматривать исключитетльно Firewall в RouterOS с оглядкой на его прародителя iptables.


Предисловие


Для кого эта статья


Если вы умеете работать с iptables, то дерзайте и настраивайте firewall, для вас в этой статье не будет ничего нового (ну разве что в таблице NAT используются цепочки с другими именами). Если вы впервые видите firewall в RouterOS и хотите получить готовый скрипт для конфигурации, то вы его здесь не найдете. Материал нацелен на тех, кто хочет получить базовое представление о том как работает firewall и что происходит с ip пакетом на разных этапах его обработки. Более глубокое понимание прейдет с опытом и решением повседневных и необычных задач с использованием пакетного фильтра.


Теоретическая часть


Что такое Layer3 Firewall



Предположим, что у вас есть роутер с выходом в интернет и двумя bridge интерфейсами: bridge-lan(ether2-ether5) и bridge-dmz(ether6-ether10).


В пределах Bridge интерфейса устройства самостоятельно находят соседей из свой подсети и обмениваются пакетами, роутер выполняет функции свича и не отслеживает такой трафик на сетевом уровне (конечно можно принудительно заставить его это делать, но про Layer2 Firewall поговорим в другой раз).


При необходимости связаться с устройством подключенного к другому bridge интерфейсу или находящемуся в глобальной сети устройства передают пакеты маршрутизатору, который определяет маршрут следования и обрабатывает их на сетевом(Layer 3) уровне.


Packet Flow Diagram


Полный путь трафика описан в Packet Flow Diagram, есть несколько официальных(v5, v6) версий, их необходимо знать и использовать в повседневной работе, но для понимания работы пакетного фильтра они перегружены, поэтому я буду объяснять на облегченном варианте.



Input/Output Interface — это любой (физический или виртуальный) Layer 3 интерфейс роутера. Пакет который идет из локальной сети в интернет попадает на input interface, а уходит с output interface. Пакет из интернета в локальную сеть, также попадает на input interface, а уходит с output interface. Packet Flow всегда читается в одном направлении input -> output.


Особенности терминологии


Изучая packet flow для iptables, можно встретить описания через "цепочки в таблицах" либо "таблицы в цепочках". На схеме представлены таблицы в цепочках, при добавлении правил в firewall все будет наоборот.


Но на самом деле пакет перемещается между блоками [цепочка+таблицы], например если вы сделайте accept в блоке [prerouting+mangle] транзитный пакет все-равно будет обработан в [forward+mangle]. Это важно помнить в сложных конфигурациях с pbr и queues.


В документации iptables есть более точные определения, но простыми словами:
Цепочки отвечают за место обработки пакета и последовательность правил.
Таблицы определяют действия, которые можно произвести над пакетом.


Базовые варианты следования пакета



Транзитный



  1. Пакет из сети приходит на один из интерфейсов роутера
  2. В цепочке PREROUTING администратор может повлиять на маршрут следования пакета: определить выходной интерфейс (Policy base routing) или перенаправить на другой адрес (dst-nat).
  3. В соответствии с таблицей маршрутизации для пакета определяется исходящий интерфейс.
  4. Цепочка FORWARD — основное место фильтрации проходящего трафика.
  5. Последним пунктом перед выходом в сеть является цепочка POSTROUTING, в которой можно изменить адрес отправителя (src-nat).
  6. Пакет ушел в сеть.

Входящий



  1. Пакет из сети пришел на один из интерфейсов роутера
  2. Попал в цепочку PREROUTING.
  3. В соответствии с таблицей маршрутизации пакет был отправлен на обработку локальному процессу.
  4. В цепочке INPUT происходит фильтрация входящего трафика администратором.
  5. Пакет ушел на обработку локальному процессу.

Исходящий



  1. Один из процессов роутера сгенерировал ip пакет (новый или ответный — неважно).
  2. В соответствии с таблицей маршрутизации для пакета определен выходной интерфейс.
  3. Администратор может фильтровать исходящий трафик, либо изменять маршрут в цепочке OUTPUT.
  4. Для пакета принимается окончательное решение о выходном интерфейсе.
  5. Пакет попадает в POSTROUTING, как и проходящий трафик.
  6. Пакет ушел в сеть.

Connection Tracker


Для начала необходимо понять, что представляет из себя stateful и stateless пакетные фильтры.



Пример. Компьютер 192.168.100.10 открывает tcp соединение с сервером 192.0.2.10. На стороне клиента используется динамический порт 49149, на стороне сервера 80. Еще до получения контента клиент и сервер должны обменяться пакетами для установки tcp сессии.


В stateless потребуется открыть трафик из локальной сети в интернет и из интернета в локальную сеть (как минимум для диапазона динамических портов). Что в целом является дырой.


В stateful маршрутизатор анализирует пакеты и получив tcp syn от 192.168.100.10:49149 для 192.0.2.10:80 считает это началом нового (new) соединения. Все дальнейшие пакеты (в любом направлении) между 192.168.100.10:49149 и 192.0.2.10:80 будут считаться частью установленного (established) соединения, до закрытия tcp сессии или истечения таймеров.


Для UDP/ICMP и других видов трафика, где нельзя четко выделить начало и конец соединения, новым пакетом является первый, остальные считаются частью установленного соединения и обновляют таймеры, маршрутизатор забывает про подобные соединения по истечению таймеров.


Connection tracker делит пакеты на несколько типов:



new — пакет открывающий соединение, например syn для tcp или первый пакет в udp потоке.
established — пакет относящийся к известному соединению.
related — пакет относящийся к дополнительному соединению в мультипротоколе (sip, pptp, ftp, ...).
invalid — пакет от неизвестного соединения.
untracked — пакет не отслеживаемый connection tracker.


Конфигурация Connection tracker
enabled=yes — включен.
enabled=no — отключен.
enabed=auto — отключен, пока в firewall не появится правило использующее возможности conntrack. Используется по умолчанию.



Остальные параметры являются различными таймерами и обычно не требуют тюнинга.


Администратор может просматривать и удалять соединения, например так выглядит соединение с NAT:



Использование conntrack сказывается на производительности и потреблении ресурсов (особенно при большом числе соединений), но отключить его в большинстве конфигураций не получится, т.к. у вас останется stateless firewall без NAT.


Список функций зависящих от connection tracker


TTL


Time To Live — поле в заголовке IP пакета определяющее число маршрутизаторов через которые может пройти пакет прежде чем будет уничтожен, защищает от бесконечной пересылки пакетов при петлях маршрутизации.



При пересылке (forwarding) роутер уменьшает значение TTL на 1 отбрасывает, если TTL=0. При этом пакет с TTL=1 попадет локальному процессу роутера.


Некторые операторы связи используют трюки с TTL для пресечения использования роутеров. Все эти ограничения прекрасно обходятся увеличением значения ttl в таблице mangle.


NAT


Network Address Translation — технология изменения адресов в заголовке ip пакета. Как и в linux, NAT является частью пакетного фильтра. NAT работает на основе connection tracker.


Изначально NAT был разработан как быстрое решение проблемы исчерпания IPv4 адресов, для локальных сетей было предложено использовать подсеть из диапазонов: 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16 и транслировать их в один(или несколько) маршрутизируемых адресов. На самом деле есть еще несколько служебных подсетей, которые можно использовать в частных сетях и роутеру в принципе все-равно что и как NAT'ить, но рекомендуется следовать стандартам.


NAT обрабатывает только: tcp, udp, icmp и некоторых мультипротоколов из [IP]->[Firewall]->[Service Port]. Обрабатывается только первый (connection-state=new) пакет в соединении, оставшиеся обрабатываются автоматически без участия таблицы NAT. Это можно отследить по изменению счетчиков в правилах.


В заголовке пакета присутствует Source и Destenation address, соответственно и NAT делится на Source и Destenation NAT.


Source NAT — подмена адреса отправителя, присутствует на подавляющем большинстве домашних и корпоративных роутеров в мире.



Позволяет множеству устройств с "серыми" адресами в локальной сети общаться с интернетом используя один (или несколько) реальных адресов.



Возвращаясь к Packet Flow смотрим, что SRC-NAT находится в Postrouting, после принятия решения о маршрутизации пакета.


Ответный пакет проходит неявный DST-NAT в котором адрес получателя меняется на локальный.


Destenation NAT — подмена адреса получателя.



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



По Packet Flow работа DST-NAT происходит до принятия решения о маршрутизации в Prerouting, присутствует неявный SRC-NAT для ответного трафика.


NAT является довольно мощным инструментом управления трафиком, но применять его стоит в последнюю очередь (когда остальные инструменты не могут помочь).


Цепочки(chains) базовые и пользовательские


Цепочки состоят из правил и форсируют логику обработки пакета.
Есть несколько базовых цепочек, отображенных на packet flow:
Prerouting(dstnat) — обработка пакета до принятия решения о маршрутизации
Input — обработка пакетов предназначеных локальным процессам маршрутизатора
Output — обработка пакетов пакетов сгенерированных локальными процессами маршрутизатора
Forward — Обработка проходящего трафика
Postrouting(srcnat) — Обработка трафика готового к передаче на интерфейс


Все как в iptables, но цепочки в nat переименованы. С чем это связано (скорее всего с hotspot или аппаратной разгрузкой nat) мне неизвестно, но в корне ничего не меняет.


Пакет проходит правила в цепочке последовательно, если он подходим по всем условиям, то к пакету применяется действие. Если действие является терминирующим и не отбрасывает пакет, то он передается в следующий блок packet flow.


У всех цепочек базовых есть действие по умолчанию (если пакет не подошел ни под одно из правил) — accept.


Пользовательские цепочки необходимы для уменьшения количества правил которые проходит каждый пакет и для построения сложных правил обработки трафика. У всех пользовательских цепочек есть действие по умолчанию — return.



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



Условия в правилах


Цепочки состоят из правил, каждое правило состоит из условий и действия. Условий достаточно много, но далеко не все вы будете использовать в реальных конфигурациях. Большинству условий можно поставить префикс "не" (знак "!"). Для совпадением с правилом, пакет должен подходить под все указанные условия.



Некоторые из условий
Условие Описание
src-address Адрес источника
dst-address Адрес получателя
src-address-list Адрес источника присутствует в списке
dst-address-list Адрес получателя присутствует в списке
protocol Протокол транспортного уровня
src-port Порт источника
dst-port Порт получателя
port Порт источника или получателя
in-interface Интерфес на который пришел пакет
out-interface Интерфейс с которого пакет будет отправлен в сеть
in-interface-list Интерфес на который пришел пакет присутствует в списке
out-interface-list Интерфейс с которого пакет будет отправлен в сеть присутствует в списке
layer7-protocol Анализ содержимого первых 10 пакетов в соединениий
content Поиск заданной строки в пакете
tls-host Поиск хоста в заголовке tls
ipsec-policy Проверить подпадает пакет под политику ipsec или нет
packet-size размер пакета в байтах
src-mac-address mac адрес источника пакета
connection-mark Метка соединения
packet-mark Метка пакета
routing-mark Маршрутная метка пакета
connection-state Состояние пакета в соединении
tcp-flags Флаги tcp пакета
icmp-options Опции icmp пакета
random Правило срабатывает(при совпадении остальных условий) с заданной вероятностью
time Можно указать рабочее время правила, к сожалению без конктеризации даты
ttl Значение поля ttl в пакете
dscp Значение поля DSCP(ToS) в пакете
--//-- --//--
place-before Консольная опция(не условие), позволяет добавить правило перед указанным
disabled Консольная опция(не условие), позволяет отключить правило

Примечания
В качестве src.(dst.) address можно указывать: одиночный ip, диапазон адресов через дефис, либо подсеть.
Списки адресов необходимы для объединения под одним именем нескольких несвязанных ip. В отличии от ipset в netfilter, записи в списках MikroTik могут удаляться через заданный промежуток времени. Просмотреть списки и внести изменения можно в [IP]->[Firewall]->[Address Lists].
В качестве номера порта(port, src-port, dst-port) можно указывать одиночный порт, несколько портов через запятую, либо диапазон портов через дефис.


На последнем MUM в МСК была неплохая презентация на тему влияния различных условий на скорость обработки пакетов (там же вы узнаете как использовать таблицу raw для снижения нагрузки на роутер), кому интересно: запись и презентация.


Действия в таблицах


Набор доступных действий над пакетом, зависит от таблицы в которой он обрабатывается.

Filter — таблица фильтрации трафика, одно из двух мест, где можно отбросить пакет.


NAT — таблица модификации ip адресов и портов(tpc, udp) в заголовке ip пакета.


Mangle — таблица для модификации других полей ip пакета и установки различных меток.



Существует три типа внутренних меток пакетов: connection, packet, route. Сетки существуют только в пределах роутера и не уходят в сеть. Пакет может иметь по одной метке каждого типа, при последовательном прохождении нескольких mark-* правил метки перезаписываются.
Маршрутные метки можно ставить только в цепочках prerouting и output, остальные в любых цепочках.


Хорошей практикой считается сначала маркировать соединение (connection), а потом пакет (packet) либо маршрут (route). Проверка наличия метки происходит быстрее чем полей пакета. На практике, это не всегда так и в сложных очередях или pbr дополнительная маркировка соединения не приносит пользы.


RAW — таблица позволяющая пакетам обходить механизм трекинга соединений (connection tracker). Используется для противодействия DoS и снижения нагрузки на cpu (например исключением multicast трафика). Позволяет отбросить пакет.


Терминирующие действия завершают обработку пакета в цепочке и передают следующему блоку в packet flow, либо отбрасывают.


Действия
Таблица Действие Описание Терминирующее?
Все accept Прекратить обработку пакета и передать в следующий блок Pakcet flow Да
Все log Записать в log информацию о пакете.В современных версиях можно добавить log к любому другому действию Нет
Все passtrough Посчитать число пакетов. Используется для отладки Нет
Все add src to address list и add dst to address list Добавить source (destenation) адрес из пакета в заданный список Нет
Все jump Перейти в пользовательскую цепочку Да
Все return Вернуться в родительскую цепочку. В базовых цепочках работает как accept Да
Filter и Raw drop Остановить движение пакета по packet flow и отбросить Да
Filter и Prerouting fasttrack Пометить пакет для быстрого прохождения packet flow Да
Filter reject Аналогично drop, но отправителю пакетов отправляется уведомление(tcp или icmp) о отброшенном пакете Да
Filter trapit Эмулировать наличие открытого порта. Используется для защиты от DoS, ввода в заблуждение и(иногда) отладке Да
NAT src-nat Подмена адреса отправителя на указанный Да
NAT masquerade Частный случай src-nat, подменяет адрес отправителя на один из адресов с интерфейса, используется на динамических(dhcp, vpn) интерфейсах. Не рекомендуется использовать при наличии нескольких ip на интерфейсе Да
NAT same Частный случай src-nat. Подменяет адрес отправителя на адрес из заданного диапазона Да
NAT dst-nat Подменяет адрес получателя на указанный Да
NAT redirect Частный случай dst-nat, подменяет адрес получателя на адрес интерфейса роутера на который пришел пакет Да
NAT netmap Не замена dst-nat. Применяется при трансляции сеть-в-сеть, смотрите примеры Да
Mangle mark connection Метка соединения Нет
Mangle mark packet Метка пакета, применяется в очередях Нет
Mangle mark routing Метка маршрута, применяется в Policy base routing Нет
Mangle change ttl Изменить ttl Нет
Mangle change dcsp(tos) Изменить dcsp, в десятичном виде Нет
Mangle change mss Изменить mss в tcp syn Нет
Mangle clear df Очистить флаг do not fragmet Нет
Mangle strip ipv4 options Очистить дополнительные опции ipv4 Нет
Mangle set priority Установить приоритет для CoS Нет
Mangle route Задать gateway для пакета. Простая версия PBR Нет
Mangle sniff tzsp Инкапсулировать пакеты в udp и отправить на указанный ip Нет
Mangle sniff pc Аналог tzsp, но с другим типом инкапсуляции. В wiki если примеры использования с calea Нет
Mangle passtrough По умолчанию большинство правил в mangle не останавливает прохождение пакета, можно изменить это поведение установить passtrough=no Нет
Raw notrack Не отслеживать пакет в connection tracker Да

Если найдутся желающие, могу написать подробнее про FastTrack и FastPath, но чудес от этих технологий ждать не стоит.


Пара слов про DPI


Существует несколько возможностей заглядывать в пакет чуть глубже заголовка транспортного уровня:
content — производит поиск заданной строки в пакете.
layer7-protocol — буферезирует первые 10 пакетов (или 2KiB) из соединения и производит поиск по regexp в буферезированных данных. Большое число layer7 правил существенно влияют на производительность.
tls-host — адрес имени хоста в заголовке TLS/SNI соединения HTTPS.


Примеры


Не копируйте примеры бездумно, лучше возбмите устройство и постарайтесь написать конфигурацию самостоятельно (или переписать примеры, но вникнуть что делает каждое из правил). Если не знаете как дополнить правила: в дефолтной и минимальной домашней конфигурациях нет доступа на роутер с wan интерфейса, добавьте его с фильтрацией по списку адресов.


Дефолтный Firewall RouterOS


Достаточно защищенная конфигурация, но местами сильно замороченая:


/ip firewall filter
#Разрешает входящий трафик от уже установленных(established, related) соединений и неотслеживаемые(untracked) пакеты
add action=accept chain=input connection-state=established,related,untracked

#Отбрасываем входящие пакеты от неизвестных(invalid) соединений
add action=drop chain=input connection-state=invalid

#Разрешаем входящий icmp трафик
add action=accept chain=input protocol=icmp

#Отбрасываем все входящие пакеты пришеджие не с интерфейсов локальной сети
add action=drop chain=input in-interface-list=!LAN

#Для правильной работы ipsec в туннельном режиме
add action=accept chain=forward ipsec-policy=in,ipsec
add action=accept chain=forward ipsec-policy=out,ipsec

#Маркируем для быстрого прохождения транзитные пакеты от уже установленных соединений
add action=fasttrack-connection chain=forward connection-state=established,related

#Разрешаем транзитные пакеты от уже установленных соединений
add action=accept chain=forward connection-state=established,related,untracked

#Отбрасываем неизвестные транзитные пакеты
add action=drop chain=forward connection-state=invalid

#Отбрасываем транзитные пакеты со стороны wan интерфейсов, которы не относятся к dstnat (вспоминаем, что для ответных пакетов в src-nat присходит неявный dst-nat)
add action=drop chain=forward connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

/ip firewall nat
#Source NAT для пакетов не относящихся к ipsec, уходящих с интерфесов из списка WAN
add action=masquerade chain=srcnat ipsec-policy=out,none out-interface-list=WAN

Никогда не использовал дефолтный конфиг, но раньше дефолтный firewall был значительно хуже.


Минимальный "домашний" firewall


Самый простой, что удалось придумать. Да в нем не разрешен untracked трафик (но на этапе базового изучения firewall он вам всеравно не нужен) и будут проблемы с туннельным ipsec (опять-же, если вы умеете настраивать ipsec, то сами знаете что необходимо сделать).


/ip firewall filter
#Разрешает входящий трафик от уже установленных(established, related) соединений
add chain=input connection-state=established,related action=accept

#Разрешаем входящий icmp трафик
add chain=input connection-state=new protocol=icmp action=accept

#Разрешаем входящий трафик из локальной сети
add chain=input connection-state=new in-interface-list=LAN action=accept

#Отбрасываем весь оставшийся входящий трафик
add chain=input action=drop

#Разрешаем транзитные пакеты от уже установленных соединений
add chain=forward connection-state=established,related action=accept

#Разрешаем транзитные пакеты из локальной сети в сеть интернет
add chain=forward connection-state=new in-interface-list=LAN action=accept

#Отбрасываем весь оставшийся транзитный трафик
add chain=forward action=drop

/ip firewall nat
#Source NAT для пакетов уходящих с интерфесов из списка WAN
add chain=srcnat out-interface-list=WAN action=masquerade 

Пример с DMZ


На "домашних" роутерах аббревиатурой DMZ любят обзывать компьютер в локальной подсети для которого проброшены все порты из внешней сети.


На самом деле это не так и один из вариантов DMZ — отделение ресурса на который необходимо предоставить доступ из сети интернет и может быть проведена успешная атака (web server с cms в которых постоянно находят дыры — хорошая цель для взломщика). В случае взлома, злоумышленник не сможет повлиять на участников локальной сети.



#Проброс порта
/ip firewall nat
add chain=dstnat dst-port=80,443 action=dst-nat to-address=192.168.200.2

/ip firewall filter
#Разрешаем ответный и icmp входящий трафик
add chain=input connection-state=established,related action=accept
add chain=input protocol=icmp connection-state=new action=accept

#Разрешаем входящий трафик из локальной сети
add chain=input in-interface=ether2-lan action=accept

#Отбрасываем оставшийся входящий трафик
add chain=input action=drop

#Разрешаем ответный транзитный трафик
add chain=forward connection-state=established,related action=accept

#Разрешаем пользователям из локальной сети создавать транзитные соединения
add chain=forward in-interface=ether2-lan connection-state=new action=accept

#Разрешаем транзитные соединения на web сервер
add chain=forward out-interface=ether3-dmz dst-address=192.168.200.2 dst-port=80,443 connection-state=new action=accept

#Отбрасываем оставшийся транзитныйтрафик
add chain=forward action=drop

HairPin NAT



/ip firewall nat
add chain=dstnat dst-port=80 action=dst-nat to-address=192.168.100.2

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


Давайте разберем что происходит:


  1. Компьютер 192.168.100.10 отправляет запрос на 192.0.2.100
  2. На роутере отрабатывает DST-NAT и пакет пересылается на 192.168.100.2
  3. Сервер видит, что к нему на адрес 192.168.100.2 пришел пакет от 192.168.100.10 и отвечает 4. Компьютер получает неожиданный пакет от 192.168.100.2 и отбрасывает его.

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


/ip firewall nat
#Правило проброса
add chain=dstnat dst-port=80 action=dst-nat to-address=192.168.100.2

#Новое правило, для пользователей из локальной сети
add chain=srcnat src-address=192.168.100.0/24 dst-address=192.168.100.2 action=masquerade

На практике такую схему используют не часто, но как пример отладки firewall мне очень нравится.


Правильное использование netmap



Netmap — технология трансляции адресов из одной подсети в адреса другой подсети.
IP адрес (в записи с маской) состоит из двух частей: сетевой (число бит указанных в маске подсети) и хостовой (оставшиеся биты). Netmap изменяет сетевую часть адреса, но не трогает хостовую.



Есть два роутера соединенные VPN каналом. Роутеры обслуживают подсети с одинаковой адресацией. Необходимо сделать доступ между подсетями.


Без дополнительной адресации тут не обойтись.


Пользователи из левой подсети будут стучаться в правую через подсеть 192.168.102.0/24
Пользователи из правой подсети будут стучаться в левую через подсеть 192.168.101.0/24


Конфигурация на MikroTik 1.


#Без правила роутинга не обойтись
/ip route
add distance=1 dst-address=192.168.102.0/24 gateway

/ip firewall nat
#В исходящих пакетах будем менять адрес источника
add action=netmap chain=srcnat dst-address=192.168.102.0/24 out-interface=ipip src-address=192.168.100.0/24 to-address=192.168.101.0/24

#Во входящих пакетах будем менять адрес получателя
add action=netmap chain=dstnat dst-address=192.168.101.0/24 in-interface=ipip src-address=192.168.102.0/24 to-address=192.168.100.0/24

Конфигурация MikroTik2 практически аналогична:


/ip route
add distance=1 dst-address=192.168.101.0/24 gateway=10.10.10.1

/ip firewall nat
add action=netmap chain=srcnat dst-address=192.168.101.0/24 out-interface=ipip src-address=192.168.100.0/24 to-address=192.168.102.0/24
add action=netmap chain=dstnat dst-address=192.168.102.0/24 in-interface=ipip src-address=192.168.101.0/24 to-address=192.168.100.0/24

Есть более сложные конфигурации с использованием netmap, например если у вас множество подключений к удаленным точкам с пересекающимеся подсетями и нет возможности изменить настройки на удаленном оборудовании, но это уже advanced routing.


Если вы ничего не поняли (про netmap), значит оно вам не нужно и просто не используйте данное действие при пробросе портов.

Комментарии (19)


  1. Rumickon
    07.01.2019 02:05
    +1

    Спасибо.
    Как минимум один желающий прочитать подробнее про FastTrack и FastPath есть.


    1. eri
      07.01.2019 15:05
      +1

      В микротиках всё это как «черная коробочка» — очень сложно найти описания внутреннего устройства таких вещей больше чем в 3 строчки. Недавно читал патчи Куалкома на бридж — надеюсь в микротике Фастпаф на их основе.


  1. beho1der
    07.01.2019 07:25

    Тоже бы почитал с удовольствием!


  1. gvozd1989
    07.01.2019 09:20

    Пожалуйста, продолжайте писать такие статьи.


  1. LMonoceros
    07.01.2019 14:00
    -1

    Качественная статья. Добавил в закладки чата @router_os в Телеграме


    1. eri
      07.01.2019 15:00

      рекламка канала? я вот тоже запостил статью, но зачем рекламироваться в коментариях?


      1. LMonoceros
        07.01.2019 17:46
        +1

        А вот и зря, что не указал свой канал.
        Новички не знают, что в Телеграме есть много сообществ специалистов по Микротик у которых можно спросить совета. Например каналы: @MikrotikRus, @mikrotikclub и @miktrain (канал Романа Козлова)


      1. Mstislav93
        07.01.2019 18:31

        почему реклама, канал известный, там много людей который оценят сей годный материал


  1. ZloyKishechnik
    07.01.2019 15:17

    но про Layer2 Firewall поговорим в другой раз


    Ждем статью и про L2 уровень.
    Спасибо, очень интересно было со всем ознакомиться.


    1. grims
      09.01.2019 00:46

      Если вы когда-то настраивали L2 на устройствах других вендоров, то забудьте про это, в Mikrotik все совсем по-другому, особенно в switch-ах ver. 1.x, 2.x (CRS).
      И статья об этом будет без сомнения очень полезна.


      1. ZloyKishechnik
        09.01.2019 11:50

        купил L2 mikrotik switch для настрйоки вланов на домашних серверах/компах.
        кто-то говорит, что я лоханулся.
        пока не знаю.

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


        1. Bulroh Автор
          09.01.2019 11:59

          Они сейчас сильно L2 колбасят, так что я немного подожду пока устаканится. Если есть конкретный вопросы по настройке, можете в ЛС написать.


          1. ZloyKishechnik
            09.01.2019 12:01

            да у меня все никак руки не доберутся начать настраивать.
            как только сяду и если возникнут трудности, то напишу. спасибо)


  1. adm738
    07.01.2019 15:18

    Спасибо.
    Очень интересно.
    Продолжайте в том-же духе.


  1. Gluzer
    07.01.2019 15:18

    Написано грамотно. Спасибо.


  1. avelor
    08.01.2019 00:59

    Спасибо, может быть будет меньше прокидывальщиков портов через netmap :)
    К слову, а почему у вас проброс порта через /ip firewall mangle? Всю жизнь через nat пробросы делал, как и маскарадинг/dstnat/srcnat.

    Добавлю, что проброс порта с srcnat лучше по возможности не делать, лучше по возможности использовать split-dns. Меньше нагрузка на роутер, да и будет не очень, если на сервер будут приходить запросы с внутреннего одного ip (для всяких fail2ban и прочих рвзборов полётов с копанием в логах). Но это конечно к делу не относится.


    1. Bulroh Автор
      08.01.2019 01:26

      К слову, а почему у вас проброс порта через /ip firewall mangle?

      Опечатка, руками переписывал, поправлю)

      лучше по возможности использовать split-dns

      Согласен, но мне пример с hairpin nat нравится именно как пример на подумать


      1. avelor
        08.01.2019 01:45

        фух, а то я уж в себе засомневался :D позанудствую — опечатка была в двух местах)

        да, к сожалению иногда приходится использовать. чуть более интересное применение «технологии» у меня было когда нужно было пробросить порт снаружи в туннель ipsec, и чтобы это счастье заработало как раз понадобился srcnat.


  1. IgnatIvchenko
    09.01.2019 12:06
    +1

    Bulroh Спасибо за статью, если нужно вот удобная MikroTik_PacketFlow v2.4 in RouterOS v6.*


    MikroTik_PacketFlow