Страх и ненависть в RouterOS: что такое сетевое соединение в ядре Linux (часть 2 — практика) +33




Ранее в первой (теоретической) части статьи была подробно описана сущность сетевого соединения глазами ядра маршрутизатора. В текущей части мы закрепим информацию в результате рассмотрения работы прикладного протокола DNS через подсистемы RouterOS.

В заключительной части речь пойдёт о диаграмме потока пакетов, при работе с которой важно понимать сущность рассматриваемого сетевого соединения, а также о не документированной в явном виде особенности работы NAT. Материала достаточно много, и чтобы читатель не потерял смысловую нить к концу статьи, она разделена на 3 части: теория, практика и особенность NAT.
Материалы носят в основном теоретический характер и предназначены для людей, тонко настраивающих Firewall, Qos и маршрутизацию, где им придётся непосредственно работать с рассматриваемыми connections. Цикл статей не предназначен для новичков и может их только запутать. Полагаю, что читатель хорошо знаком с предметом разговора.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Без лишних слов приступим к описанию практической задачи. Имеем классическую локальную сеть, в которой клиенты (в том числе беспроводные) подключены к маршрутизатору (со стороны LAN IP адрес 192.168.1.1, со стороны WAN IP адрес 10.0.2.47) и получают посредством работы DHCP протокола в качестве DNS сервера непосредственно IP адрес роутера. Сам роутер использует в качестве сервера DNS IP адрес Cloudflare (/ip dns set allow-remote-requests=yes servers=1.1.1.1). Пользователь загружает свой ноутбук (PC), подключается к Wi-Fi сети, получает от DHCP сервера IP адрес 192.168.1.2 и в браузере открывает сайт, например, mail.ru. Для простоты сосредоточимся на работе не шифрованного DNS протокола, позволяющего увидеть содержание пакетов на прикладном уровне.

Сколько типов DNS соединений будет создано в RouterOS?

Разберёмся детально и разложим всё по полочкам. Если кто-то не уверен в ответе, то после прочтения ясность будет внесена. В действительности имеем следующие DNS запросы и ответы, передающиеся по транспортному протоколу UDP:

  • PC -> MikroTik;
  • MikroTik -> DNS servers;
  • DNS servers -> MikroTik;
  • MikroTik -> PC.

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

/ip firewall mangle
add action=mark-connection chain=prerouting comment=\
    "DNS catcher PC->MikroTik Connections" dst-address=192.168.1.1 dst-port=\
    53 new-connection-mark="DNS catcher PC->MikroTik Connections" \
    passthrough=yes protocol=udp
add action=mark-packet chain=prerouting comment=\
    "DNS catcher PC->MikroTik Packets" connection-mark=\
    "DNS catcher PC->MikroTik Connections" new-packet-mark=\
    "DNS catcher PC->MikroTik packets" passthrough=no
add action=mark-connection chain=prerouting comment=\
    "DNS catcher DNS Servers->MikroTik Connections" new-connection-mark=\
    "DNS catcher DNS Servers->MikroTik Connections" passthrough=yes protocol=\
    udp src-address-list="DNS servers" src-port=53
add action=mark-packet chain=prerouting comment=\
    "DNS catcher DNS Servers->MikroTik Packets" connection-mark=\
    "DNS catcher DNS Servers->MikroTik Connections" new-packet-mark=\
    "DNS catcher DNS Servers->MikroTik Packets" passthrough=no
add action=mark-connection chain=output comment=\
    "DNS catcher MikroTik->PC Connections" new-connection-mark=\
    "DNS catcher MikroTik->PC Connections" passthrough=yes protocol=udp \
    src-address=192.168.1.1 src-port=53
add action=mark-packet chain=output comment=\
    "DNS catcher MikroTik->PC Packets" connection-mark=\
    "DNS catcher MikroTik->PC Connections" new-packet-mark=\
    "DNS catcher MikroTik->PC Packets" passthrough=no
add action=mark-connection chain=output comment=\
    "DNS catcher MikroTik->DNS Servers Connections" dst-address-list=\
    "DNS servers" dst-port=53 new-connection-mark=\
    "DNS catcher MikroTik->DNS Servers Connections" passthrough=yes protocol= udp
add action=mark-packet chain=output comment=\
    "DNS catcher MikroTik->DNS Servers Packets" connection-mark=\
    "DNS catcher MikroTik->DNS Servers Connections" new-packet-mark=\
    "DNS catcher MikroTik->DNS Servers Packets" passthrough=no

