Что за прикол с правилами микротика?

Question

[Сергей]

Итак. Имеем два правила
chain=input action=accept connection-state="" in-interface=ether1-local log-prefix=""
chain=input action=drop in-interface=ether1-local log=no log-prefix=""
Верхнее правило разрешает весь входящий трафик. А нижнее запрещает весь входящий трафик. Оба относятся к одному и том же интерфейсу. Обращаю внимание что правило полные. В верхнем правиле присутствует только connection-state="" .. которое в свою очередь никак не обозначено. При таком раскладе второе правило умудряется еще чтото блочить. Что за нах????? Может я не правильно понимаю запись connection-state=""?

Comments

[Дмитрий Шицков]

А что оно блочит? Вы записали бы лог и посмотрели его.

[Сергей]

Дмитрий Шицков: пакеты не коим образом не отличающиеся от всех остальных. все подряд. конечно соотношение трафика есть .. если по первому правилу 8 гигов. то по второму 30 мегов.

[Кирилл Васильев]

Сергей: на вкладке action поставьте галку log и посмотрите что попадает под это правило.
А также уточните эти два правила находятся друг за другом? и на последнее не кто больше не ссылается jump?

[Сергей]

Кирилл Васильев: Правила идут друг за другом. нет не ссылается. логирование ставил. типичная сетевая активность. подобное же правило дублирующим весит на wireless и при этом является дублирующим для chain=input action=accept. но с connection-state="" . и один черт по нему щелкает что-то. то есть в данном случае даже сам этот флаг меняет логику обработки пакетов. и я не могу понять в чем она заключается.


это то что падает в логи с action=accept. но с connection-state="" с вафли. по первому правилу получается идет типичная вайфай активность.

[Сергей]

может я просто спал на уроках. но выставление на любом следом идущем правиле connection-state="" .. вне зависимости от входящие или исходящие пакеты ... главное чтобы правила относилось к одному логическому объекту ... приводит к странной активности по этому правилу. образец выше

[Сергей]

то есть в первом случае запрещающее правило не должно срабатывать вообще. во втором случае разрешающее правило является дублирующим.

[satoo]

если у вас wlan (как и любо другой подчиненный интерфейс) в бридже, то правила, направленные на этот интерфейс работать не будут. их надо выставлять на бридж

то, что вы указываете connection-state="" микротик игнорирует (как будто вы вообще эту опцию не используете)

сделайте дамп interface export и ip firewall export

Answer 1

[paxlo]

connection-state можеть быть только estabilished, invalid,new,related. Пустое означает отсутствие connection-state. В первом вы разрешаете весь входящий с eth1 трафик, вторым правилом запрещаете. Вопрос то в чем? И на будущее всегда приводите выхлоп не print а export (/ip f f e)

Comments

[Сергей]

вопрос в том почему второе правило умудряется чтото обрабатывать. если первое правило выше приоритетом и относится к тому же трафику! до него вообще ничего не должно доходить.