Russian Users MikroTik | Форум пользователей MikroTik

Правило которое не отработало
chain=forward action=accept connection-state=!new connection-nat-state=!srcnat,dstnat src-address=!192.168.0.0/16 dst-address=192.168.0.0/16
in-interface=gre1 log=no log-prefix=""

трафик упал до последнего блокирующего правила и отобразился в логах
forward: in:gre1 out:LAN-bridge, proto TCP (ACK), 91.228.155.94:443->192.168.66.2:52079, len 1400

для понимания gre1 это VPN до узла через который тоже можно выйти в интернет. Но инициатором соединения должен быть только клиент из локалки.
флага syn нет, так что по идее это не новое соединение.
реальных проблем замечено небыло.

Я бы смотрел на условие !srcnat,dstnat

Во-первых, точно ли этот трафик не натится.
Во-вторых, хз корректно ли тут отрицание отрабатывается.

1)точно, он натится на другой стороне VPN туннеля.
2)а почему нет? Ну в какую сторону копать. Или как другим способом разрешить трафик только если инициатор с этой стороны туннеля.

Как проверить - продублировать это правило с меньшим кол-вом условий (и если срабатываний не много, все выводить в лог). Понять при добавлении какого именно условия правило перестает срабатывать.
Потом разбираться почему.

Не получится... по этому правилу уже 10 миллионов пакетов набегало. и тут внезапно полтора десятка событий двумя сериями. Правило не отработало. Нет попробовать конечно можно но хз сколько ждать повторения проблемы.

Я как-то подумал, что оно у вас вообще работать отказывается.

Тогда и забить.
Может conn track по какой-то причине убил эти соединения, а эти "хвосты" позже прилетели.

Ещё в логах странную вещь нашёл.
End forward rules forward: in:gre1 out:LAN-bridge, proto UDP, 213.141.131.177:37476->192.168.66.2:50002
50002 это порт для торрента, который через IGD пробрасывается на микротике.
Торренты не должны ходить через gre1
Им выделены исходящие порты 6881-7000
Трафик маркируется
@MikroTik] > ip firewall mangle print
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; Torrent Outgoing
chain=prerouting action=mark-routing new-routing-mark=Torrent passthrough=yes protocol=tcp src-address=192.168.66.0/24 dst-address=!192.168.0.0/16
src-port=6881-7000 log=no log-prefix=""

1 chain=prerouting action=mark-routing new-routing-mark=Torrent passthrough=yes protocol=udp src-address=192.168.66.0/24 dst-address=!192.168.0.0/16
src-port=6881-7000 log=no log-prefix=""

И отправляется в интернет, а не VPN
@MikroTik] > ip route print detail
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit
0 A S ;;; Torrents
dst-address=0.0.0.0/0 pref-src=109.95.219.210 gateway=109.95.219.1 gateway-status=109.95.219.1 reachable via WAN-ether1 distance=10 scope=30
target-scope=10 routing-mark=Torrent
Маршруты через gre1 имеют distance=10
И да, gre1 ходит через этот-же интернет канал т.е. не могло быть такого, что интернет упал, поэтому всё полетело в gre1

Lurker писал(а): ↑16 июл 2021, 08:57 Им выделены исходящие порты 6881-7000

Так то исходящие, а тут входящий.
Может вообще просто port-scanner случайно "попал" в нужный порт.

1)Так а каким образом с той стороны узнают о моём втором IP за VPN?
Они будут ломиться на тот IP с которого я к ним ломлюсь.
2)там за 10 секунд 3 события на 1 порт. Не похоже на порт сканер.
3)Если бы я не ломился через второй IP там NAT бы не отработал.
Хм... а действительно. Это же порт для входящих подключений. Значит одно из 2-х.
а)я хз как но торрент пробросил порт для входящих соединений со второго ip... но оно так не должно работать, в правилах запрещены новые соединения с той стороны. Да и проброса порта не должно быть вроде.
б)торрент использовал порт указанных в настройках для входящих соединений как порт для исходящих соединений... Но это не объясняет 1-й пост. Может это конечно 2 разные проблемы, но я сомневаюсь.

Я вот, если честно, не знаю, что там за механизм, как торрент публикует свои адреса - вполне может какой-то еще порт не из списка использовать, и «засветить» и второй адрес.