В чем может быть проблема маршрутизации?

Question

[Владислав Прубняк]

Здравствуйте, имеются вот такие настройки в микротике, в чем может быть проблема при маршрутизации пакетов по протоколу udp?

Answer 1

[AUser0]

Дайте я, дайте я! Щас я...

В настройках может быть проблема!

P.S. Каков вопрос - таков и ответ.

Comments

[Владислав Прубняк]

Ну так я же скинул скрины настроек, какую ещё информацию предоставить что бы мне могли помочь?

[AUser0]

Владислав Прубняк, ну хотя-бы подробности с какого IP на какой IP не проходит UDP трафик? И лучше бы не скриншоты, на которых половину настроек не видно, а вывод /ip firewall filter print и /ip firewall nat print в консольном окне, есть такое в WinBox-е.

[Владислав Прубняк]

AUser0, 0 ;;; , OpenStreetMap
chain=forward action=drop protocol=tcp src-address=192.168.0.10
dst-address-list=!Open Streep Map dst-port=80,443 log=no log-prefix=""

1 chain=forward action=drop protocol=udp src-address=192.168.0.10
dst-address-list=!Open Streep Map dst-port=80,443 log=no log-prefix=""

2 ;;; , OpenStreetMap
chain=forward action=drop protocol=tcp src-address=192.168.0.5
dst-address-list=!Open Streep Map dst-port=80,443 log=no log-prefix=""

3 chain=forward action=drop protocol=udp src-address=192.168.0.5
dst-address-list=!Open Streep Map dst-port=80,443 log=no log-prefix=""

4 ;;;
chain=input action=accept connection-state=established,related,untracked
log=no log-prefix=""

5 ;;; DNS .
chain=input action=accept protocol=udp in-interface-list=!ISP dst-port=53
log=no log-prefix=""

6 ;;; DNS
chain=input action=accept protocol=udp src-port=53 log=no log-prefix=""

7 ;;;
chain=input action=drop connection-state=invalid log=no log-prefix=""

8 chain=input action=accept protocol=icmp log=no log-prefix=""

9 ;;; WinBox
chain=input action=accept protocol=tcp in-interface-list=!ISP
dst-port=8291 log=no log-prefix=""

10 ;;;
chain=input action=drop log=no log-prefix="drop"

11 chain=forward action=accept connection-state=established,related,untracked
log=no log-prefix=""

12 chain=forward action=drop connection-state=invalid log=no log-prefix=""

13 chain=forward action=accept connection-nat-state=!dstnat
in-interface-list=ISP log=no log-prefix=""
----------------

0 chain=srcnat action=src-nat to-addresses=95.78.121.166
src-address=192.168.0.0/24 out-interface-list=ISP log=no log-prefix=""

1 chain=srcnat action=src-nat to-addresses=95.78.121.166
src-address=172.16.10.0/24 out-interface-list=ISP log=no log-prefix=""

2 ;;; DNS Mikrotik
chain=dstnat action=redirect protocol=tcp dst-port=53 log=no
log-prefix=""

3 ;;; RDP 1
chain=dstnat action=dst-nat to-addresses=192.168.0.100 to-ports=3389
protocol=tcp in-interface-list=ISP dst-port=23389 log=no log-prefix=""

4 ;;;
chain=dstnat action=dst-nat to-addresses=192.168.0.5 to-ports=8001
protocol=tcp in-interface-list=ISP dst-port=8001 log=no log-prefix=""

5 chain=dstnat action=dst-nat to-addresses=192.168.0.5 to-ports=8001
protocol=udp in-interface-list=ISP dst-port=8001 log=no log-prefix=""

6 ;;;
chain=dstnat action=dst-nat to-addresses=192.168.0.10 to-ports=8001
protocol=tcp in-interface-list=ISP dst-port=8002 log=no log-prefix=""

7 chain=dstnat action=dst-nat to-addresses=192.168.0.10 to-ports=8001
protocol=udp in-interface-list=ISP dst-port=8002 log=no log-prefix=""

