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

[amper]

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

 

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

 

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

 

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

 

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

 

 

[myth]

5. Вторая таблица маршрутизации

[amper]

5. Без мангла? Пример?

[DRiVen]

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

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

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

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

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

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

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

[amper]

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

[Saab95]

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

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

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

[myth]

В 26.03.2018 в 08:40, amper сказал:

Т.е. в первых строках описываем все разрешающие правила forward с типом соединения NEW

ужость...

[Koman]

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

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

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

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

[McSea]

28 minutes ago, Koman said:

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

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

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

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

 

[Koman]

Я его пыnался добавлять и в Firewall rulew и в Raw rule. 

[Koman]

Спасибки McSea

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

[McSea]

6 hours ago, Koman said:

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

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

[Koman]

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

[McSea]

2 hours ago, Koman said:

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

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

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