Маркировка осуществляется по схеме: сначала обозначаются соединения (mark-connection) затем пакеты этих соединений (mark-packet). Соединения «PC -> MikroTik» отлавливаются по IP адресу роутера и 53 номеру порта назначения. Здесь и далее я опускаю одинаковый и потому не информативный в текущем контексте префикс «DNS catcher». Соединения «MikroTik -> DNS servers» помечаются только по 53 номеру порта назначения. Соединения «DNS servers -> MikroTik» маркируются по такой же схеме, только в правиле используется 53 порт отправителя. Соединения «MikroTik -> PC» отлавливаются на основе IP адреса маршрутизатора и 53 порта отправителя. Для исключения ошибки перемаркировка пакетов ограничена (passthrough=no). Обращаю внимание, пакетов, а не соединений. Чтобы убедиться в корректности работы Mangle, по очереди зеркалируем пакеты каждого типа соединений. Пример, как это делается для пакетов «MikroTik -> DNS servers», представлен ниже:

/ip firewall mangle
add action=sniff-tzsp chain=postrouting comment="Sniffer"
packet-mark="DNS catcher MikroTik->DNS Servers Packets" sniff-target=\
    IP_адрес_принимающего_сервера sniff-target-port=37008

Как сохранить трафик на принимающей стороне, рассмотрено здесь. Для зеркалируемых пакетов не забываем снять ограничение, озвученное выше, и выставить passthrough=yes, иначе правило /ip firewall mangle add action=sniff-tzsp будет проигнорировано. Почему для разных типов соединений используются различные цепочки в Firewall (Prerouting, Output, Postrouting) будет рассмотрено ниже. Для тех, кто вообще не в теме, коротко прокомментирую: пакет проходит через различные части сетевой подсистемы Linux, ядро применяет правила из определённых цепочек (chains) к пакетам. После получения нового пакета от физического уровня ядро активизирует правила в цепочках, соответствующих вводу. Все эти структуры данных обслуживаются ядром. Такая подсистема в целом и является Firewall-ом, который из пространства пользователя создаёт правила и управляет ими. Иллюстрация, взятая здесь, в очень упрощённом варианте отображает связь между различными цепочками:



В качестве DNS клиента удобно использовать встроенную во многие операционные системы программу nslookup, которой можно указать IP адрес DNS сервера (192.168.1.1) куда будет отправлен запрос:

nslookup mail.ru 192.168.1.1

Посмотрим, что представляет из себя каждый тип выделенных нами пакетов:

  • Соединения с меткой «PC->MikroTik Connections» (содержат пакеты «PC->MikroTik packets») передают DNS query;


  • Соединения с меткой «MikroTik->DNS Servers Connections» (содержат пакеты «MikroTik->DNS Servers Packets») также передают DNS query;


  • Соединения с меткой «DNS Servers->MikroTik Connections» (содержат пакеты «DNS Servers->MikroTik Packets») передают DNS query response;


  • Соединения с меткой «MikroTik->PC Connections» (содержат пакеты «MikroTik->PC Packets») также передают DNS query response.



Видно, что маркировка соответствует своим названиям, и, следовательно, выполнена корректно. Пришло время ответить на вопрос, сколько типов соединений создано в RouterOS? Теоретическая часть цикла статей позволяет нам на него ответить – будет создано 2 типа соединения, которые должны получить метки «PC->MikroTik Connections» и «MikroTik->DNS Servers Connections». Внутри операционной системы созданы всего 2 типа соответствующих сокетов (с одинаковыми Stream index). Хотя с точки зрения UDP протокола, будет 4 типа отправки пакетов, ведь UDP ничего не знает про полезную нагрузку прикладного протокола DNS, и что в нём идут запросы и ответы на них, и какие там существуют клиент-серверные взаимосвязи. Чтобы это проверить, дополним правило для «MikroTik->PC Connections» параметром «established», т.е. соединение, которое установлено ранее:

/ip firewall mangle
add action=mark-connection chain=output comment=\
    "DNS catcher MikroTik->PC Connections" connection-state=established \
    new-connection-mark="DNS catcher MikroTik->PC Connections" passthrough=yes \
    protocol=udp src-address= 192.168.1.1 src-port=53

