FW_RULE_ORDER_LATENCY Сетевое оборудование и VPN

Аудит и оптимизация порядка правил фаервола для снижения задержек

Обновлено: 25.08.2026 · Официальная документация ↗

Резкий рост задержек (Latency/RTT) и снижение пропускной способности при прохождении транзитного трафика.
Высокая утилизация CPU маршрутизатора демонами межсетевого экрана (ksoftirqd / firewall).
Наличие сотен неактивных, устаревших или дублирующих правил фильтрации в таблицах.
Служебные и часто используемые пакеты проверяются в самом конце списка правил (Bottom of chain).

1. Базовый принцип последовательной обработки правил (Top-to-Bottom)

Пакетный фильтр проверяет правила последовательно сверху вниз до первого совпадения (First Match Win). Пакеты установленных сессий составляют 90%+ трафика и обязаны обрабатываться самым первым правилом.

2. Эталонная структура цепочки Forward в MikroTik RouterOS

/ip firewall filter
# 1. ТОП: Прием установленных и связанных сессий (Established/Related) + FastTrack
add chain=forward action=fasttrack-connection connection-state=established,related order=1 comment="1. FastTrack Established"
add chain=forward action=accept connection-state=established,related order=2 comment="2. Accept Established/Related"

# 2. Мгновенный сброс битых пакетов
add chain=forward action=drop connection-state=invalid order=3 comment="3. Drop Invalid"

# 3. Разрешающие правила для самых высоконагруженных сервисов (LAN -> WAN)
add chain=forward action=accept src-address-list=LAN_Subnets out-interface-list=WAN order=4 comment="4. Allow LAN to Internet"

# 4. Точечные правила проброса портов (DMZ/Серверы)
add chain=forward action=accept connection-nat-state=dstnat in-interface-list=WAN order=5 comment="5. Allow Port Forwarding (DST-NAT)"

# 5. ДНО: Запрет всего остального неавторизованного трафика (Default Deny)
add chain=forward action=drop order=6 comment="6. Default Drop All"

3. Использование Address Lists вместо сотен одиночных правил

Вместо создания 100 правил для 100 IP-адресов объединяйте их в один хэш-список (ipset / Address List):

# Неэффективно: 50 отдельных правил add action=accept src-address=10.0.0.X
# Эффективно: одно правило с поиском по бинарному дереву O(1)
/ip firewall filter
add chain=forward action=accept src-address-list=Authorized_Managers dst-address-list=Server_Farm

4. Аудит неиспользуемых правил по счетчикам байт

/ip firewall filter print stats
# Удалите или переместите вниз правила с нулевыми значениями счетчиков (0 packets / 0 bytes)

💡 Практика специалистов: Главная ошибка администраторов — размещение тяжелых правил L7-фильтрации, проверки сигнатур или регулярных выражений в начале общих цепочек. Выносите любой глубокий анализ (DPI/L7) только для пакетов со статусом connection-state=new и строгим ограничением по портам.

Частые вопросы (FAQ)

Почему правило drop connection-state=invalid нужно ставить до проверки новых соединений?

Недействительные пакеты не должны тратить ресурсы CPU на сопоставление с длинными списками портов и IP-адресов. Их сброс в начале цепочки экономит процессорное время.

Как использование подцепочек (Custom Chains / jump) ускоряет фаервол?

Подцепочки позволяют классифицировать трафик по протоколам (например, jump chain=ICMP_RULES при protocol=icmp) и не гонять TCP-пакеты по всем нерелевантным правилам.

В чем разница в скорости между классическим IP rule и ipset в Linux?

Классические правила проверяются линейно O(N), где N — число правил. Список ipset использует хэш-таблицы в ядре и проверяет наличие IP за константное время O(1) независимо от размера списка.

Как часто нужно проводить аудит счетчиков фаервола?

Рекомендуется выполнять аудит счетчиков раз в квартал. Правила с нулевыми счетчиками архивируются и удаляются для предотвращения деградации производительности.