RB750GL загрузка ЦП Firewall-ом

[TuoH]

Доброго времени суток!
После добавления правил Firewall-а появилась проблема с временным проседанием производительности устройства. Но обо всем по порядку..
Имеется железка MikroTik RB750GL, из 5 портов используются 2:
1. аплинк до оператора, без всякой инкапсуляции, банально IPoE;
2. линк в сторону свичей, тут собраны VLAN-ы от пользователей локалки, всего 6 VLAN-ов.
Пять из них живут в Бридже, а один отдельно.
Так сложилось, что пользователи в 5 VLAN-ах, которые в Бридже, имеют адреса из одной подсети(фактически это бывшая 1 сеть, разбитая на группы), хотя это есть криво, поменять адресацию в обозримом будущем не представляется возможным.
Целью было настроить правила Firewall-а для запрета хождения всего трафика между VLAN-ами, кроме разрешенного(скажем доступ отдельных ПК на бухгалтерский сервер).

Но началось все с настройки фильтров на доступ к соц.сетям..
Имеем правила фильтрации 9шт:
6 для NAT-а(стандартные),
3 правила на открытие портов(вход. VPN, ssh)
Экспресс-тест - копируем файлы через сеть между разными vlan-ами:
на интерфейсе скорость около 180Мбит и около 22000pps(в обе стороны в сумме), загрузка ЦП около 30-40%.
Т.к много и долго копировать через сеть не предполагается - нормально, устраивает.

Добовляем 4 правила для фильтра сой.сетей вида:
/ip firewall filter add chain=forward protocol=tcp src-address=172.16.0.0/24 content="vk.com" action=reject reject-with=tcp-reset
Экспресс-тест - копируем файлы через сеть между разными vlan-ами:
на интерфейсе скорость около 40Мбит и примерно 4000pps, загрузка ЦП 90-100%(преимущественно Firewall-ом), жуткие тупняки и прочие радости..

Боюсь предположить что будет если навесить еще правил на внутреннюю фильтрацию..

Вопрос №1 - почему загрузка ЦП так подскакивает? Или я слишком много хочу от железки и надо ставить что-то другое?
Вопрос №2 - при хождении трафика между vlan-ами, в списке интерфейсов бОльшая часть трафика(скорость, пакеты) отображается напротив соответствующего vlan-а. Как мне кажется, ВЕСЬ трафик(в сумме), идущий через бридж, должен отображаться в строке с бриджом, а там отображается копеечное(~5% от трафика) кол-во пакетов.

[vqd]

на 750-м в вашей конфигурации жестоко применять фильтрацию по контексту. У меня дома такой стоит, все страдаю от нехватки памяти, а если уж подниму хотя бы половину тоннелей + OSPF до удаленных точек то микротик просто помирает. Надо бы все 951 приобрести.

[simpl3x]

1). слишком много хотите. т.к. по сути, микротик просматривает содержимое пакетов от 172.16.0.0/24 на наличие строки vk.com. задача ресурсоёмкая. было время когда хотел повесить задачу фильтрации по 149 ФЗ на более производительную железку. после 5 правил передумал. вам советую как то более конкретно задать правило. или использовать прокси. но все равно для 750 железки это слишком много.

[TuoH]

советую как то более конкретно задать правило. или использовать прокси.

По IP не имеет смысла блокировать. Разве еще как-то можно настроить?

или использовать прокси

Это нужно дополнительно какое-то устройство припрягать..

для 750 железки это слишком много.

Какой железки хватит? Или смотреть в сторону x86?

[vqd]

Микротик это роутер, для фильтрации трафика другие системы применяются ))

Вы же шуруп молотком не забиваете не смотря на то что есть такая возможность? ))

[TuoH]

Микротик это роутер

А как тогда быть если нужен роутинг с фильтрацией?

для фильтрации трафика другие системы применяются ))

Другие - какие?
Внутресетевой трафик все равно чем-то фильтровать придется.

[vqd]

ну фильтруйте, я про фильтры по контенту

[TuoH]

как то более конкретно задать правило

simpl3x, спасибо
натолкнуло на мысль фильтровать не весь трафик, а только тот, что идет на порты 80 и 443.

4 правила, при копировании через сеть загрузка ЦП до 40-70%, трафик внутри сети такой же как и без фильтров. Никакой разницы для пользователя, кроме повышения пинга на 1-4мс.
Завтра все выйдут на работу, под нагрузкой попробуем..

[simpl3x]

443.

можете его тоже убрать, оставить только 80. https бесполезно обрабатывать в прокси и по контенту, это как бы шифрованное соединение, в открытом виде там не передаётся домен.

Это нужно дополнительно какое-то устройство припрягать..

в микротике есть прокси, можете использовать его.

Другие - какие?

заточенные под это. попробуйте поискать по слову DPI (Deep Packet Inspection). Ценник вас удивит =) но для общего развития будет интересно. а так, вообще да, нужно как минимум старшие модели брать под это дело. уж больно мало ресурсов у 750 модели. или ставить несколько младших, и трафик для анализа маршрутизировать на отдельную.

[TuoH]

можете его тоже убрать, оставить только 80. https бесполезно обрабатывать в прокси и по контенту, это как бы шифрованное соединение, в открытом виде там не передаётся домен.

https://www.facebook.com/ замечательно блокирует. Правда некоторый трафик сразу после попытки отправки запроса есть, но страница не открывается - результат достигнут. Без 443 порта - открывает страницу.

в микротике есть прокси, можете использовать его.

по идее он будет делать тоже самое:
трафик dst-port=80 будет бегать на прокси, там будет пропущен через правила. Т.е. опять же будет просмотрено содержимое пакетов с соответствующей нагрузкой, к тому же еще и весь web трафик сети будет бегать через этот же прокси, создавая дополнительную нагрузку.
Или нет?

заточенные под это. попробуйте поискать по слову DPI (Deep Packet Inspection). Ценник вас удивит =)

Ну у нас же на масштабная сеть на 100500 машин ;) Всего лишь 60 пользователей, из которых про то, что такое интернет, знают хорошо если 30..
Для 5 правил фильтрации и трафика до 100Мбит по идее должны быть железки за разумную цену, до 20килорублей.
К тому же трафик, уходящий наружу, скорее всего можно отделить от внутреннего трафика, который не нужно фильтровать. Получается фильтровать нужно будет вообще до 20Мбит(тариф ISP-а).

нужно как минимум старшие модели брать под это дело

Имелось ввиду например RB1200? Или что-то выше, из CCR?