Ничего не изменится, счётчик пакетов будет отрабатывать, потому как соединение было установлено ранее на этапе «PC->MikroTik Connections». А если укажем connection-state=new, то счётчик замрёт, таких новых соединений нет. Попробуем ещё дополнительно повесить указанную марку на соединения, которые ранее не размечались (connection-mark=no-mark):

/ip firewall mangle
add action=mark-connection chain=output comment=\
    "DNS catcher MikroTik->PC Connections" connection-mark=no-mark \
    new-connection-mark="DNS catcher MikroTik->PC Connections"\
    passthrough=yes protocol=udp src-address=192.168.1.1 src-port=53

Счётчики остановятся и возобновят свою работу только, если мы укажем не пустой маркер, а «PC->MikroTik Connections». Для других правил будет аналогичная ситуация. Однако если заглянуть в Connection tracking, то там можно увидеть следующую картину:



Как видно, маркировка как бы перевёрнута, что вначале может даже ошеломить. Чтобы такого с вами не произошло, разберу ситуацию подробно. Если мы укажем для соединений «MikroTik->PC Connections» и «DNS Servers->MikroTik Connections» условие connection-mark=no-mark, то Connection tracking даст ожидаемый результат:



Без него происходит перемаркировка соединений, а с ним уже существующие соединения не получат новую марку. Вышесказанное звучит достаточно запутанно, поэтому передам туже самую мысль, касательно не корректной ситуации в Connection tracking, другими словами. Внутри маршрутизатора возникает следующая ситуация. DNS запрос от PC поступает на DNS сервер, интегрированный в MikroTik. RouterOS внутри себя создаёт первое сетевое соединение «PC->MikroTik Connections». Далее роутер осуществляет DNS запрос к серверу Cloudflare, и создаётся второе соединение «MikroTik->DNS Servers Connections». Далее от сервиса Cloudflare приходит DNS query response, что является продолжением и окончанием второго соединения. После этого роутер выполняет DNS query response в сторону PC, что является продолжением и окончанием первого соединения. Правилами Mangle мы вмешиваемся в вышеописанные действия.

Первая половина первого запроса у нас маркируется как «PC->MikroTik Connections» (корректно), а вторая половина первого запроса маркируется как «MikroTik->PC Connections» (что и должно было вызвать смуту в нашей голове при просмотре Connection tracking, как показано на рисунке с некорректной ситуацией). На деле это одно и то же соединение внутри RouterOS. Однако половина его вышла с одной меткой, а вторая половина с другой, и Connection tracking отрисовал только ту метку, которая пришла к нему последней (в последнем блоке по движению пакетов внутри операционной системы, об этом подробнее будет в третьей части цикла статей). Для соединений «MikroTik->DNS Servers Connections» и «DNS Servers->MikroTik Connections» возникает ровно такая же ситуация. Поэтому выровнять ситуацию нам помог параметр connection-mark=no-mark.

Отмечу, что если в правилах Mangle указать passthrough=no, которое при срабатывании пропустит трафик, минуя оставшиеся правила маркировки (значение по умолчанию для параметра passthrough=yes, поэтому в явном виде оно не указывается), то при отсутствующем параметре connection-mark=no-mark перемаркировка всё равно произойдёт. Ключевую роль опять же играет прохождение соединений и пакетов внутри операционной системы маршрутизатора, о чём мы подробно поговорим в третьей части цикла статей. Параметр passthrough=no попросту не отработает, так как первая половина соединения и вторая половина соединения проходят различными маршрутами внутри роутера.

Резюмирую вышесказанное. При работе описанной классической сети для одного DNS запроса клиента LAN в реальности UDP соединение отрабатывает 4 раза: в направление роутера, затем до DNS сервера Cloudflare и обратно. Однако RouterOS будет воспринимать их только как 2 соединения: от клиента Wi-Fi в направлении маршрутизатора и обратно, а также от роутера до DNS сервера Cloudflare и обратно. В глазах MikroTik, любой одиночный UDP пакет — это новое соединение до тех пор, пока не будет отправлен ответ в обратном направлении. Когда есть ответ, то это уже для него UDP соединение. Разумеется, вышесказанное правило ограничено во времени в соответствии с таймаутами, о которых речь шла в первой части цикла статей.

Ранее говорилось, что защита роутера от DOS атак на L3 уровне может базироваться на правилах обработки сетевых соединений. На практике это будет выглядеть так:

