mikrotik. connection-state=established

[Опиум]

Что ознаечает в циске
ip access-list extended WAN-IN
permit tcp any any established
совершенно понятно.

Но, что означает в микротике запись в фаерволе:
add action=accept chain=input connection-state=established
без привязки к tcp мне не очень понятно.
???

(Это правило из дефолтного конфига микротика)

[Busla]

Опиум, это у Cisco двойные стандарты: в случае NAT она внутри себя формирует признак established не только для TCP, а для firewall это вдруг невозможно.

[Опиум]

Busla, спасибо.
Но если речь о gre туннеле (протоколе), то какой там простигосподи NAT задействован?
Это я клоню к тому что в микротике правило запрещающее 47 протокол в инпут цепочке не отрабоатывало после правила
add action=accept chain=input connection-state=established

[freese]

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

[Опиум]

freese, это то понятно.
Непонятно почему протокол gre причислен к протоколам устанавливающим соединение.
Когда микротик решает что соединение established? А когда уже нет..

[Busla]

Когда микротик решает что соединение established? »
к сожалению, на Микротики отвратная документация. Так что работу чуть ли не каждого правила стоит перепроверять :-/

Непонятно почему протокол gre причислен к протоколам устанавливающим соединение. »
А он не устанавливает соединение? - там вполне явно разделены фазы установки соединения и его эксплуатации.

[Опиум]

А он не устанавливает соединение? - там вполне явно разделены фазы установки соединения и его эксплуатации. »
насколько я знаю нет, какие там фазы? это просто протокол инкапсуляции...

[freese]

Опиум, у вас в чем конкретно проблема?
Когда микротик решает что соединение established? А когда уже нет.. »
вы занимаетесь реверс-инжинирингом? Можете разработчикам написать, они вам может быть и расскажут логику (хотя вряд ли)

[Опиум]

у вас в чем конкретно проблема? »
))
как я это указал выше у меня проблема в понимании. Если ты понимаешь как работает железка, значит и применяешь её правильно, а не "сделано на отъе*ись".

если у тебя есть понимание, что такое "established" для не-TCP в микротиках, то буду благодарным слушателем.

[freese]

если у тебя есть понимание, что такое "established" для не-TCP в микротиках, то буду благодарным слушателем. »
нет, нет полного понимания, но могу только сказать что у тика правила обычно чем то завязаны, и выше приведенное разрешается для чего то и должно быть рядом правило
и уже рядышком ваше /ip firewall filter add chain=input connection-state=established ... блаблабла

[Busla]

это просто протокол инкапсуляции... »
в современных реалиях обвешанный опциями и расширениями. GRE может нести в себе принадлежность к сесии, и AFAIK сейчас в основном так и используется

А в том исходном смысле простой инкапсуляции, его сейчас никто не использует, т.к. VLAN (придуманный позже) эффективнее

[Опиум]

в современных реалиях обвешанный опциями и расширениями. GRE может нести в себе принадлежность к сесии, »
не хило бы подкрепить свои слова цитатой из RFC ;)

VLAN (придуманный позже) эффективнее »
VLAN тут не о чем. Он работает на другом уровне OSI. Туннель GRE я могу организовать без поддержки провайдером.

уже рядышком ваше /ip firewall filter add chain=input connection-state=established ... блаблабла »
а рядышком, это выше или ниже?
а то цисковское эстаблишед можно ставить в самый верх ACL, не волнуясь, что через него гадость пролезет, а микротиковское эстаблишед этого не гарантирует.

[Busla]

не хило бы подкрепить свои слова цитатой из RFC »
не хило бы самому смотреть документацию. если так уже интересует вопрос

RFC 1701:
Key (4 octets)

The Key field contains a four octet number which was inserted by the encapsulator. It may be used by the receiver to authenticate the source of the packet. The techniques for determining authenticity are outside of the scope of this document. The Key field is only present if the Key Present field is set to 1.

Sequence Number (4 octets)

The Sequence Number field contains an unsigned 32 bit integer which is inserted by the encapsulator. It may be used by the receiver to establish the order in which packets have been transmitted from the encapsulator to the receiver. The exact algorithms for the generation of the Sequence Number and the semantics of their reception is outside of the scope of this document.

Ну и RFC 2890 говорит о том, что не стоит это дело использовать само по себе:
Security Considerations

This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE (Generic Routing Encapsulation) Header [1]. When using the Sequence number field, it is possible to inject packets with an arbitrary Sequence number and launch a Denial of Service attack. In order to protect against such attacks, IP security protocols [4] MUST be used to protect the GRE header and the tunneled payload. Either ESP (Encapsulating Security Payload) [5] or AH (Authentication Header)[6] MUST be used to protect the GRE header. If ESP is used it protects the IP payload which includes the GRE header. If AH is used the entire packet other than the mutable fields are authenticated. Note that Key field is not involved in any sort or security (despite its name).

[Опиум]

Цитата Busla:
The Sequence Number field contains an unsigned 32 bit integer which is inserted by the encapsulator. It may be used by the receiver to establish the order in which packets have been transmitted from the encapsulator to the receiver. »
это единственное что заслуживает внимания, однако смущает "may be".
Проверка установленности соединения GRE имхо можно задать только включив Keepalive на интерефейсах, ибо без него даже ошибочно настроенные концы туннеля (интерфейсы) становятся UP, как будто "соединение установлено".

И второе, GRE тут просто для примера, с которым я столкнулся. А что ты скажешь за UDP, который по микротику тоже может быть "эстаблишед"?)

как пример, UDP514, где между клиентом и syslog-сервером может быть микротик.