Jump to content
Калькуляторы

FastTrack и правила Firewall в новых прошивках

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

 

2. Или можно создать несколько разрешающих fasttrack правил, а последним сделать правило запрещающее все? Есть какая-то зависимость от кол-ва правил которые будут "проверены", прежде, чем найдется правило которое пропустит пакет дальше?

 

3. Правила RAW имеет смысл использовать только для борьбы с DOS атаками или тут они тоже могут улучшить производительность?

 

4. Если разрешать все соединения с типом established и related нет ли вероятности что-то пропустить если правилами описывать только new соединения? Например, UDP можно считать established соединением?

 

5. Без использования Mangle и скриптов можно ли реализовать правило маршрутизации, если IP шлюза получен по DHCP? Например задача поднимать резервное соединение через WIFI если основное отвалилось, но при этом фоном надо проверять доступность инета через основное соединение, а для этого нужно смаршрутизировать какой-то хост через это соединение, если указать в качестве шлюза - интерфейс, ничего не работает...

 

 

Share this post


Link to post
Share on other sites

1. Нет, не правильно. Рациональная логика формирования списка фильтров подразумевает создание в начале списка разрешающих правил и замыкающих список запрещающих (как правило более общих).

2. Проверяются все правила с первого до нахождения совпадающего для соединения, безотносительно количества. А зачем создавать несколько fasttrack-правил?

3. Никакого улучшения не получите.

4. established - любое установленное соединение (имеющее запись в Connections), т.е. как правило либо инициированное изнутри, либо описанное правилами трансляции, не путайте с состояниями протоколов.

В 24.03.2018 в 16:41, amper сказал:

поднимать резервное соединение через WIFI если основное отвалилось

То, что вы описали как пример - обычный failover через Netwatch, и никаких маркировок для этого не требуется.

Share this post


Link to post
Share on other sites

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 by amper

Share this post


Link to post
Share on other sites

В 24.03.2018 в 16:41, amper сказал:

5. Без использования Mangle и скриптов можно ли реализовать правило маршрутизации, если IP шлюза получен по DHCP? Например задача поднимать резервное соединение через WIFI если основное отвалилось, но при этом фоном надо проверять доступность инета через основное соединение, а для этого нужно смаршрутизировать какой-то хост через это соединение, если указать в качестве шлюза - интерфейс, ничего не работает...

Самое простое, надежное и без проблемное - это использовать некий микротик с 2-мя и более внешними адресами, до которого все другие микротики, которым требуется резервирование каналов, поднимают туннели. Внутри туннелей через OSPF или простой проверкой пингом мониторится состояние канала.

Share this post


Link to post
Share on other sites

Добрый день. У меня следующая ситуация.

На MicroTik 750GR3 проброшен порт 5060. В BlackList я занёс нежелательные адреса (для примера 37.0.0.0) и добавил правило в RAW для блокировки IP с BlackList.

Но правило блокировки не срабатывает и пользователи с этих IP адресов всё равно пытаются подключиться. 

Что я делаю не так?

Action.png

Advanced.png

general.png

Share this post


Link to post
Share on other sites

28 minutes ago, Koman said:

Что я делаю не так?

Надеюсь вы понимаете что без как минимум остального конфига вопрос не имеет смысла ?

Само-то правило нормальное, но может перед ним все разрешается ?

А адрес подсети (а не хоста) без маски вы в качестве примера специально выбрали или просто до нолика ближе тянуться ?

 

Share this post


Link to post
Share on other sites

Спасибки McSea

Адрес подсети 37.0.0.0 выбран не случайно. Задача стоит заблокировать все зарубежные подключения по портам 5060-5080, а с из подсети 37.0.0.0 попыток больше всего. По этому принял решение блокировать всю подсеть а не определённые IP.

Share this post


Link to post
Share on other sites

6 hours ago, Koman said:

По этому принял решение блокировать всю подсеть

Маску какую указываете для подсети ?

Share this post


Link to post
Share on other sites

2 hours ago, Koman said:

Для подсети указываю маску /24

Т.е. в адресный лист "blacklist" вносите 37.0.0.0/24, я правильно понял ?  

Если так, это дает диапазон блокируемых адресов 37.0.0.0 - 37.0.0.255, может это не совсем то, что нужно ?

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.