Вопросы по файрволу и модификации потоков.

Начал разбираться с файрвол-мэнглом и фильтрацией потоков. После многих лет простого копирования статей из Mikrotik Wiki, меня заставили писать собственные правила. Прочитав мануалы и вики настолько хорошо, насколько мог, у меня всё ещё есть несколько нерешённых вопросов: Сколько пакетных/соединительных/маршрутных меток можно добавить к одному пакету? Например, я использую connection/route метки для балансировки нагрузки, но хотел бы ещё форматировать P2P и QoS для VoIP. Переопределит ли вторая соединительная метка первую, или будет добавлена? То есть, если я хочу пометить согласно балансировке нагрузки connection/route метками, а потом ещё пометить их для QoS и/или других правил файрвола, типа защиты от брутфорс-атак? В wiki http://wiki.mikrotik.com/wiki/PCC, где соединения помечаются: add chain=prerouting dst-address-type=!local in-interface=Local per-connection-classifier=both-addresses:2/0 action=mark-connection new-connection-mark=wlan1_conn passthrough=yes add chain=prerouting dst-address-type=!local in-interface=Local per-connection-classifier=both-addresses:2/1 action=mark-connection new-connection-mark=wlan2_conn passthrough=yes 2a) Будет ли роутер автоматически помечать все пакеты, связанные с ранее conn-помеченным соединением, той же conn-меткой во время фазы conn-track? Если да, то будет ли он также автоматически добавлять предыдущую маршрутную метку? Если да, то почему нет правил перед этими проверками для passthrough=no для уже помеченных соединений? Допустим, на первом пакете соединение помечается во втором правиле (wlan2_conn). Следующий пакет, который прилетает, попадает в первое правило и это первый в «пакетке» из двух, не добавит ли первое правило/не переопределит ли оно метку wlan1_conn? Как оно останется помеченным как wlan2_conn? (Надеюсь, это имеет смысл) 2b) В http://wiki.mikrotik.com/wiki/NTH_in_RouterOS_3.x и в упомянутых PCc wiki нет connection-state=new, как в оригинальной wiki по Nth. Почему? 3a) При создании собственных цепей в mangle, если passthrough=no в вашей пользовательской цепи, она просто выходит из этой цепи, или из той основной цепи, в которую она перешла? 3b) Как можно предотвратить или разрешить действие accept/drop или passthrough=yes/no, чтобы также продолжать/останавливать обработку в основной цепи, которая вызвала её? Например, в моей собственной цепи, иногда я просто хочу выйти где-то в цепи и продолжить в основной цепи. Иногда я хочу остановить дальнейшую обработку этого пакета. Ekkas