amper Posted March 24, 2018 · Report post 1. Подскажите, правильно ли я понимаю, что для того, чтобы получить быструю обработку пакетов на новых прошивках надо переделать правила брандмауэра таким образом, чтобы были запрещающие правила, а не разрешающие? Т.е. в первых строках надо описать все вариации того, что запрещено, а ниже правило fasttrack куда должно попасть все остальное, что не было отброшено первыми правилами? Правила простые, как правила описывается адрес лист и интерфейс, либо другой адрес лист, иногда указывается порт. 2. Или можно создать несколько разрешающих fasttrack правил, а последним сделать правило запрещающее все? Есть какая-то зависимость от кол-ва правил которые будут "проверены", прежде, чем найдется правило которое пропустит пакет дальше? 3. Правила RAW имеет смысл использовать только для борьбы с DOS атаками или тут они тоже могут улучшить производительность? 4. Если разрешать все соединения с типом established и related нет ли вероятности что-то пропустить если правилами описывать только new соединения? Например, UDP можно считать established соединением? 5. Без использования Mangle и скриптов можно ли реализовать правило маршрутизации, если IP шлюза получен по DHCP? Например задача поднимать резервное соединение через WIFI если основное отвалилось, но при этом фоном надо проверять доступность инета через основное соединение, а для этого нужно смаршрутизировать какой-то хост через это соединение, если указать в качестве шлюза - интерфейс, ничего не работает... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
myth Posted March 24, 2018 · Report post 5. Вторая таблица маршрутизации Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
amper Posted March 24, 2018 · Report post 5. Без мангла? Пример? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
DRiVen Posted March 25, 2018 · Report post 1. Нет, не правильно. Рациональная логика формирования списка фильтров подразумевает создание в начале списка разрешающих правил и замыкающих список запрещающих (как правило более общих). 2. Проверяются все правила с первого до нахождения совпадающего для соединения, безотносительно количества. А зачем создавать несколько fasttrack-правил? 3. Никакого улучшения не получите. 4. established - любое установленное соединение (имеющее запись в Connections), т.е. как правило либо инициированное изнутри, либо описанное правилами трансляции, не путайте с состояниями протоколов. В 24.03.2018 в 16:41, amper сказал: поднимать резервное соединение через WIFI если основное отвалилось То, что вы описали как пример - обычный failover через Netwatch, и никаких маркировок для этого не требуется. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
amper Posted March 26, 2018 (edited) · Report post 2. Т.е. в первых строках описываем все разрешающие правила forward с типом соединения NEW; после этого ставим одно правило fasttrack с типом established,related; и в самом конце drop? Или все таки fasttrack надо поднять как можно выше, по идее в него не попадут новые соединения? А related как определяются, не очень понял из описания, там фигурирует пример с ftp. 5. Все равно нужен скрипт на dhcp клиенте, который будет прописывать шлюз до хостов и обновлять его, да и потом netwatch не самый адекватный инструмент в плане мониторинга (т.к. для принятия решения у него только 1 попытка), решил проблему таким скриптом: :global ETHER1GW :if ($ETHER1GW="Up") do={\ :if ([/ping routing-table=onlime-gw 77.88.8.8 count=5]<1 && [/ping routing-table=onlime-gw 8.8.8.8 count=5]<1) do={\ :log warning ("ETHER1GW DOWN"); :global ETHER1GW "Down"; /interface wireless set wlan2-4g disabled=no /ip dhcp-client set disabled=no [find comment="wlan2-4g"]; :for i from=1000 to=40 step=-20 do={ :beep frequency=$i length=11ms; :delay 11ms; } } } else { :if ($ETHER1GW="Down") do={\ :if ([/ping routing-table=onlime-gw 77.88.8.8 count=5]>=2 || [/ping routing-table=onlime-gw 8.8.8.8 count=5]>=2) do={\ :log warning ("ETHER1GW UP"); :global ETHER1GW "Up"; /ip dhcp-client set disabled=yes [find comment="wlan2-4g"]; /interface wireless set wlan2-4g disabled=yes /ip firewall connection {:foreach r in=[find] do={remove $r}}; } } } Edited March 26, 2018 by amper Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Saab95 Posted March 26, 2018 · Report post В 24.03.2018 в 16:41, amper сказал: 5. Без использования Mangle и скриптов можно ли реализовать правило маршрутизации, если IP шлюза получен по DHCP? Например задача поднимать резервное соединение через WIFI если основное отвалилось, но при этом фоном надо проверять доступность инета через основное соединение, а для этого нужно смаршрутизировать какой-то хост через это соединение, если указать в качестве шлюза - интерфейс, ничего не работает... Самое простое, надежное и без проблемное - это использовать некий микротик с 2-мя и более внешними адресами, до которого все другие микротики, которым требуется резервирование каналов, поднимают туннели. Внутри туннелей через OSPF или простой проверкой пингом мониторится состояние канала. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
myth Posted March 28, 2018 · Report post В 26.03.2018 в 08:40, amper сказал: Т.е. в первых строках описываем все разрешающие правила forward с типом соединения NEW ужость... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Koman Posted January 25, 2019 · Report post Добрый день. У меня следующая ситуация. На MicroTik 750GR3 проброшен порт 5060. В BlackList я занёс нежелательные адреса (для примера 37.0.0.0) и добавил правило в RAW для блокировки IP с BlackList. Но правило блокировки не срабатывает и пользователи с этих IP адресов всё равно пытаются подключиться. Что я делаю не так? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
McSea Posted January 25, 2019 · Report post 28 minutes ago, Koman said: Что я делаю не так? Надеюсь вы понимаете что без как минимум остального конфига вопрос не имеет смысла ? Само-то правило нормальное, но может перед ним все разрешается ? А адрес подсети (а не хоста) без маски вы в качестве примера специально выбрали или просто до нолика ближе тянуться ? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Koman Posted January 28, 2019 · Report post Я его пыnался добавлять и в Firewall rulew и в Raw rule. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Koman Posted January 28, 2019 · Report post Спасибки McSea Адрес подсети 37.0.0.0 выбран не случайно. Задача стоит заблокировать все зарубежные подключения по портам 5060-5080, а с из подсети 37.0.0.0 попыток больше всего. По этому принял решение блокировать всю подсеть а не определённые IP. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
McSea Posted January 28, 2019 · Report post 6 hours ago, Koman said: По этому принял решение блокировать всю подсеть Маску какую указываете для подсети ? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Koman Posted January 29, 2019 · Report post Для подсети указываю маску /24 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
McSea Posted January 29, 2019 · Report post 2 hours ago, Koman said: Для подсети указываю маску /24 Т.е. в адресный лист "blacklist" вносите 37.0.0.0/24, я правильно понял ? Если так, это дает диапазон блокируемых адресов 37.0.0.0 - 37.0.0.255, может это не совсем то, что нужно ? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...