Владислав Прубняк, ну хотя-бы подробности с какого IP на какой IP не проходит UDP трафик? И лучше бы не скриншоты, на которых половину настроек не видно, а вывод /ip firewall filter print и /ip firewall nat print в консольном окне, есть такое в WinBox-е.
например в порядке правил фаерволла - 12 правило делает бесполезным 13... а уж что там внутри этих правил так и вообще хз.
А в целом вопрос из серии у меня машина не едет и фото багажника, движка и запаски...
На первый взгляд косяков не нашел, хотя в целом правила странные, первое что бросается в глаза - цепочка forward у Вас остается незакрытой. В наше время Нормально открытый фаервол достаточно редкое явление.
Для начала я бы очень рекомендовал навести немного порядка.
- Сначала правила цепочки Input, затем forward - на работу не влияет, но Вам станет понятнее что у Вас творится.
- Для каждой цепочки последнее правило запрещающее ВСЕ, перед ним ряд правил разрешающий трафик по конкретным критериям.
По идее получится приметно вот так:
0 ;;; разрешаем уже установленные соединения
chain=input action=accept connection-state=established,related,untracked
log=no log-prefix=""
2 ;;; Разрешаем запросы к DNS от всех кроме повайдеров - боимся злых хакеров (и правильно делаем)
chain=input action=accept protocol=udp in-interface-list=!ISP dst-port=53 log=no log-prefix=""
3 ;;; Не понял сокрального смысла этого правила - можно стучаться на микротик кому угодно но только с 53 порта? Т.е. Нувот даже на винбокс можно если с 53 на 8291 запрос оформить... я бы убивал...
chain=input action=accept protocol=udp src-port=53 log=no log-prefix=""
4 ;;; Разрешаем подключения WinBox от всех кроме повайдеров - боимся злых хакеров (и правильно делаем)
chain=input action=accept protocol=tcp in-interface-list=!ISP dst-port=8291 log=no log-prefix=""
5 ;;; И вот тут, глядя на следующее правило мы задумываемся, а нужно ли оно вообще. Хотя, учитывая количество срабатываний его можно поднять повыше и упростить жизнь роутеру в плане нагрузки
chain=input action=drop connection-state=invalid log=no log-prefix=""
6 ;;; Дропаем все - это и называется нормально закрытый фаерволл
chain=input action=drop log=no log-prefix="drop"
7 ;;; разрешаем уже установленные соединения
chain=forward action=accept connection-state=established,related,untracked log=no log-prefix=""
8 ;;; смотри правило 6
chain=forward action=drop connection-state=invalid log=no log-prefix=""
9 ;;; вот совсем не понял, вот если бы accept для dstnat, или наоборот drop для !dstnat, а так - это странный заменитель accept для srcnat? но для пакетов от провайдера? У Вас же есть правила dstnat, почему вы им не желаете добра?
chain=forward action=accept connection-nat-state=!dstnat in-interface-list=ISP log=no log-prefix=""
9a ;;; Может хотели разрешить трафик тем, кому прописываете правила snat|dstnat в секции nat? тогда это так
chain=forward action=accept connection-nat-state=srcnat,dstnat
10 ;;; Разрешим избранным ходить на OpenStreetMap заодно сократим количество правил с помощью еще одного адес листа. Кстати а к чему пробелы в имени листа, нет оно конечно можно, но зачем?
chain=forward action=accept protocol=tcp src-address-list=streetwalker dst-address-list=OpenStreepMap dst-port=80,443 log=no log-prefix=""
11 ;;; Судя по счетчику правило не используется
chain=forward action=accept protocol=udp src-address=192.168.0.10 dst-address-list=!Open Streep Map dst-port=80,443 log=no log-prefix=""
13 ;;; Судя по счетчику правило не используется
chain=forward action=accept protocol=udp src-address=192.168.0.5 dst-address-list=!Open Streep Map dst-port=80,443 log=no log-prefix=""
14 ;;; Вот и тут делаем все закрытым, а не полагаемся на волю случая
chain=forward action=drop
Данный микротик работает на пульту охранной организации. И мобильные приложения хреново работают с пультом, очень часто теряют связь и долго обратно восстанавливаются. Обратились к ним они попробовали подключаться к пульту и сказали что пульт постоянно обрывает соединения ,ищите проблему в маршрутизации
damis, Да подключение из мобильной сети. Нет проверял из офиса с отключенным wifi и разработчик программы оператора и приложения проверял с другого города
Владислав Прубняк, Интересно)
Тогда самое простое - в момент потери связи обнулять счетчик пакетов (кнопка Reset Counters) на правиле проброса порта, это 4,5,6,7 правила NAT.
И смотреть как скоро начнут бегать пакеты и в каком количестве.
Ну и еще в bridge запустить Torch указав в Src.Address 192.168.0.5 и посмотреть на какие айпи бегают пакеты.
damis, я имею ввиду что не понятно будет откуда именно идут пакеты, если не остановить все подключения кроме того который проверяешь, а это никак не сделаешь
как минимум с помощью Torch немного станет ясно куда и по каким портам идет трафик.
вообще нет там никаких лишних правил случайно?
я не работал со струной.
Поэтому интересно зачем этим двум устройствам блокируют вэб траффик, кроме openstreetmap (понятно что в этот сервис они передают информацию о местоположении).
И достаточно большой трафик от правой Струны (по сравнению с левой) тоже не понятен.
damis, вэб трафик блокируем что бы операторы ночью на дежурстве на рабочей станции кино не смотрели, а правая струна больше нагружена так как она основная, а левая это просто резерв на случай если что то случится с правой. Струна и весь наш трафик(проблемный) должен идти только по 8001 порту на правую струну