8 ;;;
chain=dstnat action=dst-nat to-addresses=192.168.0.50 to-ports=443
protocol=tcp in-interface-list=ISP dst-port=443 log=no log-prefix=""

9 chain=dstnat action=dst-nat to-addresses=192.168.0.50 to-ports=80
protocol=tcp in-interface-list=ISP dst-port=80 log=no log-prefix=""

Адреса ip от которого на пульт связываются всегда разный, так как приложения стоят на разных телефонах, а ip пульта 95.78.121.166

Answer 2

[Disel0k]

например в порядке правил фаерволла - 12 правило делает бесполезным 13... а уж что там внутри этих правил так и вообще хз.
А в целом вопрос из серии у меня машина не едет и фото багажника, движка и запаски...

Comments

[Владислав Прубняк]

0 ;;; , OpenStreetMap
chain=forward action=drop protocol=tcp src-address=192.168.0.10
dst-address-list=!Open Streep Map dst-port=80,443 log=no log-prefix=""

1 chain=forward action=drop protocol=udp src-address=192.168.0.10
dst-address-list=!Open Streep Map dst-port=80,443 log=no log-prefix=""

2 ;;; , OpenStreetMap
chain=forward action=drop protocol=tcp src-address=192.168.0.5
dst-address-list=!Open Streep Map dst-port=80,443 log=no log-prefix=""

3 chain=forward action=drop protocol=udp src-address=192.168.0.5
dst-address-list=!Open Streep Map dst-port=80,443 log=no log-prefix=""

4 ;;;
chain=input action=accept connection-state=established,related,untracked
log=no log-prefix=""

5 ;;; DNS .
chain=input action=accept protocol=udp in-interface-list=!ISP dst-port=53
log=no log-prefix=""

6 ;;; DNS
chain=input action=accept protocol=udp src-port=53 log=no log-prefix=""

7 ;;;
chain=input action=drop connection-state=invalid log=no log-prefix=""

8 chain=input action=accept protocol=icmp log=no log-prefix=""

9 ;;; WinBox
chain=input action=accept protocol=tcp in-interface-list=!ISP
dst-port=8291 log=no log-prefix=""

10 ;;;
chain=input action=drop log=no log-prefix="drop"

11 chain=forward action=accept connection-state=established,related,untracked
log=no log-prefix=""

12 chain=forward action=drop connection-state=invalid log=no log-prefix=""

13 chain=forward action=accept connection-nat-state=!dstnat
in-interface-list=ISP log=no log-prefix=""
----------------

0 chain=srcnat action=src-nat to-addresses=95.78.121.166
src-address=192.168.0.0/24 out-interface-list=ISP log=no log-prefix=""

1 chain=srcnat action=src-nat to-addresses=95.78.121.166
src-address=172.16.10.0/24 out-interface-list=ISP log=no log-prefix=""

2 ;;; DNS Mikrotik
chain=dstnat action=redirect protocol=tcp dst-port=53 log=no
log-prefix=""

3 ;;; RDP 1
chain=dstnat action=dst-nat to-addresses=192.168.0.100 to-ports=3389
protocol=tcp in-interface-list=ISP dst-port=23389 log=no log-prefix=""

4 ;;;
chain=dstnat action=dst-nat to-addresses=192.168.0.5 to-ports=8001
protocol=tcp in-interface-list=ISP dst-port=8001 log=no log-prefix=""

5 chain=dstnat action=dst-nat to-addresses=192.168.0.5 to-ports=8001
protocol=udp in-interface-list=ISP dst-port=8001 log=no log-prefix=""

6 ;;;
chain=dstnat action=dst-nat to-addresses=192.168.0.10 to-ports=8001
protocol=tcp in-interface-list=ISP dst-port=8002 log=no log-prefix=""

7 chain=dstnat action=dst-nat to-addresses=192.168.0.10 to-ports=8001
protocol=udp in-interface-list=ISP dst-port=8002 log=no log-prefix=""

