Размышления на тему nftables
... Время от времени уговариваю себя решать ту или иную задачу не привычным и давно знакомым iptables, а при помощи модного молодежного nftables. От последнего впечатления остаются неоднозначные. С одной стороны, для программистов, автоматизаторов и прочих дево-псов это большое подспорье, поскольку предоставляет неслыханную гибкость. Если хочется построить еще один уровень абстракции поверх nftables, то это прям то что доктор прописал. Но если начинаешь работать с ним напрямую, тут же вылезает куча нелогичностей, которые мой мозг просто отказывается принимать.
Начнем с таблиц. В iptables они несли в себе чёткую смысловую нагрузку: задавали порядок исполнения цепочек - раз, являлись дополнительной "защитой от дурака" - два. В nftables же они по сути только разграничивают правила по уровням модели OSI. При этом, если бы перехватчики (хуки) на разных уровнях назывались бы по-разному (например, "l2-input" и "l3-input", а не просто "input"), то сущность "таблица" стала бы вообще не актуальна. Вот и спрашивается, зачем нужно было плодить эти самые сущности сверх необходимого?
С перехватчиками (hooks) ребята тоже знатно перемудрили и вот почему. Возьмем для примера какую-нибудь хрестоматийную базовую цепочку (base chain) наподобие "chain input { type filter hook input priority filter; }". В этом описании "type filter" относится к сущности "цепочка", "hook input" относится к сущности "перехватчик" (хук), "priority filter" снова относится к сущности "цепочка". При этом слово "filter" в словосочетаниях "type filter" и "priority filter" представляет собой совершенно разные директивы. Голова ещё не начала пухнуть? Дальше больше. Хуки не всякого типа подходят для цепочки того или иного типа. Надо сверяться со специальной таблицей. Бывает, что одну и ту же задачу можно решить внутри цепочек разных типов (например, route и filter), но как тогда понять какой из них применять? А если копнуть чуть глубже, то выяснится, что priority по своему смыслу - это не просто очередность выполнения цепочек по хукам одного и того же типа, а фактически некая точка / местоположение в потоке (flow) логической обработки пакета / кадра внутри ядра, из которой мы его (пакет) изымаем для обработки. То есть если раньше приходилось помнить порядок прохождения пакетов по таблицам и встроенным цепочкам (iptables), то теперь... всё равно приходится держать в голове диаграмму packet flow чтобы уметь задавать хуки с правильными координатами в оном flow (nftables).
И тут возникает некий диссонанс. Чтобы начать обработку пакета, нам нужно поместить в какую-то точку потока (packet flow) перехватчик того или иного типа. Но при этом местоположение того самого перехватчика в потоке определяется не только его собственной характеристикой (типом), но и неким свойством цепочки, в которую он призван вести захват пакетов. "Почему дунул волк, а крышу снесло поросятам?!" ©
Сама идеология всех этих перехватчиков (хуков) тоже весьма неоднозначная. Понятно, что их может быть больше одного, в том числе в самых разных местах того самого потока (packet flow). Так вот если раньше "-j ACCEPT" означало, что обработка пакета в пределах данной таблицы однозначно завершена и ниипёт, то в nftables действие "accept" по своему смыслу аналогично "-j RETURN" в iptables. То есть в современном мире accept может запросто оказаться никаким и не accept вовсе, если где-то ниже по течению packet flow есть ещё какие-то хуки. А теперь помогите Даше пройтись по всему тексту правил (особенно если они развесистые и с кучей include-ов) и найти в них все хуки заданного типа на протяжении всего packet flow. И да, вы ведь не забыли, что нужно искать одновременно по типу хука и по приоритету цепочки? Последний, к слову, может быть задан ключевым словом (псевдонимом), числом или их арифметической комбинацией. А сам порядок описания / появления цепочек в конфигурационном файле не значит вообще ничего...
Отдельная песня - счётчики. В iptables к каждому правилу автоматически прилагался счетчик срабатываний этого правила, который можно было в любой момент посмотреть. В nftables счетчики нужно объявлять явно. Не указал волшебное слово "counter" в описании правила - сам себе злобный баклан.
Но не всё же о плохом. Есть и ложка мёда. Для меня это возможность писать комментарии. Вот это то, чего мне так сильно не хватало в iptables. А всё остальное - какая-то сплошная задница.
Резюмируя. С одной стороны, в nftables беспрецендентно "развязали руки", позволив вытворять всё что угодно и крайне эффективно стрелять себе в ногу. И для M2M управления они, бесспорно, подходят много лучше чем iptables. Но с точки зрения usability и простой человеческой логики это какой-то мрак.
Как всегда, можете со мной спорить.