Как разорвать соединение с определенным адресом : MikroTik

OlegON · █ 28.01.2021 19:32

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

Код:

/ip firewall connection { remove [find dst-address="1.1.1.1:111"] }
/ip firewall connection remove [find src-address~"^192.168.10.20:"]

Stels · █ 24.01.2023 10:05

А можно в условии использовать Address Lists ?

Буду благодарен за пример...
(Сам пока ищу)

OlegON · █ 24.01.2023 14:34

зачем? в любом случае это будет цикл и тормоза...

Stels · █ 24.01.2023 15:31

Цитата:

OlegON ➤ зачем? в любом случае это будет цикл и тормоза...

))
Ну вот мне нужно включать иногда правило NAT, которое будет подменять внешний адрес на другой внешний..
Но при включении правила, пока не убьёшь сессию, подключение так и будет висеть на старый адрес

Вот наваял на коленке рабочий вариант ..
За скорость работы и загрузку проца микротика не скажу..
Сразу скажу, что в списке конкретные IP .. не диапазоны
мне этого оказалось достаточно

Код:

:local lst001 "ИмяСписка"; :foreach i in=[/ip firewall address-list find list=$lst001] do={
    :local ipaddress [/ip firewall address-list get $i address]
     /ip firewall connection remove [ find where src-address~"^$ipaddress:" protocol~"tcp"]
}

OlegON · █ 24.01.2023 15:35

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

Stels · █ 24.01.2023 15:47

Ну у меня в этом списке <10шт адресов ..и запускать скрипт надо не часто
и аппарат RB4011iGS+ четырёх ядерный..
Думаю, справится
Остальные работают - их трогать нельзя..

OlegON · █ 24.01.2023 19:15

Тут дело не в том, сколько у тебя в списке (если мало), а в том, сколько у тебя вообще соединений, поскольку проверяться будут все.
На самом деле некорректно я назвал тему, поскольку исчезновение соединения из таблички conntrack не обозначает обрыв соединения для сервера или клиента. Они вообще не будут в курсе этих очисток. Вот льется поток пакетиков от одного к другому, как только первый пошел (грубо говоря) - соединение попадает в NEW, отрабатывают правила для нового соединения, и запись в conntrack рутера, после чего оно становится ESTABLISHED. Само состояние соединения не в рутере хранится, а на сторонах. Если ты из conntrack этими скриптами соединение выкинул, то первый же пакет поднимет соединение в NEW с отработкой всех существующих (и появившихся) правил. Если ты ничего не запрещал для этого соединения, то для сторон соединения ничего не изменится. Большинство правил цепочек строятся на том, что ESTABLISHED уже не проверяются, чтобы зря не греть процессор. А скриптом ты "разрываешь" соединение для рутера. У меня еще для облегчения жизни рутеру сильно снижены интервалы неактивности сессий. Я писал уже, что, на мой взгляд, сильно завышены эти интервалы для обычных сетей, тем более - локалок.
Немного сумбурно, но я не лектор, а тему сложно уложить в несколько предложений.