Ранее в первой (теоретической) части статьи была подробно описана сущность сетевого соединения глазами ядра маршрутизатора. В текущей части мы закрепим информацию в результате рассмотрения работы прикладного протокола 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)
kterik
26.11.2021 19:21Можете ли вы рассказать, как файервол RouterOS функционирует в случае прохождения трафика через разные VRF на одном маршрутизаторе? Например, если все VRF через динамическую маршрутизацию связаны с неким внешним узлом, выполняющим функцию сетевого экрана. В частности, я сталкивался с некорректной работой NAT.
Подозреваю, что вследствие неполной изоляции VRF на RouterOS здесь есть много тонкостей.
Kiano
27.11.2021 02:08Если не сложно, можно ли подробнее, в какой ситуации у Вас проявилась неполная изоляция vrf?
kterik
27.11.2021 09:56Имеется роутер 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.
olegtsss Автор
27.11.2021 05:58Тема маршрутизации в RouterOS действительно требует глубокого разбора. Термин «неполная изоляция» считаю не уместным. Думаю, проблема в настройках сети (устройств), а не в MikroTik.
kterik
27.11.2021 10:04VRF в Mikrotik неполноценный. Я не разбираюсь в линуксе, но давняя статья поясняет причины, почему в RouterOS не существует VRF-зависимых сервисов (telnet, ssh, DHCP relay и пр.), почему возникает ситуация из моего комментария выше и почему разработчики RouterOS уже лет десять обещают нормально изолированный VRF в ROS7.
barlog1
29.11.2021 06:59+1/ip firewall filter
...
add action=drop chain=input comment="Drop DOS list" src-address-list=DOS
Почему не в RAW?
olegtsss Автор
29.11.2021 18:46Спасибо за верный комментарий. Намеренно, чтобы не усложнять материал (ведь под диаграммы отведена отдельная третья часть цикла статей. Однако вопрос борьбы с DOS в ней уже не поднимается. Конечно, банить лучше в RAW. Явно указал в статье.
Tarakanator
Пока непонятно. Почему у вас счётчик работает. А у меня в фаервольные правила иногда не попадает.
Я чего-то не понял или мне надо ждать 3-ю часть?
olegtsss Автор
Исправьте в своем правиле log=yes. После этой части должно быть все ясно. Третья часть является дополнением, касательно работы DNS протокола.
Tarakanator
Исправил, полюбовался на километры лога.
Выключил.
Сделал правило с логированием только с 53 порта... ну вроде всё правильно выглядит. Куда смотреть-то?
olegtsss Автор
Сформулируйте ваш вопрос.
Tarakanator
пакет от 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 Автор
Приведите все правила вашего firewall filter.
Tarakanator
Этого достаточно?
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 Автор
В представленных выше материалах есть вывод:
«Теоретическая часть цикла статей позволяет нам на него ответить – будет создано 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 Автор
В третьей части цикла статей будет много схем прохождения трафика, которые поясняют материал. Но уже сейчас все должно стать ясно.
Tarakanator
А при чем тут MikroTik->DNS Servers Connections, если пакет летит от микротика к pc, а не к dns серверу?
olegtsss Автор
Смотрите какая ситуация. Пакеты, которые летят от микротика к pc последним правилом своего firewall вы не дропаете. Вы дропаете пакеты от встроенного DNS сервера RouterOS в сторону следующего DNS сервера (например, интернет провайдера). Пакеты «MikroTik->DNS Servers Packets».
Tarakanator
Почему тогда в логе в дестинейшн ПК, а не внешний dns сервер, и почему пакет не НА 53 порт, а С 53 порта?
Почему вы решили что дропает пакет на внешний dns сервер?
А новые соединений к dns серверам от микротика, это 10е правило в выгрузке.
olegtsss Автор
Я симулировал ситуацию для правил:
;;; 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 я просто проглядел.
Tarakanator
https://yadi.sk/d/KwdZFiiMJ41iUw
Зацензурил только серийник
olegtsss Автор
Разбираемся с вашим случаем. Из всей выгрузки оставляю значимые правила:
/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
Неправильно делаете вывод.
Это значит что ОБЫЧНО пакеты попадают в разрешающее правило.
Но практика показывает что так происходит не со всеми пакетами.
Ещё раз. Я не жалуюсь что у меня в принципе 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 Автор
Мой вывод основан на действиях, представленных выше. Объясните, почему он не правилен?
Пока с ваших слов видно, что вы имеете дело с тем, что получаете не тот результат, что ожидаете. Начали с DNS протокола. Теперь добавляете SSL в комментарии. С учетом количества правил в вашем Firewall, в нем не сложно запутаться. Уберите все лишнее, выполните отладку для конкретной проблемы. Затем постепенно включайте другие правила и анализируйте ситуацию. Обычный troubleshooting. Ситуацию про работу DNS протокола я вам описал, можете на нее опираться.
Tarakanator
1)Потому, что такие-же действия с моей стороны выдают такой-же результат. Но при этом в логах события аналогичные вышеуказанному проскакивают.
2)
а)192.168.66.6 НЕ DNS СЕРВЕР.
б)Если пакет летит на DNS сервер, то он летит на 53 порт, а тут летит ИЗ 53 порта.
Соответственно это не может быть «MikroTik->DNS Servers Packets»
это я на случай чтобы вы не сказали что раз DNS в принципе работает, то и забей на логи.
я не могу сделать это на проде. Лишнее = или функционал или безопасность.
Тем более что у меня проблема что НИ ОДНО правило(кроме последнего) не отрабатывает. Что может измениться от того, что я ещё уменьшу количество правил(т.е. ещё уменьшу вероятность срабатывания правил кроме последнего)
Термин вероятности тут конечно неправильный, но я думаю вы поняли.
olegtsss Автор
Я вижу, что в ваших логах что-то не так. Вам надо разбираться. Выражения, что что-то работает, то не работает не корректно, так как техника всегда имеет под строгий алгоритм функционирования. Устройство и протоколы работают так, как запрограммированы. Если что-то не так, как вы ожидаете, тогда приступаете к troubleshooting.
olegtsss Автор
Если вы думаете, что кому-то интересно разбирать ваш firewall в более 60 правил и искать причину, почему результат не тот, как вы ожидаете, то я думаю это не так). Примените метод абстрагирования. Удалите все лишнее и по шагам идите до нужного (ожидаемого, контролируемого) результата, не переступая через «непонятки».
Tarakanator
Я честно не понимаю зачем нужно разбирать мой фаервол.
Если правила в нём НЕ срабатывают (раз дело доходит до последнего правила)
И тем более почему нужно разбирать все 60 правил, если нас интересует только output.
Причина должна быть в чём-то другом. Мне кажется есть какой-то нюанс в коннекшн трекере.
Я уже сделал это. Я не смотрю на работу DOH. Я смотрю на самый базовый уровень(DNS пакеты). И всё равно ожидаемого результата не получаю.
Если я сломаю все правила и оставлю только DNS... ну а толку, У меня сейчас есть лог с 29 ноября... ни одного пакета DNS пакета не дропнуло. Ну и сколько мне без интернета сидеть чтобы таким способом отловить проблему?
А правил куча как раз для того, чтобы было видно что и где ходит.
Хотя сейчас подумал... добавил логирующие правила перед последним output для UDP из 53 порта со state new\invalid\untracked. Посмотрим попадётся ли в них что.
olegtsss Автор
Что у вас с fasttrack ?
Tarakanator
не используется.
Tarakanator
Опять дропнулся пакет.
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 Автор
Например, когда MikroTik осуществляет резолв по собственной инициативе. У вас в конфиге использованы DNS имена? Соответственно по таймеру нужно резолвить, и это будут new.
Tarakanator
Не понял.
Если DNS клиент обращается к DNS серверу, то пакет будет НА 53 порт. А тут он ИЗ 53 порта.
и 192.168.66.6 не DNS сервер. Я вроде это уже 3-й раз пишу, но ответа не получаю.
olegtsss Автор
Давайте вам объясню на примере, рассчитываю, что так вам будет все яснее. Откройте консоль на роутере и выполните в ней команду: /ping mail.ru
Перед тем, как пойдет выполнение команды ping, роутер сначала отрезолвит доменное имя mail.ru. И этот резолвинг будет у него new.
Tarakanator
Вот этот резолвинг (залогирован другим правилом)
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 Автор
«Возникает вопрос:
Как пакет ИЗ (а не НА) 53 порта может иметь connection state=new»?
Это ваш вопрос, на который выше был дан ответ.
olegtsss Автор
Напоминаю, что у «UDP» соединения глазами RouterOS есть таймаут (udp-timeout: 10s). Если ответ придет позже, то ответ на резолвинг клиента будет тоже new.
Tarakanator
1)это что за тормозной сервер должен быть, чтобы по 10 сек ждать?
2)я увеличил до 20 сек, не помогло.
3)20 секундные таймауты я бы заметил
Хотя... Сейчас обдумал, а может вы и правы. у меня же какая-то нездоровая хрень с DOH есть. возможно какие-то ответы действительно за 20 сек выбиваются.
olegtsss Автор
Я бы все равно посоветовал выполнить дамп и внимательно его разобрать.
olegtsss Автор
«192.168.66.1:53->192.168.66.6:55628, len 60» Выполните запись трафика, изучите содержание пакета.
Tarakanator
А как при записе трафика определить какой именно пакет был дропнут? DNS ответов же куча будет.
olegtsss Автор
Я бы советовал это сделать посредством маркировки трафика.