/ip firewall filter
add action=add-src-to-address-list address-list=DOS address-list-timeout=1h chain=input comment="List DOS" connection-limit=100,32 connection-state=new in-interface=WAN
add action=drop chain=input comment="Drop DOS list" src-address-list=DOS

Логика работы приведённых правил следующая: не более 100 новых сетевых соединений с IP адреса с 32 маской, иначе IP адрес идет в бан. Подробнее про возможности можно почитать здесь. В комментариях правильно отметили, что правильнее банить не в таблице Firewall Filter, а в таблице Firewall Raw, почему это так станет очевидно после прочтения третьей части цикла статей:
/ip firewall raw
add action=drop chain=input comment="Drop DOS list" src-address-list=DOS


▍ Заключение


В статье с практической точки зрения рассмотрено, что такое сетевое соединение в ядре Linux. Внутри RouterOS и других, «Linux based» операционных систем, понятие сетевое соединение не идентично клиент-серверному соединению. MikroTik работает с виртуальными сокетами, под которыми следует понимать совокупность пар IP адрес отправителя и номера порта отправителя, а также IP адрес получателя и номера порта получателя, искусственно введённых для обеспечения функционирования устройства. Это особенно важно при настройке Firewall, а следовательно, и связанных с ним Qos и маршрутизации, в некоторых случаях.

Часть 1
Часть 2 (вы тут)
Часть 3




