Doh server connection error ssl internal error

MikroTik поддерживает DNS over HTTPS (DoH)

Начиная со стабильной версии 6.47 MikroTik поддерживает DNS over HTTPS (DoH).
Далее краткая инструкция по настройке с проверкой сертификата сервера на примере Cloudflare.

1) Импортируем сертификат DigiCert Global Root CA в хранилище сертификатов роутера:

2) В поле Use DoH Server пишем https://1.1.1.1/dns-query и ставим галку Verify DoH Certificate:

3) Убираем все существующие DNS-сервера, чтобы поля Servers и Dynamic Servers (из DHCP Client) были пустыми и все запросы шли через DNS over HTTPS (не обязательно для 6.47.1+).

Проверить корректность настройки можно на странице https://www.cloudflare.com/ssl/encrypted-sni

MikroTik поддерживает DNS over HTTPS (DoH) : 36 комментариев

DoH server connection error: SSL: handshake failed: unable to get local issuer certificate (6)

в логах такая ошибка

Видимо вы не добавили сертификат из первого шага.

CF сломал https://1.1.1.1/dns-query , а так всё хорошо начиналось…

Нет, всё работает, видимо вы не настоящий админ.

Возвращение 400 это работает называется?
400 = 200 уже?

Его нужно не в браузере открывать, а в микротике прописывать, у меня до сих пор работает.

Он лишь в Curl’е иногда проскакивает что работает.
В микротике тоже отказывается.
У них в DoH мане теперь написано что нужно указывать домен, т.е. что бы юзать DoH, нужно юзать чей то DNS.
У гугла та же история теперь, по этому DoH в той самой изначальной идее уже больше мёртв, чем жив, т.к. остальную мелочь из поставщиков DoH не рассматриваем.

Укажите домен статикой будет вам счастье.

И искать потом приключения на удалённых узлах, когда он вдруг сменится?
Хороший такой совет.

перестало сегодня работать
DoH server connection error: SSL: handshake failed: certificate is not yet valid (6)
DoH server connection error: Connection refused

не смог заставить работать
и серт перекачал

Как вариант, снимите галку с пункта verify-doh-cert=

Спасибо за инструкцию.
Всё работает как надо.
После я усложнил схему. Я ещё и WARP Cloudflare подключил через WireGuard (в RouterOS 7.1) и смаршрутизировал запросы на 1.1.1.1 в тоннель.

класс. Поделитесь конфигом?)

Там его нужно генерировать через неофициальный cli клиент, вот инструкция: https://moonback.ru/page/keenetic-warp
Вот клиент: https://github.com/ViRb3/wgcf

Добавить комментарий Отменить ответ

Источник

Mikrotik doh server connection error ssl internal error 6

Маршрутизаторы MikroTik — Обсуждение

