Ин = билайн – значит, даунлоад. Аут = билайн – значит, аплоад

/me чешет затылок

потому что билайн смотрит в мир

Либо, если бриджом, то аут бридж – даунлоад, ин бридж – аплоад

А в случае с бриджем будет наоборот, верно?

☝️

то есть два аута

Блять

Я понял вроде

очередная попытка

А в случае с бриджем будет наоборот, верно?

потому что я нахожу по другую сторону

У любого форвард траффика есть ин и аут

Я понял

если я отдаю в интернет - то это аут

если я скачиваю в бридж - это тоже аут

если я скачиваю из мира - это ин

если забираю из бриджа - это ин

оно?

Не путайте тёплое и мягкое. Давайте издалека. У вас есть локальная сетка. Интерфейс называется бридж. И у вас есть внешняя сетка. Интерфейс называется билайн. ТАк?

да

Я нахожусь между ними, верно?

Теперь ответьте мне сами: вы запрашиваете у яндекса страничку. Ваш запрос прилетает на какой интерфейс роутера?

А то я не пойму где 0, как говорится

Между ними роутер, а не Вы

Ну я имею ввиду что я=роутер

Теперь ответьте мне сами: вы запрашиваете у яндекса страничку. Ваш запрос прилетает на какой интерфейс роутера?

это аут на билайн

Ок, Вы ответили на следующий мой вопрос, куда это дальше улетит. А прилетает этот запрос на бридж

Т.е. мы смотрим направление пакетов относительно роутера

А, ну да, я опять не с той стороны посмотрел

Т.е. в случае, когда траффик идёт из локальной сети в инет, он сначала попадает на бридж (in-interface), обрабатывается и улетает через билайн (out-interface). Когда Вы качаете — то траффик прилетает на билайн (in-interface) и идёт к вашему компу через бридж (out-interface)

Надеюсь, хоть чуть разобрались

Ибо я всё

ну понял

да

вроде понял

Я просто думал что in/out определяется там где роутер

то есть бежду бриджем и билайном

@moneron А чаин то будет forward или postrouting?)

Я просто думал что in/out определяется там где роутер

А я написал про что-то другое?

А я написал про что-то другое?

Я не могу сформулировать, но я понял)

А чейны куда?)

А чейны куда?)

https://mum.mikrotik.com/presentations/EU16/presentation_2901_1456413105.pdf

https://mum.mikrotik.com/presentations/EU16/presentation_2901_1456413105.pdf

C тем же успехом можно было пистолет мне выдать с одним патроном)

C тем же успехом можно было пистолет мне выдать с одним патроном)

Ну что ещё ответить... Приходите — научу

Для этого надо к вам приехать на недельку

C тем же успехом можно было пистолет мне выдать с одним патроном)

Читай все. С начала и до упора.

А вот это главная проблема, т.к. надо найти время и т.д.

Если бы вы у меня в городе были - я бы давно уже на все курсы сходил)

@ZZToP А вы еще тут?)

Тут

И прекрати выкать, мы в интернете

Тут обращение на "вы" почти оскорбление

Я тут вроде раскидал и зашел в тупик

И прекрати выкать, мы в интернете

не могу, привык к ненакомым и малознакомым на вы)

add chain=forward action=mark-connection connection-mark=no-mark new-connection-mark=QoS_HTTP passthrough=yes protocol=tcp dst-port=80,443 comment=HTTP add chain=forward action=mark-connection connection-mark=no-mark new-connection-mark=QoS_DNS passthrough=yes protocol=udp dst-port=53,123 comment=HTTP add chain=forward action=mark-connection connection-mark=no-mark new-connection-mark=QoS_SERVICE passthrough=yes protocol=udp dst-port=110,995,143,993,25,20,21 comment=HTTP

вот три правила в маркировку коннектов

А как мне маркировать все оставшееся?

=)

что не вошло в эти 4

Сорри, думать уже сложновато

ну ебанаврот)

Но щас попробую

add chain=forward action=mark-connection connection-mark=no-mark new-connection-mark=QoS_OTHER passthrough=yes

как то так?

А как мне маркировать все оставшееся?

Во всех правилах passthrough=no и в конец правило на connection-mark=no-mark, action=mark-connection, new-connmark=all_the_rest

точно passthrough=no? там в премере Алексея было как раз наоборот)

ERROR: S client not available

Ну смотри. Если пакет удовлетворяет условиям первого - ему присваивается метка коннекшна

угу

Но при этом этот же пакет проверяется во втором правиле на наличие метки

И в третьем

да

И в четвёртом

add chain=forward action=mark-connection connection-mark=no-mark new-connection-mark=QoS_OTHER passthrough=no comment=OTHER

А при пастру=ноу он дальше не пойдёт проверяться

короче вот так

Совсем

А при пастру=ноу он дальше не пойдёт проверяться

ну так а мне же надо что бы оно дальше падало в остальные, не?

Потому я бы при разных входящих условиях у первых правил и одном экшне (выставление метки коннекшну) не пускал бы пакет на остальные проверки

Раз уже помечен - нафиг перепомечать или проверять на наличие метки

окей

ну так а мне же надо что бы оно дальше падало в остальные, не?

А в остальные попадёт все, что не попало под условия первых трёх правил

add chain=forward action=mark-connection connection-mark=no-mark new-connection-mark=QoS_OTHER passthrough=no comment=OTHER

вот так верно?

и ставлю его в конец

Потому пастру=ноу на всех четырех

окей

add chain=forward action=mark-connection connection-mark=no-mark new-connection-mark=QoS_OTHER passthrough=no comment=OTHER

Да, верно

У каждого хирурга свой подход, я смотрю )

Ну и проверь сразу

У каждого хирурга свой подход, я смотрю )

а вы по-другому считаете?

У каждого хирурга свой подход, я смотрю )

А зачем проверять пакет, который уже был помечен, в каждом правиле? Нагрузку на ЦПУ дать лишнюю?

Ну и проверь сразу

Я могу заблуждаться, это чисто теоретические выкладки. Давно не колупал мангл микротика :)

А как Вы пометите пакеты по коннекшн-марке в той же цепочке, не дав им пройти дальше?

Имхо, можно метить коннекшны и пакеты в разных цепочках, но тогда в разы проще запутаться

Поэтому есть такое условие connection-mark=no-mark, чтобы искалось совпадение только по немаркированным коннекшнам

А как Вы пометите пакеты по коннекшн-марке в той же цепочке, не дав им пройти дальше?

Как "не дав"? Пакет пришёл, коннекшн марк проставился на соединение целиком, пакет ушёл дальше на куос. Следующий пакет проскочит правила уже с меткой, нет?

В общем, проверил я маркировку

что то вяло течет

и как сквозь решето