Comments 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
Этого достаточно?
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"
«Теоретическая часть цикла статей позволяет нам на него ответить – будет создано 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
А при чем тут MikroTik->DNS Servers Connections, если пакет летит от микротика к pc, а не к dns серверу?
Почему тогда в логе в дестинейшн ПК, а не внешний dns сервер, и почему пакет не НА 53 порт, а С 53 порта?
Почему вы решили что дропает пакет на внешний dns сервер?
А новые соединений к dns серверам от микротика, это 10е правило в выгрузке.
;;; 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 я просто проглядел.
https://yadi.sk/d/KwdZFiiMJ41iUw
Зацензурил только серийник
/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 это будет не скучно сделать.
Делаю вывод, что пакеты от 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 пакеты почему-то не проходят фаервол.
Пока с ваших слов видно, что вы имеете дело с тем, что получаете не тот результат, что ожидаете. Начали с DNS протокола. Теперь добавляете SSL в комментарии. С учетом количества правил в вашем Firewall, в нем не сложно запутаться. Уберите все лишнее, выполните отладку для конкретной проблемы. Затем постепенно включайте другие правила и анализируйте ситуацию. Обычный troubleshooting. Ситуацию про работу DNS протокола я вам описал, можете на нее опираться.
Мой вывод основан на действиях, представленных выше. Объясните, почему он не правилен?
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 в принципе работает, то и забей на логи.
Уберите все лишнее, выполните отладку для конкретной проблемы.
я не могу сделать это на проде. Лишнее = или функционал или безопасность.
Тем более что у меня проблема что НИ ОДНО правило(кроме последнего) не отрабатывает. Что может измениться от того, что я ещё уменьшу количество правил(т.е. ещё уменьшу вероятность срабатывания правил кроме последнего)
Термин вероятности тут конечно неправильный, но я думаю вы поняли.
Я честно не понимаю зачем нужно разбирать мой фаервол.
Если правила в нём НЕ срабатывают (раз дело доходит до последнего правила)
И тем более почему нужно разбирать все 60 правил, если нас интересует только output.
Причина должна быть в чём-то другом. Мне кажется есть какой-то нюанс в коннекшн трекере.
Удалите все лишнее и по шагам идите до нужного (ожидаемого, контролируемого) результата, не переступая через «непонятки».
Я уже сделал это. Я не смотрю на работу DOH. Я смотрю на самый базовый уровень(DNS пакеты). И всё равно ожидаемого результата не получаю.
Если я сломаю все правила и оставлю только DNS... ну а толку, У меня сейчас есть лог с 29 ноября... ни одного пакета DNS пакета не дропнуло. Ну и сколько мне без интернета сидеть чтобы таким способом отловить проблему?
А правил куча как раз для того, чтобы было видно что и где ходит.
Хотя сейчас подумал... добавил логирующие правила перед последним output для UDP из 53 порта со state new\invalid\untracked. Посмотрим попадётся ли в них что.
Что у вас с fasttrack ?
не используется.
Опять дропнулся пакет.
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
Не понял.
Если DNS клиент обращается к DNS серверу, то пакет будет НА 53 порт. А тут он ИЗ 53 порта.
и 192.168.66.6 не DNS сервер. Я вроде это уже 3-й раз пишу, но ответа не получаю.
Перед тем, как пойдет выполнение команды ping, роутер сначала отрезолвит доменное имя mail.ru. И этот резолвинг будет у него new.
Вот этот резолвинг (залогирован другим правилом)
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-й раз пишу.
Как пакет ИЗ (а не НА) 53 порта может иметь connection state=new»?
Это ваш вопрос, на который выше был дан ответ.
Можете ли вы рассказать, как файервол RouterOS функционирует в случае прохождения трафика через разные VRF на одном маршрутизаторе? Например, если все VRF через динамическую маршрутизацию связаны с неким внешним узлом, выполняющим функцию сетевого экрана. В частности, я сталкивался с некорректной работой NAT.
Подозреваю, что вследствие неполной изоляции VRF на RouterOS здесь есть много тонкостей.
Если не сложно, можно ли подробнее, в какой ситуации у Вас проявилась неполная изоляция vrf?
Имеется роутер 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.
VRF в Mikrotik неполноценный. Я не разбираюсь в линуксе, но давняя статья поясняет причины, почему в RouterOS не существует VRF-зависимых сервисов (telnet, ssh, DHCP relay и пр.), почему возникает ситуация из моего комментария выше и почему разработчики RouterOS уже лет десять обещают нормально изолированный VRF в ROS7.
/ip firewall filter
...
add action=drop chain=input comment="Drop DOS list" src-address-list=DOS
Почему не в RAW?
Страх и ненависть в RouterOS: что такое сетевое соединение в ядре Linux (часть 2 — практика)