Действие JUMP и собственные цепочки в iptables и брандмауэре Mikrotik
Про то, как пакеты бегают по цепочкам брандмауэра, мы рассказывать не будем, это все знают, а если не знают, то перед тем, как читать эту заметку им следует ознакомиться с базовыми принципами работы iptables.
Сегодня мы поговорим о другом, а именно об оптимизации правил брандмауэра и снижении нагрузки. Особенно это актуально для недорогих роутеров, таких как Mikrotik, но не будет лишним и на любых других системах.
Как мы помним любой пакет попадая в цепочку iptables (а в Mikrotik тот же самый iptables) начинает движение по правилам последовательно, до первого совпадения критериев. Затем, если правило терминальное, он прекращает движение по цепочке и переходит в следующую.
А теперь представьте, что у вас в цепочке несколько десятков правил и пакет попадает под критерии условно 30-го. Перед этим он впустую пройдет предыдущие 29 попадая под все проверки и вызывая дополнительную нагрузку.
И чем больше у вас в цепочке правил, тем более высокой будет нагрузка, особенно если в правилах есть «дорогие» критерии.
Можно, конечно, оптимизировать расположение правил, чтобы дорогие проверки стояли после дешевых, но не всегда это возможно, а также не решает задачи холостого срабатывания цепочек.
И вот здесь нам на помощь придут цепочки собственные и действие JUMP, которое поможет нам перейти в эти цепочки.
А дальше довольно просто, прежде всего определяем группы правил, которые можно объединить по какому-либо общему критерию и выносим их в отдельную цепочку, а в основной цепочке делаем JUMP по срабатыванию на этот общий критерий.
Например, если из 30 правил мы выделим 5 групп по 5 правил, то у нас в основной цепочке их останется только 10 и пять из них будут гораздо более простыми. Таким образом пакет пройдет брандмауэр гораздо быстрее и с меньшей нагрузкой на оборудование.
После чего следует аналогичным образом вынести и тяжелые правила, разделив их на проверку по простым критериям, на основании которой будет переход в отдельную цепочку, где уже будем дополнительно проводить «дорогие» проверки.
С одной стороны, у нас вместо одного правила получается два, но по факту мы оказываемся в выигрыше, так как большая часть пакетов будет проходить проверку только по «дешевым» критериям, не вызывая проверку «дорогих».
Также имеет смысл выносить в отдельные цепочки логические группы правил, объединенные общим назначением, что не только уменьшит нагрузку, но и позволит более легко читать сложные конфигурации брандмауэра.
Количество пользовательских цепочек не ограничено, и работа с ними ничем не отличается от стандартных, при срабатывании правила пакет прекращает движение по цепочке и возвращается к месту вызова. Туда же он вернется если не сработало ни одно правило.
Вызывать собственную цепочку можно из любого места, даже из другой собственной цепочки. Это позволяет также упростить конфигурацию брандмауэра за счет повторного использования наборов правил для разных цепочек.
Практические примеры использования собственных цепочек и JUMP мы рассмотрим в следующей заметке.
