Почему не отрабатывает правило?

Обсуждение ПО и его настройки
Lurker
Сообщения: 159
Зарегистрирован: 29 апр 2021, 10:45

Не совсем так.
Он не инициирует трафик с 50002.
Но когда к нему прилетает на 50002, то логично что он отвечает с 50002
Хотя всё равно не сходится... Мой торрент же первым в GRE1 лезет(шаг3) т.е. ответные пакеты это уже не новое соединение... Похоже микротик считает что это старое соединение, несмотря на то, что пакет прилетел с другого интерфейса, но статус соединения dstnat. А такие с GRE1 не пускаются.


xvo
Сообщения: 4204
Зарегистрирован: 25 фев 2018, 22:41
Откуда: Москва

Lurker писал(а): 20 июл 2021, 11:44 Но когда к нему прилетает на 50002, то логично что он отвечает с 50002
В mangle надо правило добавить, которое будет помечать все соединения, которые прилетели не через VPN, чтобы ответные пакеты этих соединений тоже помечались, как то, что отправлять не через VPN.


Telegram: @thexvo
Lurker
Сообщения: 159
Зарегистрирован: 29 апр 2021, 10:45

Не надо. Тогда проблема что в VPN летает то, что не должно не будет видна.
Хотя, если это не единичная проблема, то вероятно надо будет подставить этот костылёк, но вроде пока ок.


xvo
Сообщения: 4204
Зарегистрирован: 25 фев 2018, 22:41
Откуда: Москва

Lurker писал(а): 20 июл 2021, 15:25 Не надо. Тогда проблема что в VPN летает то, что не должно не будет видна.
Не понял: тогда проблемы не будет вообще - что не должно лететь в впн, туда и не полетит.

И это не костылек, а базовая логика мульти-WAN'а: что с какого WAN прилетело, в него же и должно быть отправлено в ответ.
Без этого и получаются вот всякие такие "поломанные" соединения.


Telegram: @thexvo
Lurker
Сообщения: 159
Зарегистрирован: 29 апр 2021, 10:45

Так и без этого оно правильно будет летать, если конфиг правильный.
у меня было неправильно то, что с 50002 не маркировался трафик для маршрутизации.
Т.е. если конфиг правильный правило откуда прилетело туда и улетает не нужно.
Если конфиг не правильный... то правило маскирует проблему. Да работать будет, но не через тот интерфейс, через который ожидалось.


xvo
Сообщения: 4204
Зарегистрирован: 25 фев 2018, 22:41
Откуда: Москва

А что тогда имеется ввиду под "правильный"/"не правильный"?
Lurker писал(а): 21 июл 2021, 08:06 Да работать будет, но не через тот интерфейс, через который ожидалось.
Если к вам снаружи приходит пакет на WAN1 то вы ответный пакет должны отправить через WAN1, так что это именно через тот интерфейс, который ожидается. И иначе оно именно что не будет работать вообще.


Telegram: @thexvo
Lurker
Сообщения: 159
Зарегистрирован: 29 апр 2021, 10:45

А что тогда имеется ввиду под "правильный"/"не правильный"?
Если конфиг такой, что NAT настроен принимать пакеты снаружи на 50002, а ответы с 50002 летят в случайный интерфейс, то очевидно конфиг неправильный.

да, ответ должен быть на тот-же интерфейс куда прилетел пакет.
Но кто сказал, что пакет прилетел на тот интерфейс на который нужно?
В моём конфиге это вызовет ошибки и проявится в логах.
Если же прописать откуда прилетело, туда и отправлять, то может втихую. начать ходить туда, куда не должно.

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


xvo
Сообщения: 4204
Зарегистрирован: 25 фев 2018, 22:41
Откуда: Москва

Lurker писал(а): 21 июл 2021, 10:09 А что тогда имеется ввиду под "правильный"/"не правильный"?
Если конфиг такой, что NAT настроен принимать пакеты снаружи на 50002, а ответы с 50002 летят в случайный интерфейс, то очевидно конфиг неправильный.
да, ответ должен быть на тот-же интерфейс куда прилетел пакет.
Ну так а конкретно?
Просто это правило как бы и формирует правильный конфиг.
Который будет работать.
Lurker писал(а): 21 июл 2021, 10:09 Но кто сказал, что пакет прилетел на тот интерфейс на который нужно?
Не понимаю. Пакет прилетает на тот интерфейс, на который его отправляет отправитель.
Вы этим процессом управлять не можете.
Если пакет не должен быть принят с этого интерфейса - не принимайте.
Mangle тут ни при чем, это задача firewall'а (ну или если идет "проброс" через NAT - то NAT'а).

Если же пакет был принят, то соединение должно быть помечено соответствующим образом.
Чтобы ответный пакет улетел куда надо.
Lurker писал(а): 21 июл 2021, 10:09 Да, я считаю вариант не работает вообще и сыпет логи лучше, чем работает неправильно. Возможно в этом различие наших взглядов.
Вы как-то странно трактуете мои взгляды, я просто понимаю, как оно работает и изначально делаю так, чтобы оно работало правильно, а не выискиваю где у меня в логах свидетельства того, что что-то не работает.


Telegram: @thexvo
Lurker
Сообщения: 159
Зарегистрирован: 29 апр 2021, 10:45

Конкретно... вот хз как ответить конкретно, если только свой конфиг выложить.

Ну давайте на пальцах.
при моей неправильной настройке (Не подумал о том, что если на 50002 идёт входящий трафик, то с него будет ещё и исходящий) и не отмаркировал трафик с этого порта как трафик торрента. В следствии чего он ушёл не на тот интерфейс, и в логах посыпались ошибки, я их увидел, исправил.

Теперь подумаем что было-бы если бы я добавил правило откуда прилетело, туда и улетело.
Торрент бы прекрасно работал и летал даже через правильный порт. Но в логах никаких ошибок бы небыло. И хз сколько бы я времени разбирался с проблемой почему у меня некорректно работает QoS. А дело было бы в том, что не весь трафик торрента маркируется.


xvo
Сообщения: 4204
Зарегистрирован: 25 фев 2018, 22:41
Откуда: Москва

Lurker писал(а): 21 июл 2021, 11:00 Теперь подумаем что было-бы если бы я добавил правило откуда прилетело, туда и улетело.
Торрент бы прекрасно работал и летал даже через правильный порт. Но в логах никаких ошибок бы небыло. И хз сколько бы я времени разбирался с проблемой почему у меня некорректно работает QoS. А дело было бы в том, что не весь трафик торрента маркируется.
Да просто не было бы никакой проблемы вовсе.
На основном канале этот порт проброшен, на vpn - нет.
Все кто ломится на 50002 на основной IP спокойно бы себе устанавливали соединение и работали через основной канал, а в VPN никаких пакетов с reply-dst-port=50002 никогда бы не попало, а значит и в ответ тоже ничего никогда бы не прилетело.

Ну и вообще сама идея использовать для отлова мелких ошибок другую более глобальную ошибку, кажется мне странной - она сама будет являться причиной большей части этих ошибок (как и получилось в данном конкретном случае).


Telegram: @thexvo
Ответить