8 ;;;
chain=dstnat action=dst-nat to-addresses=192.168.0.50 to-ports=443
protocol=tcp in-interface-list=ISP dst-port=443 log=no log-prefix=""

9 chain=dstnat action=dst-nat to-addresses=192.168.0.50 to-ports=80
protocol=tcp in-interface-list=ISP dst-port=80 log=no log-prefix=""

Вот полный список правил, помогите разобраться пожалуйста

[Disel0k]

На первый взгляд косяков не нашел, хотя в целом правила странные, первое что бросается в глаза - цепочка forward у Вас остается незакрытой. В наше время Нормально открытый фаервол достаточно редкое явление.
Для начала я бы очень рекомендовал навести немного порядка.
- Сначала правила цепочки Input, затем forward - на работу не влияет, но Вам станет понятнее что у Вас творится.
- Для каждой цепочки последнее правило запрещающее ВСЕ, перед ним ряд правил разрешающий трафик по конкретным критериям.
По идее получится приметно вот так:

0 ;;; разрешаем уже установленные соединения
chain=input action=accept connection-state=established,related,untracked
log=no log-prefix=""

1 ;;; разрешим пинги и прочее icmp
chain=input action=accept protocol=icmp 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

не забываем дописать
/ip firewall address-list
add address=192.168.0.5 list=streetwalker
add address=192.168.0.10 list=streetwalker

дальше уже можно будет смотреть и разбираться

Answer 3

[damis]

А какие откуда и куда не бегают пакеты? В чем именно заключается проблема?

Comments

[Владислав Прубняк]

Данный микротик работает на пульту охранной организации. И мобильные приложения хреново работают с пультом, очень часто теряют связь и долго обратно восстанавливаются. Обратились к ним они попробовали подключаться к пульту и сказали что пульт постоянно обрывает соединения ,ищите проблему в маршрутизации

[damis]

Владислав Прубняк, видно , что есть проброс портов и трафик бегает.
Подключение идет извне по мобильной связи?

И не получается ли так, что телефон в момент потери связи с пультом охраны переключается на вай фай (если он есть)?

[Владислав Прубняк]

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

[damis]

Владислав Прубняк, Интересно)
Тогда самое простое - в момент потери связи обнулять счетчик пакетов (кнопка Reset Counters) на правиле проброса порта, это 4,5,6,7 правила NAT.
И смотреть как скоро начнут бегать пакеты и в каком количестве.

Ну и еще в bridge запустить Torch указав в Src.Address 192.168.0.5 и посмотреть на какие айпи бегают пакеты.

[Владислав Прубняк]

damis, так устройств много, а остановить микротик невозможно так как там ещё и стационарная охранная сигнализация

[damis]

Владислав Прубняк, микротик не остановится)

[Владислав Прубняк]

damis, я имею ввиду что не понятно будет откуда именно идут пакеты, если не остановить все подключения кроме того который проверяешь, а это никак не сделаешь

[Владислав Прубняк]

damis, а вообще нет там никаких лишних правил случайно? Может там что не правильно настроено?

[damis]

Владислав Прубняк,

не понятно будет откуда именно идут пакеты

как минимум с помощью Torch немного станет ясно куда и по каким портам идет трафик.

вообще нет там никаких лишних правил случайно?

я не работал со струной.
Поэтому интересно зачем этим двум устройствам блокируют вэб траффик, кроме openstreetmap (понятно что в этот сервис они передают информацию о местоположении).

И достаточно большой трафик от правой Струны (по сравнению с левой) тоже не понятен.

[Владислав Прубняк]

damis, вэб трафик блокируем что бы операторы ночью на дежурстве на рабочей станции кино не смотрели, а правая струна больше нагружена так как она основная, а левая это просто резерв на случай если что то случится с правой. Струна и весь наш трафик(проблемный) должен идти только по 8001 порту на правую струну