Проект Netfilter представил (http://lists.netfilter.org/pipermail/netfilter-announce/2014...) второй выпуск нового пакетного фильтра nftables (0.2), а также соответствующий выпуск вспомогательной библиотеки libnftnl 1.0.1 (http://lists.netfilter.org/pipermail/netfilter-announce/2014...).
В рамках проекта Nftables развивается новая реализация пакетного фильтра, унифицирующая интерфейсы фильтрации пакетов для IPv4, IPv6, ARP и сетевых мостов, и нацеленная на замену iptables, ip6table, arptables и ebtables. Для реализации поставленной задачи Nftables предоставляет на уровне ядра лишь общий интерфейс, не зависящий от конкретного протокола и предоставляющий базовые функции извлечения данных из пакетов, выполнения операций с данными и управления потоком. Непосредственно логика фильтрации и специфичные для протоколов обработчики компилируются в байткод в пространстве пользователя, после чего данный байткод загружается в ядро при помощи интерфейса Netlink и выполняется в специальной виртуальной машине, напоминающей BPF (Berkeley Packet Filters).
Новые возможности, доступные в данной версии:- Поддержка гибридных IPv4/IPv6 таблиц. По умолчанию, правила в такой таблице применяются как к IPv4, так и к IPv6-пакетам. Исключение составляют те правила, для которых протокол указан явно. Пример работы с подобной таблицей (http://git.netfilter.org/nftables/tree/files/nftables/inet-f...):
<font color="#461b7e">
nft inet filter input ip saddr 192.168.0.0/24 jump from_lan
nft inet filter input ip6 saddr 2001::/64 jump from_lan
nft inet filter input tcp dport ssh accept
nft inet filter input iif lo accept</font>- Возможность изменения метаинформации о пакете, в частности, метки (аналог iptables -j MARK), класса шейпера (iptables -j CLASSIFY) и статуса трассировки (iptables -j TRACE). Например,
<font color="#461b7e">
nft filter input mark set 0x1</font>
устанавливает метку пакета в значение 1, а
<font color="#461b7e">
nft filter input mark set mark | 0x1</font>
устанавливает в единицу младший бит метки, не меняя остальные.
Особенный интерес представляет возможность использования меток соединений в словарях (maps), что позволяет, например, в рамках одного правила устанавливать различные метки в зависимости от исходных IP-адресов пакетов:
<font color="#461b7e">
nft filter input mark set ip saddr map {
192.168.0.0/24 : 0x1,
192.168.1.0-192.168.1.64 : 0x2,
192.168.2.1 : 0x3,
* : 0x4
}</font>
Кроме того, метка может быть рассчитана на основании арифметических операций с адресами пакета (аналог неофициального дополнения к iptables IPMARK):
<font color="#461b7e">
nft filter input ip saddr 192.168.0.0/16 mark set ip saddr & 0xff00</font>
- Управление метками соединений (аналог iptables -j CONNMARK). В частности, поддерживается возможность установки метки соединения на основании метки пакета и наоборот, а также прямое задание метки соединения.
- Поддержка именованных меток соединений (аналог iptables -m connlabel).
- Возможность балансировки пакетов, передаваемых на обработку вспомогательным программам, между несколькими очередями, что позволяет более эффективно организовывать работу на системах с большим трафиком (аналог iptables -j NFQUEUE --queue-balance).
- Реализован экспорт набора правил в форматы XML и JSON. Возможность импорта ожидается в следующем выпуске.
- Поддержка комментариев, встроенных непосредственно в правила (аналог iptables -m comment):
<font color="#461b7e">
nft filter input tcp dport ssh accept comment "SSH access"</font>
- При чтении файла с правилами, содержащего ошибки, операция прерывается только после 10 ошибок (а не после первой, как раньше), что значительно ускоряет процесс отладки больших наборов правил.
- Добавлена новая команда create для создания таблиц и цепочек. В отличие от уже имеющейся команды add, create не выдает ошибки, если создаваемый объект уже существует.
- Исправлен ряд ошибок, в частности, улучшена работа с символьными переменными.
- Также внесены некоторые изменения в синтаксис правил:- В некоторых meta-выражениях (mark, iif, iifname, iiftype, oif, oifname, oiftype, skuid, skgid, nftrace, rtclassid) явное указание слова meta теперь необязательно.
- Приведены к единой схеме имена типов данных, используемые в декларации списков (set) и словарей (maps). В частности, типы, связанные с адресами, теперь именуются *_addr, с протоколами — *_proto, с интерфейсами — iface_*. Тип "arphrd" переименован в "iface_type".URL: http://lists.netfilter.org/pipermail/netfilter-announce/2014...
Новость: https://www.opennet.ru/opennews/art.shtml?num=39596
у БЗД подобное есть? (хотя бы в разработке?)
> у БЗД подобное есть? (хотя бы в разработке?)Мапы адрес -> метка считались киллeр-фичей pf (по сути, наиболее существенное преимущество перед iptables). Но пришел nftables и обломал всю малину.
Что касается остальных фич (например, тонка работа с метками), но аналогов в BSD, насколько я знаю, нет.
Как бы модуль IPMARK для iptables уже несколько лет как есть.
iptables v1.4.14: Couldn't load target `IPMARK':/lib/xtables/libipt_IPMARK.so: cannot open shared object file: No such file or directory
>> у БЗД подобное есть? (хотя бы в разработке?)
> Мапы адрес -> метка считались киллeр-фичей pf (по сути, наиболее существенное преимущество
> перед iptables). Но пришел nftables и обломал всю малину.
> Что касается остальных фич (например, тонка работа с метками), но аналогов в
> BSD, насколько я знаю, нет.мне может кто-нибудь подсказать хоть один практический пример нафига подобное нужно?
> мне может кто-нибудь подсказать хоть один практический пример нафига подобное нужно?Практический пример - мапы dst addr/port -> dnat addr/port, или src addr/port -> snat addr/port. Не совсем addr -> mark, но тоже киллeр-фича pf tables. Была.
>> мне может кто-нибудь подсказать хоть один практический пример нафига подобное нужно?
> Практический пример - мапы dst addr/port -> dnat addr/port, или src addr/port
> -> snat addr/port. Не совсем addr -> mark, но тоже киллeр-фича
> pf tables. Была.это типа с диапазона серых ip на диапазон белых?
дык это давно можно через -j NATMAP
какие ещк были киллер фичи?
PF и IPFW хватает всем нормальным людям
кому не хватает, для тех есть netgraph )
> кому не хватает, для тех есть netgraph )Вы сравниваете немного разные вещи.
netgraf слишком общая и универсальная вещь, и требует серьезного напилинга под конкретные задачи.
>PF и IPFW хватает всем нормальным людямА 640 кбайт всем хватает?
> А 640 кбайт всем хватает?Если очень хочется - то да.
> Реализован экспорт набора правил в форматы XML и JSON. Возможность импорта
> ожидается в следующем выпуске.#include <trollface.h> однако :)
Всё правильно. Можно ещё добавить в/из: YAML, CSV, SQLite.
> Всё правильно. Можно ещё добавить в/из: YAML, CSV, SQLite.И плагин для связи с systemd через kdbus.
> Всё правильно. Можно ещё добавить в/из: YAML, CSV, SQLite.Да, слушай, надо какой-нибудь самопальный упаковщик написать, пожалуй. Чтобы паковал ваши ценные данные. А как распаковывать - я потом подумаю. В следующей версии. Заодно будет стимул донейтить на новую версию [пример Тео больно уж заразителен]. :)
>> Всё правильно. Можно ещё добавить в/из: YAML, CSV, SQLite.
> Да, слушай, надо какой-нибудь самопальный упаковщик написать, пожалуй. Чтобы паковал ваши
> ценные данные. А как распаковывать - я потом подумаю.В данном случае - наоборот (есть только преобразователь из специфичного блоба в общепринятые текстовые форматы, то есть распаковщик).
Изменений овер9000 ... практически только дока, мля0944e15..daf4958 master -> origin/master
* [new branch] trans -> origin/trans
* [new tag] v0.2 -> v0.2
Updating 0944e15..daf4958
Fast-forward
Makefile.defs.in | 1 +
Makefile.rules.in | 4 +-
configure.ac | 28 ++--
doc/.gitignore | 4 +-
doc/Makefile.in | 4 +-
doc/nft.xml | 2168 +++ ...
doc/nftables.xml | 966 --- ...
include/gmputil.h | 9 ++
include/utils.h | 16 +-
src/datatype.c | 12 +-
src/gmputil.c | 7 +-
src/meta.c | 8 +-
src/netlink.c | 2 +-
src/parser.y | 7 +
src/payload.c | 3 +-
src/proto.c | 4 +-
src/rule.c | 2 +-
17 files changed, 2246 insertions(+), 999 deletions(-)
create mode 100644 doc/nft.xml
delete mode 100644 doc/nftables.xml
Выражать многое в нескольких словах - признак мастерства.
>Поддержка гибридных IPv4/IPv6 таблицОтлично.
Очень надеюсь, что добавят поддержку ipset. Он очень хорошо оптимизирован под гигантские списки адресов/подсетей/портов, и вряд ли более универсальный аналог из nftables будет работать быстрее.
Ты прибалт что-ли? Он ещё в прошлом релизе работал быстрее ipset.
> Ты прибалт что-ли? Он ещё в прошлом релизе работал быстрее ipset.Пруфы будут? Нужны нормальные бенчмарки типа такого http://daemonkeeper.net/781/mass-blocking-ip-addresses-with-.../
какой уродливый синтаксис у этого nft, iptables был намного проще.
Воистину так. В принципе, все понимаю про преимущества nftables, но его освоение по большей тормозит именно дико уродливый синтаксис правил nft...
> Воистину так. В принципе, все понимаю про преимущества nftables, но его освоение
> по большей тормозит именно дико уродливый синтаксис правил nft...И это пройдёт. Освоение iptables то же самое тормозит, пока не прочитаешь [и поймёшь!] достаточно решений реальных проблем. И для этого всё будет.
>И это пройдёт. Освоение iptables то же самое тормозит, пока не прочитаешь [и поймёшь!]
>достаточно решений реальных проблем. И для этого всё будет.В принципе да, iptables в свое время тоже осваивал на практике, может когда дойдет дело до практики, то будет проще во всем разобраться..
Но в синтаксисе iptables имхо есть системность, там можно мысленно разобрать правило на куски и понять что за что отвечает... А здесь синтаксис nft мне лично напоминает хаотично и безсистемно понаписанные наборы слов, которые якобы должны что-то означать..
Читаю wiki-справку проекта. Вроде бы как даже удобней iptables, там даже примеры есть, как описать одно и то же правило в ipt и nft. Другое дело, что сама вики пока довольно скудная.
> А здесь синтаксис nft мне лично напоминает хаотично и безсистемно понаписанные наборы слов, которые якобы должны что-то означать..Когда не знаешь значения большинства слов, это естественно. И с iptables сначала так, если не хуже.
Учитесь, читайте документацию.
iptables привычнее, но не проще. Особенно учитывая, что *tables слишком много.
> iptables привычнее, но не проще. Особенно учитывая, что *tables слишком много.Самое веселое, что arptables и ebtables по архитектуре отличаются от iptables и ip6tables. Изначально код был один и тот же (размноженный методом копипасты), но потом дороги начали расходиться.
Например, в arptables и ebtables есть target extensions, а в ebtables - еще и watch extensions. Но при этом в arptables нет match extensions.
В то время как в ip(6)tables есть только match extensions (хотя некоторые из них, по факту, выполняют модифицирующие действия - например, -m recent --set/--update).
>> iptables привычнее, но не проще. Особенно учитывая, что *tables слишком много.
> Самое веселое, что arptables и ebtables по архитектуре отличаются от iptables и
> ip6tables. Изначально код был один и тот же (размноженный методом копипасты),
> но потом дороги начали расходиться.
> Например, в arptables и ebtables есть target extensions, а в ebtables -
> еще и watch extensions.точно watch? где такие?
> Но при этом в arptables нет match
> extensions.что как-бы логично т.к. это фильтр для одного протокола и мачить там нечего
> В то время как в ip(6)tables есть только match extensions (хотя некоторые
> из них, по факту, выполняют модифицирующие действия - например, -m recent
> --set/--update).recent не изменяет сам пакет и в этом смысле ничем не отличим от того-же MARK
бред о том что в ip6tables есть только match и отсутствуют target откуда взялси?
> точно watch? где такие?Watcher. В ebtables. log, nflog, ulog.
> что как-бы логично т.к. это фильтр для одного протокола и мачить там нечего
Была бы расширяемая архитектура - глядишь, поддерживал бы и больше протоколов.
> recent не изменяет сам пакет и в этом смысле ничем не отличим от того-же MARK
MARK - это target.
> бред о том что в ip6tables есть только match и отсутствуют target откуда взялси?
Там есть только target, но нет target extensions (нельзя применить больше одной операции к пакету в одном правиле). В ebtables за одно правило можно, например, поставить метку, подменить адрес и пропустить пакет.
>> точно watch? где такие?
> Watcher. В ebtables. log, nflog, ulog.посмотрел man -- и действительно в мане подобное понятие вводиться -- хотя лично для меня это искуственное деление.
>> что как-бы логично т.к. это фильтр для одного протокола и мачить там нечего
> Была бы расширяемая архитектура - глядишь, поддерживал бы и больше протоколов.мы точно говорим о arptables? потому-что напрмую отталкиваясь от названия это таблицы протокола ARP -- появились же они т.к. это и не l2 и не l3 -- а именно то, что объеденяет эти два слоя в рамках ethernet. никакая расширяемая архитекрура тут ни при чём.
>> recent не изменяет сам пакет и в этом смысле ничем не отличим от того-же MARK
> MARK - это target.
>> бред о том что в ip6tables есть только match и отсутствуют target откуда взялси?
> Там есть только target, но нет target extensions (нельзя применить больше одной
> операции к пакету в одном правиле). В ebtables за одно правило
> можно, например, поставить метку, подменить адрес и пропустить пакет.ой....
да -- ebtables во много отход от традиции, и шаг назад. статическая линковка расширений чего только стоит. соответственно ввод нескольких действий выглядит каким-то странным костылём, хотя нет никакой (окромя политики партии) написать match extension для ip(6)tables которое будет производить действия по модификации пакета/meta, я считаю что чёткое определение ролей match/target в iptables существует совершенно оправданно.
> посмотрел man -- и действительно в мане подобное понятие вводиться -- хотя лично для меня это искуственное деление.Деление чего и на что?
По-моему, это в ip(6)tables весьма глупый ход - выполнять логгирование в виде target.> мы точно говорим о arptables? потому-что напрмую отталкиваясь от названия это таблицы протокола ARP -- появились же они т.к. это и не l2 и не l3 -- а именно то, что объеденяет эти два слоя в рамках ethernet. никакая расширяемая архитекрура тут ни при чём.
ARP - это придаток IPv4 и, по здравому размышлению, заниматься им нужно в iptables.
В IPv6 с этим проще - четко прописано, что обслуживание сетевого протокола выполняется при помощи его внутренней подсистемы (ICMPv6).> да -- ebtables во много отход от традиции, и шаг назад.
По удобству - шаг вперед, это однозначно.
> нет никакой (окромя политики партии) написать match extension для ip(6)tables которое будет производить действия по модификации пакета/meta, я считаю что чёткое определение ролей match/target в iptables существует совершенно оправданно.
По факту, на него уже забили. См. тот же пример recent, или -m connlabel --set (если насчет метаданности recent можно поспорить, то с connlabel никаких вопросов нет).
>> посмотрел man -- и действительно в мане подобное понятие вводиться -- хотя лично для меня это искуственное деление.
> Деление чего и на что?
> По-моему, это в ip(6)tables весьма глупый ход - выполнять логгирование в виде
> target.деление на watch и target
>> мы точно говорим о arptables? потому-что напрмую отталкиваясь от названия это таблицы протокола ARP -- появились же они т.к. это и не l2 и не l3 -- а именно то, что объеденяет эти два слоя в рамках ethernet. никакая расширяемая архитекрура тут ни при чём.
> ARP - это придаток IPv4 и, по здравому размышлению, заниматься им нужно
> в iptables.сам ты придаток, напомни себе определение и перестань фантазировать, ARP никоим образом к ipv4 отношения не имеет, потому как ipv4 это l3 а arp это l2+
> В IPv6 с этим проще - четко прописано, что обслуживание сетевого протокола
> выполняется при помощи его внутренней подсистемы (ICMPv6).
>> да -- ebtables во много отход от традиции, и шаг назад.
> По удобству - шаг вперед, это однозначно.удобство крайне относительная вещь, сугубо индивидуальная.
>> нет никакой (окромя политики партии) написать match extension для ip(6)tables которое будет производить действия по модификации пакета/meta, я считаю что чёткое определение ролей match/target в iptables существует совершенно оправданно.
> По факту, на него уже забили. См. тот же пример recent, или
> -m connlabel --set (если насчет метаданности recent можно поспорить, то с
> connlabel никаких вопросов нет).connlabel меняет пакет? жду от вас новых увлекательных историй!
>При чтении файла с правилами, содержащего ошибки, операция прерывается только после 10 ошибок (а не после первой, как раньше), что значительно ускоряет процесс отладки больших наборов правил.Ай да молодцы!
закос на ipfw и json
технически - скорее обеспечивается возможность сделать "закос"(и взаимодействие) подо что угодно, помимо перечисленного.