Комментарии (44):

  1. Tarakanator
    /#23753411 / +1

    Чтобы это проверить, дополним правило для «MikroTik->PC Connections» параметром «established», т.е. соединение, которое установлено ранее:

    Пока непонятно. Почему у вас счётчик работает. А у меня в фаервольные правила иногда не попадает.

    End output rules output: in:(unknown 0) out:LAN-bridge, proto UDP, 192.168.66.1:53->192.168.66.6:51496, len 60
    Почему он не попал в правило?
    ;;; established related chain=output action=accept connection-state=established,related log=no

    Я чего-то не понял или мне надо ждать 3-ю часть?

    Работа протокола DNS в контексте connections очень подробно рассмотрена во второй части цикла статей. А в третьей будут еще и уточняющие диаграммы. После их прочтения данный вопрос у вас будет снят.

    • olegtsss
      /#23753507

      Исправьте в своем правиле log=yes. После этой части должно быть все ясно. Третья часть является дополнением, касательно работы DNS протокола.

      • Tarakanator
        /#23753577

        Исправил, полюбовался на километры лога.
        Выключил.
        Сделал правило с логированием только с 53 порта... ну вроде всё правильно выглядит. Куда смотреть-то?

        • olegtsss
          /#23753741

          Сформулируйте ваш вопрос.

          • Tarakanator
            /#23754003

            пакет от DNS сервера микротика к компу попадает в последнее запрещающее правило
            End output rules output: in:(unknown 0) out:LAN-bridge, proto UDP, 192.168.66.1:53->192.168.66.6:51496, len 60
            Почему он не попал в правило?
            ;;; established related chain=output action=accept connection-state=established,related log=no
            Раз этот пакет ИЗ порта 53, то он явно ответный, а значит соединение established

            С TCP тоже бывает случается

            End output rules output: in:(unknown 0) out:LAN-bridge, proto TCP (SYN,ACK), 192.168.66.1:53->192.168.66.4:3765, len 52

            С коннекшн трекером по умолчанию такая-же фигня. Но на всякий случай прилагаю текущие настройки.

            ip firewall connection tracking print
            enabled: auto
            tcp-syn-sent-timeout: 5s
            tcp-syn-received-timeout: 10s
            tcp-established-timeout: 12h
            tcp-fin-wait-timeout: 20s
            tcp-close-wait-timeout: 10s
            tcp-last-ack-timeout: 30m
            tcp-time-wait-timeout: 10s
            tcp-close-timeout: 10s
            tcp-max-retrans-timeout: 5m
            tcp-unacked-timeout: 10m
            loose-tcp-tracking: yes
            udp-timeout: 20s
            udp-stream-timeout: 3m
            icmp-timeout: 10s
            generic-timeout: 10m
            max-entries: 183768
            total-entries: 870

            • olegtsss
              /#23754211

              Приведите все правила вашего firewall filter.

              • Tarakanator
                /#23754377

                Этого достаточно?

                chain=output

                ip firewall filter print where chain=output Flags: X - disabled, I - invalid, D - dynamic 0 chain=output action=drop dst-address-list=fail2ban 248d log=no log-prefix=""

                1 X ;;; established related chain=output action=accept connection-state=established,related protocol=udp src-port=53 log=yes log-prefix=""

                2 ;;; established related chain=output action=accept connection-state=established,related log=no log-prefix=""

                3 ;;; ICMP chain=output action=accept protocol=icmp log=no log-prefix=""

                4 ;;; NTP chain=output action=accept connection-state=new protocol=udp src-address=109.95.219.210 dst-address-list=NTP servers src-port=123 dst-port=123 log=no log-prefix=""

                5 ;;; ipsec. chain=output action=accept protocol=udp src-port=4500 log=no log-prefix=""

                6 ;;; temp ipsec chain=output action=accept connection-state=new protocol=udp dst-address-list=ipsec hosts dst-port=500,4500 log=no log-prefix=""

                7 ;;; telegram bot and DoH chain=output action=accept connection-state=new protocol=tcp out-interface-list=!LAN+VPN dst-port=443 log=no log-prefix=""

                8 ;;; download.mikrotik.com chain=output action=accept connection-state=new protocol=tcp dst-address-list=download.mikrotik.com out-interface-list=Internet dst-port=80 log=no log-prefix=""

                9 X ;;; DoH chain=output action=accept connection-state=new protocol=tcp dst-address=94.140.0.0/16 dst-address-list=DNS servers dst-port=443 log=no log-prefix=""

                10 ;;; DNS client chain=output action=accept connection-state=new protocol=udp dst-address-list=DNS servers dst-port=53,853 log=no log-prefix=""

                11 ;;; BGP chain=output action=accept connection-state=new protocol=tcp dst-address=163.172.210.8 out-interface=gre1 dst-port=179 log=no log-prefix=""

                12 ;;; Simple Service Discovery Protocol (answer on broadcast) chain=output action=accept connection-state=new protocol=udp src-address=192.168.66.1 dst-address=192.168.66.0/24 out-interface=LAN-bridge src-port=1900 log=no log-prefix=""

                13 ;;; upnp answer(why new?) chain=output action=accept connection-state=new protocol=tcp src-address=192.168.66.1 dst-address=192.168.66.0/24 out-interface=LAN-bridge src-port=2828 log=no log-prefix=""

                14 ;;; GRE to Amsterdam chain=output action=accept protocol=gre dst-address=158.101.195.230 log=no log-prefix=""

                15 ;;; Simple Service Discovery Protocol. Why ? chain=output action=drop protocol=udp dst-address=239.255.255.250 out-interface=LAN-bridge src-port=1900 dst-port=1900 log=no log-prefix=""

                16 ;;; igmp chain=output action=drop protocol=igmp src-address=192.168.66.1 dst-address=224.0.0.22 out-interface=LAN-bridge log=no log-prefix=""

                17 ;;; SSDP event notification service\MS icslap
                chain=output action=drop protocol=tcp src-address=192.168.66.1 out-interface=LAN-bridge port=2869 log=no log-prefix=""

                18 X ;;; icslap
                chain=output action=drop protocol=tcp src-port=52572 dst-port=2869 log=no log-prefix=""

                19 ;;; The End chain=output action=drop log=yes log-prefix="End output rules"

                • olegtsss
                  /#23755451

                  В представленных выше материалах есть вывод:
                  «Теоретическая часть цикла статей позволяет нам на него ответить – будет создано 2 типа соединения, которые должны получить метки «PC->MikroTik Connections» и «MikroTik->DNS Servers Connections»». Обращаю внимание на соединение «MikroTik->DNS Servers Connections».

                  Своим правилом firewall №2 вы принимаете (accept) только соединения established и related, вместо new. Правильный вид для разрешающего правила:
                  /ip firewall filter
                  add action=accept chain=output connection-state=new,established

                  • olegtsss
                    /#23755453

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

                  • Tarakanator
                    /#23755623

                    А при чем тут MikroTik->DNS Servers Connections, если пакет летит от микротика к pc, а не к dns серверу?

                    • olegtsss
                      /#23755883

                      Смотрите какая ситуация. Пакеты, которые летят от микротика к pc последним правилом своего firewall вы не дропаете. Вы дропаете пакеты от встроенного DNS сервера RouterOS в сторону следующего DNS сервера (например, интернет провайдера). Пакеты «MikroTik->DNS Servers Packets».

                      • Tarakanator
                        /#23756099

                        Почему тогда в логе в дестинейшн ПК, а не внешний dns сервер, и почему пакет не НА 53 порт, а С 53 порта?

                        Почему вы решили что дропает пакет на внешний dns сервер?

                        А новые соединений к dns серверам от микротика, это 10е правило в выгрузке.

                      • olegtsss
                        /#23756419

                        Я симулировал ситуацию для правил:
                        ;;; established related chain=output action=accept connection-state=established,related log=no
                        ;;; The End chain=output action=drop log=yes log-prefix=«End output rules»

                        Приведите экспорт вашего firewall filter, чтобы можно было симулировать ситуацию полностью. Так как, например, правило №10 я просто проглядел.

                      • olegtsss
                        /#23765021

                        Разбираемся с вашим случаем. Из всей выгрузки оставляю значимые правила:

                        /ip firewall filter
                        add action=accept chain=output comment=«established related» connection-state=established,related
                        add action=accept chain=output comment=«DNS client» connection-state=new dst-address-list=«DNS servers» dst-port=53 protocol=udp
                        add action=drop chain=output comment=«The End» log=yes log-prefix=«End output rules»

                        Пробую nslookup mail.ru 192.168.1.1, все работает. Выключаю разрешающее правило:
                        add action=accept chain=output comment=«DNS client» connection-state=new dst-address-list=«DNS servers» dst-port=53 protocol=udp

                        Пробую опять nslookup mail.ru 192.168.1.1, ничего не работает, так как срабатывает правило аdd action=drop chain=output comment=«The End» для попытки RouterOS отрезолвить dns имя на внешнем DNS сервере.

                        Пробую добавить статическую запись, чтобы он не обращался туда:
                        /ip dns static add address=1.1.1.1 name=mail.ru

                        Пробую опять nslookup mail.ru 192.168.1.1 и запрос отрабатывает. Делаю вывод, что пакеты от DNS сервера микротика к компу не попадают в последнее запрещающее правило. В него попадают пакеты «MikroTik->DNS Servers Packets».

                        P.S. Что там у вас записывается в лог, вы уж разберите сами, с вашим firewall это будет не скучно сделать.

                      • Tarakanator
                        /#23766701

                        Делаю вывод, что пакеты от DNS сервера микротика к компу не попадают в последнее запрещающее правило.

                        Неправильно делаете вывод.
                        Это значит что ОБЫЧНО пакеты попадают в разрешающее правило.
                        Но практика показывает что так происходит не со всеми пакетами.
                        Ещё раз. Я не жалуюсь что у меня в принципе DNS не работает. Я жалуюсь, что с DNS периодически творится какая-то хрень.

                        DoH server connection error: SSL: internal error (6)
                        DoH server connection error: remote disconnected while in HTTP exchange
                        DoH server connection error: Idle timeout - waiting data

                        Но к этому вообще непонятно как подступаться. Поэтому я решил начать с того, что некоторые DNS пакеты почему-то не проходят фаервол.

                      • olegtsss
                        /#23767395 / +1

                        Мой вывод основан на действиях, представленных выше. Объясните, почему он не правилен?

                        Пока с ваших слов видно, что вы имеете дело с тем, что получаете не тот результат, что ожидаете. Начали с DNS протокола. Теперь добавляете SSL в комментарии. С учетом количества правил в вашем Firewall, в нем не сложно запутаться. Уберите все лишнее, выполните отладку для конкретной проблемы. Затем постепенно включайте другие правила и анализируйте ситуацию. Обычный troubleshooting. Ситуацию про работу DNS протокола я вам описал, можете на нее опираться.

                      • Tarakanator
                        /#23768493 / -1

                        Мой вывод основан на действиях, представленных выше. Объясните, почему он не правилен?

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

                        В него попадают пакеты «MikroTik->DNS Servers Packets».

                        End output rules output: in:(unknown 0) out:LAN-bridge, proto UDP, 192.168.66.1:53->192.168.66.6:51496, len 60

                        а)192.168.66.6 НЕ DNS СЕРВЕР.
                        б)Если пакет летит на DNS сервер, то он летит на 53 порт, а тут летит ИЗ 53 порта.
                        Соответственно это не может быть «MikroTik->DNS Servers Packets»

                        Теперь добавляете SSL в комментарии.

                        это я на случай чтобы вы не сказали что раз DNS в принципе работает, то и забей на логи.

                         Уберите все лишнее, выполните отладку для конкретной проблемы.

                        я не могу сделать это на проде. Лишнее = или функционал или безопасность.
                        Тем более что у меня проблема что НИ ОДНО правило(кроме последнего) не отрабатывает. Что может измениться от того, что я ещё уменьшу количество правил(т.е. ещё уменьшу вероятность срабатывания правил кроме последнего)
                        Термин вероятности тут конечно неправильный, но я думаю вы поняли.

                      • olegtsss
                        /#23769355 / +1

                        Я вижу, что в ваших логах что-то не так. Вам надо разбираться. Выражения, что что-то работает, то не работает не корректно, так как техника всегда имеет под строгий алгоритм функционирования. Устройство и протоколы работают так, как запрограммированы. Если что-то не так, как вы ожидаете, тогда приступаете к troubleshooting.

                      • olegtsss
                        /#23769367 / +1

                        Если вы думаете, что кому-то интересно разбирать ваш firewall в более 60 правил и искать причину, почему результат не тот, как вы ожидаете, то я думаю это не так). Примените метод абстрагирования. Удалите все лишнее и по шагам идите до нужного (ожидаемого, контролируемого) результата, не переступая через «непонятки».

                      • Tarakanator
                        /#23771495

                        Я честно не понимаю зачем нужно разбирать мой фаервол.
                        Если правила в нём НЕ срабатывают (раз дело доходит до последнего правила)
                        И тем более почему нужно разбирать все 60 правил, если нас интересует только output.
                        Причина должна быть в чём-то другом. Мне кажется есть какой-то нюанс в коннекшн трекере.

                        Удалите все лишнее и по шагам идите до нужного (ожидаемого, контролируемого) результата, не переступая через «непонятки».

                        Я уже сделал это. Я не смотрю на работу DOH. Я смотрю на самый базовый уровень(DNS пакеты). И всё равно ожидаемого результата не получаю.
                        Если я сломаю все правила и оставлю только DNS... ну а толку, У меня сейчас есть лог с 29 ноября... ни одного пакета DNS пакета не дропнуло. Ну и сколько мне без интернета сидеть чтобы таким способом отловить проблему?
                        А правил куча как раз для того, чтобы было видно что и где ходит.

                        Хотя сейчас подумал... добавил логирующие правила перед последним output для UDP из 53 порта со state new\invalid\untracked. Посмотрим попадётся ли в них что.

                      • Tarakanator
                        /#23776053

                        Опять дропнулся пакет.
                        udp from 53 new output: in:(unknown 0) out:LAN-bridge, proto UDP, 192.168.66.1:53->192.168.66.6:55628, len 60

                        По префиксу понятно, что залогировано было правилом

                        ;;; udp from 53 new chain=output action=drop connection-state=new protocol=udp src-port=53 log=yes log-prefix="udp from 53 new"

                        Возникает вопрос:

                        Как пакет ИЗ (а не НА) 53 порта может иметь connection state=new

                      • olegtsss
                        /#23776129

                        Например, когда MikroTik осуществляет резолв по собственной инициативе. У вас в конфиге использованы DNS имена? Соответственно по таймеру нужно резолвить, и это будут new.

                      • Tarakanator
                        /#23776207

                        Не понял.
                        Если DNS клиент обращается к DNS серверу, то пакет будет НА 53 порт. А тут он ИЗ 53 порта.
                        и 192.168.66.6 не DNS сервер. Я вроде это уже 3-й раз пишу, но ответа не получаю.

                      • olegtsss
                        /#23776237

                        Давайте вам объясню на примере, рассчитываю, что так вам будет все яснее. Откройте консоль на роутере и выполните в ней команду: /ping mail.ru

                        Перед тем, как пойдет выполнение команды ping, роутер сначала отрезолвит доменное имя mail.ru. И этот резолвинг будет у него new.

                      • Tarakanator
                        /#23776303

                        Вот этот резолвинг (залогирован другим правилом)
                        DNS client output: in:(unknown 0) out:WAN-ether1, proto UDP, 109.95.219.210:46159->94.140.14.14:53, len 60
                        он отличается от
                        udp from 53 new output: in:(unknown 0) out:LAN-bridge, proto UDP, 192.168.66.1:53->192.168.66.6:55628, len 60
                        1)Пакет идёт НА 53 порт, а не ИЗ 53 порта.
                        2)Пакет идёт на DNS сервер, а не на устройство внутри сети, в котором DNS сервера нет.
                        Я это уже 4-й раз пишу.

                      • olegtsss
                        /#23776379

                        «Возникает вопрос:

                        Как пакет ИЗ (а не НА) 53 порта может иметь connection state=new»?

                        Это ваш вопрос, на который выше был дан ответ.

                      • olegtsss
                        /#23776435

                        Напоминаю, что у «UDP» соединения глазами RouterOS есть таймаут (udp-timeout: 10s). Если ответ придет позже, то ответ на резолвинг клиента будет тоже new.

                      • Tarakanator
                        /#23776513

                        1)это что за тормозной сервер должен быть, чтобы по 10 сек ждать?
                        2)я увеличил до 20 сек, не помогло.
                        3)20 секундные таймауты я бы заметил

                        Хотя... Сейчас обдумал, а может вы и правы. у меня же какая-то нездоровая хрень с DOH есть. возможно какие-то ответы действительно за 20 сек выбиваются.

                      • olegtsss
                        /#23776607

                        Я бы все равно посоветовал выполнить дамп и внимательно его разобрать.

                      • olegtsss
                        /#23776399

                        «192.168.66.1:53->192.168.66.6:55628, len 60» Выполните запись трафика, изучите содержание пакета.

                      • Tarakanator
                        /#23776879

                        А как при записе трафика определить какой именно пакет был дропнут? DNS ответов же куча будет.

                      • olegtsss
                        /#23778205

                        Я бы советовал это сделать посредством маркировки трафика.

  2. kterik
    /#23754195

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

    Подозреваю, что вследствие неполной изоляции VRF на RouterOS здесь есть много тонкостей.

    • Kiano
      /#23755275

      Если не сложно, можно ли подробнее, в какой ситуации у Вас проявилась неполная изоляция vrf?

      • kterik
        /#23755713

        Имеется роутер R1. На нём поднят MPLS, создано несколько VRF, из каждого доступен свой набор маршрутов, получаемых по BGP (MPLS L3VPN), а также в каждом VRF имеются локальные интерфейсы. Адресация нигде не пересекается. Имеется роутер с фаерволом R2, с которым каждый VRF на R1 связан динамической маршрутизацией по OSPF: в сторону R2 редистрибутятся все маршруты, обратно получается маршрут по умолчанию. В некотором VRF X есть присоединённая сеть X1, при обращении в которую нужно выполнять простой маскарадинг. Маскарадинг прописан в правилах NAT R1. Некий узел Y1 из другого VRF Y обращается в сеть X1. Трафик проходит из R1 VRF Y на R2, оттуда обратно на R1, но уже в VRF X. Возникает проблема: Mikrotik создаёт одно соединение, к которому пытается применить правило NAT, не глядя на то, что вообще-то потоков трафика два, входящий и исходящий forward, и они типа должны быть изолированы в разных VRF, но вот поди ж ты. В итоге NAT не работает. Прописывание Routing mark в правиле NAT, попытка разметить соединения не помогли. Пришлось решать проблему, искусственно введя лупбек на R2, на котором вторично происходит source nat.

        • Kiano
          /#23755723

          Интересный кейс, спасибо.

    • olegtsss
      /#23755457

      Тема маршрутизации в RouterOS действительно требует глубокого разбора. Термин «неполная изоляция» считаю не уместным. Думаю, проблема в настройках сети (устройств), а не в MikroTik.

      • kterik
        /#23755719

        VRF в Mikrotik неполноценный. Я не разбираюсь в линуксе, но давняя статья поясняет причины, почему в RouterOS не существует VRF-зависимых сервисов (telnet, ssh, DHCP relay и пр.), почему возникает ситуация из моего комментария выше и почему разработчики RouterOS уже лет десять обещают нормально изолированный VRF в ROS7.

        • Kiano
          /#23755735

          И снова спасибо, упустил эту статью.

  3. barlog1
    /#23761979 / +1

    /ip firewall filter

    ...

    add action=drop chain=input comment="Drop DOS list" src-address-list=DOS

    Почему не в RAW?

    • olegtsss
      /#23764917

      Спасибо за верный комментарий. Намеренно, чтобы не усложнять материал (ведь под диаграммы отведена отдельная третья часть цикла статей. Однако вопрос борьбы с DOS в ней уже не поднимается. Конечно, банить лучше в RAW. Явно указал в статье.