Старая программа для конфигурирования — Winbox winbox.exe ( 111.5 КБ )
Новая программа для конфигурирования — Winbox winbox3.exe ( 1.39 МБ )
Версия 3.18 (исправлена совместимость с прошивками 6.43): winbox318.exe ( 1.58 МБ )
Версия 3.19 (исправлен логин в 6.45): winbox.exe ( 1.59 МБ )

]*ssdp:(alive|byebye)|^m-search[9-D ]\*[9-D ]http/1\.1[9-D —

]*user-agent: gnucleus [9-D —

]* Accept: application/x-rtsp-tunnelled|http/(0\.9|1\.0|1\.1) [1-5][0-9][0-9] [9-D —

Если вам требуется помощь в решении проблемы- выкладывайте свой конфиг: /export hide-sensitive terse

Сообщение отредактировал ferhad.necef — 03.01.23, 15:46

Smartecs, через L7 руки не дошли пока у самого на своём, но вроде как читал через webproxy можно, и вроде как: (где-то вычитал, почему-то запомнилось):
Cоздать разрешающее правило в котором ничего нет, кроме значения accept в action и просто разместить его перед/после правила, которое разрешает доступ.

У меня такая проблема на одном из встроенных в материнскую плату сетевых контроллеров. Так и не поборол, использую тот, который без проблем поднимает 100Мб.

Сообщение отредактировал Shoore — 03.12.14, 00:47

ToMaTo_0,
А после покупки делали полный сброс устройства, потом устанавливали свежую прошивку?

Добавлено 02.12.2014, 23:26:

Shoore,
Кстати думаю сообщения нужно перенести в тему указанную тобой.

ToMaTo_0,
Подключите роутер к другому ПК/ноуту/роутеру к чему нибудь где есть активный ethernet порт и посмотрите в статусе на сколько поднимется порт.
Интересует будет ли держать порт скорость 100/1000мб/с с другим устройством, не вашим ПК.
Также попробуйте на ПК «жестко» зажать порт на 100мб/с.

Сообщение отредактировал ctich — 03.12.14, 00:20

А можно уточнить расстояние «основного пачкорда» ??
Надеюсь не более 90м., и кабель обжат правильно.

Парни подскажите где туплю.
Необходимо доработать схему:
2 port tagged — vlan 55
3 port untagged — vlan 55
5 port tagged — vlan 55,56,57

Для vlan 56,57 создан bridge0 и с ними проблем нет.
Прописываю теперь 55 vlan.
Создаю vlan 55 указываю на interf 5
Создаю bridge 1
В bridge в port создаю приземляю vlan 55 на bridge 1
В bridge в port создаю eth 2 + bridge 1
В bridge в port создаю eth 5 + bridge 1
При такой схеме работает проблем нет, НО как только добавляю к eth 3 + bridge 1 . буквально через 8-15 пингов, канал ложится, с чем у меня вопрос, что не так ? o.O

ctich,
А третий порт у тебя нигде не больше не участвует?

Тут еще можно почитать

На момент тестирования нет, но время от времени он будет также активен, и поэтому должна быть полносвязность между тремя портами (2,3,5).
Может что то в фаерфолах надо подкрутить, завтра буду дальше мучить :scratch_one-s_head:
У меня в схеме ip адреса к вланам не привязаны (вернее не все), основная задача микротика — принять этот влан через аплинковый порт и просвичить на два других, и все ( на cisco, alcatel, huawei, zyxel, dlink как то проще, разрешил, прописал и забыл, а тут. ) .

update
возможно бред, но похоже нужно делать для порта 2+5 = bridge 1, 3+5 bridge 2. (по крайней мере на это натолкнула статья)

Сообщение отредактировал ctich — 03.12.14, 23:57

Источник

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

Комментарии 44

Чтобы это проверить, дополним правило для «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 очень подробно рассмотрена во второй части цикла статей. А в третьей будут еще и уточняющие диаграммы. После их прочтения данный вопрос у вас будет снят.

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

пакет от 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

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 serviceMS 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»

Источник

Mikrotik doh server connection error ssl internal error 6

Маршрутизаторы MikroTik — Обсуждение

Старая программа для конфигурирования — Winbox winbox.exe ( 111.5 КБ )
Новая программа для конфигурирования — Winbox winbox3.exe ( 1.39 МБ )
Версия 3.18 (исправлена совместимость с прошивками 6.43): winbox318.exe ( 1.58 МБ )
Версия 3.19 (исправлен логин в 6.45): winbox.exe ( 1.59 МБ )

]*ssdp:(alive|byebye)|^m-search[9-D ]\*[9-D ]http/1\.1[9-D —

]*user-agent: gnucleus [9-D —

]* Accept: application/x-rtsp-tunnelled|http/(0\.9|1\.0|1\.1) [1-5][0-9][0-9] [9-D —

Если вам требуется помощь в решении проблемы- выкладывайте свой конфиг: /export hide-sensitive terse

Сообщение отредактировал ferhad.necef — 03.01.23, 15:46

Smartecs, через L7 руки не дошли пока у самого на своём, но вроде как читал через webproxy можно, и вроде как: (где-то вычитал, почему-то запомнилось):
Cоздать разрешающее правило в котором ничего нет, кроме значения accept в action и просто разместить его перед/после правила, которое разрешает доступ.

У меня такая проблема на одном из встроенных в материнскую плату сетевых контроллеров. Так и не поборол, использую тот, который без проблем поднимает 100Мб.

Сообщение отредактировал Shoore — 03.12.14, 00:47

ToMaTo_0,
А после покупки делали полный сброс устройства, потом устанавливали свежую прошивку?

Добавлено 02.12.2014, 23:26:

Shoore,
Кстати думаю сообщения нужно перенести в тему указанную тобой.

ToMaTo_0,
Подключите роутер к другому ПК/ноуту/роутеру к чему нибудь где есть активный ethernet порт и посмотрите в статусе на сколько поднимется порт.
Интересует будет ли держать порт скорость 100/1000мб/с с другим устройством, не вашим ПК.
Также попробуйте на ПК «жестко» зажать порт на 100мб/с.

Сообщение отредактировал ctich — 03.12.14, 00:20

А можно уточнить расстояние «основного пачкорда» ??
Надеюсь не более 90м., и кабель обжат правильно.

Парни подскажите где туплю.
Необходимо доработать схему:
2 port tagged — vlan 55
3 port untagged — vlan 55
5 port tagged — vlan 55,56,57

Для vlan 56,57 создан bridge0 и с ними проблем нет.
Прописываю теперь 55 vlan.
Создаю vlan 55 указываю на interf 5
Создаю bridge 1
В bridge в port создаю приземляю vlan 55 на bridge 1
В bridge в port создаю eth 2 + bridge 1
В bridge в port создаю eth 5 + bridge 1
При такой схеме работает проблем нет, НО как только добавляю к eth 3 + bridge 1 . буквально через 8-15 пингов, канал ложится, с чем у меня вопрос, что не так ? o.O

ctich,
А третий порт у тебя нигде не больше не участвует?

Тут еще можно почитать

На момент тестирования нет, но время от времени он будет также активен, и поэтому должна быть полносвязность между тремя портами (2,3,5).
Может что то в фаерфолах надо подкрутить, завтра буду дальше мучить :scratch_one-s_head:
У меня в схеме ip адреса к вланам не привязаны (вернее не все), основная задача микротика — принять этот влан через аплинковый порт и просвичить на два других, и все ( на cisco, alcatel, huawei, zyxel, dlink как то проще, разрешил, прописал и забыл, а тут. ) .

update
возможно бред, но похоже нужно делать для порта 2+5 = bridge 1, 3+5 bridge 2. (по крайней мере на это натолкнула статья)

Сообщение отредактировал ctich — 03.12.14, 23:57

Источник

Ранее в первой (теоретической) части статьи была подробно описана сущность сетевого соединения глазами ядра маршрутизатора. В текущей части мы закрепим информацию в результате рассмотрения работы прикладного протокола 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