The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Второй выпуск пакетного фильтра nftables

17.04.2014 23:30

Проект Netfilter представил второй выпуск нового пакетного фильтра nftables (0.2), а также соответствующий выпуск вспомогательной библиотеки libnftnl 1.0.1.

В рамках проекта Nftables развивается новая реализация пакетного фильтра, унифицирующая интерфейсы фильтрации пакетов для IPv4, IPv6, ARP и сетевых мостов, и нацеленная на замену iptables, ip6table, arptables и ebtables. Для реализации поставленной задачи Nftables предоставляет на уровне ядра лишь общий интерфейс, не зависящий от конкретного протокола и предоставляющий базовые функции извлечения данных из пакетов, выполнения операций с данными и управления потоком. Непосредственно логика фильтрации и специфичные для протоколов обработчики компилируются в байткод в пространстве пользователя, после чего данный байткод загружается в ядро при помощи интерфейса Netlink и выполняется в специальной виртуальной машине, напоминающей BPF (Berkeley Packet Filters).

Новые возможности, доступные в данной версии:

  • Поддержка гибридных IPv4/IPv6 таблиц. По умолчанию, правила в такой таблице применяются как к IPv4, так и к IPv6-пакетам. Исключение составляют те правила, для которых протокол указан явно. Пример работы с подобной таблицей:
    
        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
    
  • Возможность изменения метаинформации о пакете, в частности, метки (аналог iptables -j MARK), класса шейпера (iptables -j CLASSIFY) и статуса трассировки (iptables -j TRACE). Например,
    
        nft filter input mark set 0x1
    

    устанавливает метку пакета в значение 1, а

    
        nft filter input mark set mark | 0x1
    

    устанавливает в единицу младший бит метки, не меняя остальные.

    Особенный интерес представляет возможность использования меток соединений в словарях (maps), что позволяет, например, в рамках одного правила устанавливать различные метки в зависимости от исходных IP-адресов пакетов:

    
        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
        }
    

    Кроме того, метка может быть рассчитана на основании арифметических операций с адресами пакета (аналог неофициального дополнения к iptables IPMARK):

    
        nft filter input ip saddr 192.168.0.0/16 mark set ip saddr & 0xff00
    
  • Управление метками соединений (аналог iptables -j CONNMARK). В частности, поддерживается возможность установки метки соединения на основании метки пакета и наоборот, а также прямое задание метки соединения.
  • Поддержка именованных меток соединений (аналог iptables -m connlabel).
  • Возможность балансировки пакетов, передаваемых на обработку вспомогательным программам, между несколькими очередями, что позволяет более эффективно организовывать работу на системах с большим трафиком (аналог iptables -j NFQUEUE --queue-balance).
  • Реализован экспорт набора правил в форматы XML и JSON. Возможность импорта ожидается в следующем выпуске.
  • Поддержка комментариев, встроенных непосредственно в правила (аналог iptables -m comment):
    
        nft filter input tcp dport ssh accept comment "SSH access"
    
  • При чтении файла с правилами, содержащего ошибки, операция прерывается только после 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".


  1. Главная ссылка к новости (http://lists.netfilter.org/pip...)
  2. OpenNews: Первый пригодный для пользователей релиз пакетного фильтра Nftables
  3. OpenNews: Релиз ядра Linux 3.13. Обзор новшеств
  4. OpenNews: В ядре Linux 3.13 ожидается появление нового пакетного фильтра Nftables
  5. OpenNews: Разработчики Netfilter представили замену iptables
Автор новости: Аноним
Тип: Программы
Ключевые слова: nftables, iptables, netfilter
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (40) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Пропатентный тролль (?), 00:37, 18/04/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    у БЗД подобное есть? (хотя бы в разработке?)
     
     
  • 2.8, Аноним (-), 02:05, 18/04/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > у БЗД подобное есть? (хотя бы в разработке?)

    Мапы адрес -> метка считались киллeр-фичей pf (по сути, наиболее существенное преимущество перед iptables). Но пришел nftables и обломал всю малину.

    Что касается остальных фич (например, тонка работа с метками), но аналогов в BSD, насколько я знаю, нет.

     
     
  • 3.18, mickvav (?), 10:18, 18/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Как бы модуль IPMARK для iptables уже несколько лет как есть.
     
     
  • 4.23, Аноним (-), 13:25, 18/04/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    iptables v1.4.14: Couldn't load target 'IPMARK':/lib/xtables/libipt_IPMARK.so: cannot open shared object file: No such file or directory
     
  • 3.25, pavel_simple (ok), 13:27, 18/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> у БЗД подобное есть? (хотя бы в разработке?)
    > Мапы адрес -> метка считались киллeр-фичей pf (по сути, наиболее существенное преимущество
    > перед iptables). Но пришел nftables и обломал всю малину.
    > Что касается остальных фич (например, тонка работа с метками), но аналогов в
    > BSD, насколько я знаю, нет.

    мне может кто-нибудь подсказать хоть один практический пример нафига подобное нужно?

     
     
  • 4.43, Аноним (-), 20:38, 21/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > мне может кто-нибудь подсказать хоть один практический пример нафига подобное нужно?

    Практический пример - мапы dst addr/port -> dnat addr/port, или src addr/port -> snat addr/port. Не совсем addr -> mark, но тоже киллeр-фича pf tables. Была.

     
     
  • 5.44, pavel_simple (ok), 09:49, 22/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> мне может кто-нибудь подсказать хоть один практический пример нафига подобное нужно?
    > Практический пример - мапы dst addr/port -> dnat addr/port, или src addr/port
    > -> snat addr/port. Не совсем addr -> mark, но тоже киллeр-фича
    > pf tables. Была.

    это типа с диапазона серых ip на диапазон белых?

    дык это давно можно через -j NATMAP

    какие ещк были киллер фичи?

     

  • 1.2, Аноним (-), 00:44, 18/04/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    PF и IPFW хватает всем нормальным людям
     
     
  • 2.3, axe (??), 00:45, 18/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    кому не хватает, для тех есть netgraph )
     
     
  • 3.7, Аноним (-), 02:03, 18/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > кому не хватает, для тех есть netgraph )

    Вы сравниваете немного разные вещи.

     
     
  • 4.9, Аноним (-), 02:08, 18/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    netgraf слишком общая и универсальная вещь, и требует серьезного напилинга под конкретные задачи.
     
  • 2.30, Аноним (-), 17:00, 18/04/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >PF и IPFW хватает всем нормальным людям

    А 640 кбайт всем хватает?

     
     
  • 3.32, Аноним (-), 01:41, 19/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > А 640 кбайт всем хватает?

    Если очень хочется - то да.

     

  • 1.4, Аноним (-), 00:59, 18/04/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    > Реализован экспорт набора правил в форматы XML и JSON. Возможность импорта
    > ожидается в следующем выпуске.

    #include <trollface.h> однако :)

     
     
  • 2.31, Аноним (-), 17:05, 18/04/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Всё правильно. Можно ещё добавить в/из: YAML, CSV, SQLite.
     
     
  • 3.33, Аноним (-), 01:44, 19/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Всё правильно. Можно ещё добавить в/из: YAML, CSV, SQLite.

    И плагин для связи с systemd через kdbus.

     
  • 3.36, Аноним (-), 07:17, 19/04/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Всё правильно. Можно ещё добавить в/из: YAML, CSV, SQLite.

    Да, слушай, надо какой-нибудь самопальный упаковщик написать, пожалуй. Чтобы паковал ваши ценные данные. А как распаковывать - я потом подумаю. В следующей версии. Заодно будет стимул донейтить на новую версию [пример Тео больно уж заразителен]. :)

     
     
  • 4.40, Аноним (-), 01:57, 20/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> Всё правильно. Можно ещё добавить в/из: YAML, CSV, SQLite.
    > Да, слушай, надо какой-нибудь самопальный упаковщик написать, пожалуй. Чтобы паковал ваши
    > ценные данные. А как распаковывать - я потом подумаю.

    В данном случае - наоборот (есть только преобразователь из специфичного блоба в общепринятые текстовые форматы, то есть распаковщик).

     

  • 1.5, asavah (ok), 01:07, 18/04/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Изменений овер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

     
     
  • 2.11, Аноним (-), 02:14, 18/04/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Выражать многое в нескольких словах - признак мастерства.
     

  • 1.6, rob pike (?), 01:09, 18/04/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Поддержка гибридных IPv4/IPv6 таблиц

    Отлично.

     
  • 1.10, Аноним (-), 02:13, 18/04/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Очень надеюсь, что добавят поддержку ipset. Он очень хорошо оптимизирован под гигантские списки адресов/подсетей/портов, и вряд ли более универсальный аналог из nftables будет работать быстрее.
     
     
  • 2.12, Аноним (-), 05:08, 18/04/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ты прибалт что-ли? Он ещё в прошлом релизе работал быстрее ipset.
     
     
  • 3.24, Аноним (-), 13:26, 18/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Ты прибалт что-ли? Он ещё в прошлом релизе работал быстрее ipset.

    Пруфы будут? Нужны нормальные бенчмарки типа такого http://daemonkeeper.net/781/mass-blocking-ip-addresses-with-ipset/

     

  • 1.13, Ващенаглухо (ok), 09:01, 18/04/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    какой уродливый синтаксис у этого nft, iptables был намного проще.
     
     
  • 2.15, Аноним (-), 10:04, 18/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Воистину так. В принципе, все понимаю про преимущества nftables, но его освоение по большей тормозит именно дико уродливый синтаксис правил nft...
     
     
  • 3.16, Andrey Mitrofanov (?), 10:07, 18/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Воистину так. В принципе, все понимаю про преимущества nftables, но его освоение
    > по большей тормозит именно дико уродливый синтаксис правил nft...

    И это пройдёт. Освоение iptables то же самое тормозит, пока не прочитаешь [и поймёшь!] достаточно решений реальных проблем. И для этого всё будет.

     
     
  • 4.17, Аноним (-), 10:11, 18/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >И это пройдёт. Освоение iptables то же самое тормозит, пока не прочитаешь [и поймёшь!]
    >достаточно решений реальных проблем. И для этого всё будет.

    В принципе да, iptables в свое время тоже осваивал на практике, может когда дойдет дело до практики, то будет проще во всем разобраться..
    Но в синтаксисе iptables имхо есть системность, там можно мысленно разобрать правило на куски и понять что за что отвечает... А здесь синтаксис nft мне лично напоминает хаотично и безсистемно понаписанные наборы слов, которые якобы должны что-то означать..

     
     
  • 5.20, llolik (ok), 10:24, 18/04/2014 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Читаю wiki-справку проекта. Вроде бы как даже удобней iptables, там даже примеры есть, как описать одно и то же правило в ipt и nft. Другое дело,  что сама вики пока довольно скудная.
     
  • 5.26, Аноним (-), 13:29, 18/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > А здесь синтаксис nft мне лично напоминает хаотично и безсистемно понаписанные наборы слов, которые якобы должны что-то означать..

    Когда не знаешь значения большинства слов, это естественно. И с iptables сначала так, если не хуже.
    Учитесь, читайте документацию.

     
  • 2.22, анон (?), 11:08, 18/04/2014 [^] [^^] [^^^] [ответить]  
  • +6 +/
    iptables привычнее, но не проще. Особенно учитывая, что *tables слишком много.
     
     
  • 3.34, Аноним (-), 01:50, 19/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > 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).

     
     
  • 4.38, pavel_simple (ok), 22:29, 19/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> 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 откуда взялси?

     
     
  • 5.39, Аноним (-), 01:54, 20/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > точно watch? где такие?

    Watcher. В ebtables. log, nflog, ulog.

    > что как-бы логично т.к. это фильтр для одного протокола и мачить там нечего

    Была бы расширяемая архитектура - глядишь, поддерживал бы и больше протоколов.

    > recent не изменяет сам пакет и в этом смысле ничем не отличим от того-же MARK

    MARK - это target.

    > бред о том что в ip6tables есть только match и отсутствуют target откуда взялси?

    Там есть только target, но нет target extensions (нельзя применить больше одной операции к пакету в одном правиле). В ebtables за одно правило можно, например, поставить метку, подменить адрес и пропустить пакет.

     
     
  • 6.41, pavel_simple (ok), 14:46, 20/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> точно 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 существует совершенно оправданно.

     
     
  • 7.42, Аноним (-), 20:35, 21/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > посмотрел 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 никаких вопросов нет).

     
     
  • 8.45, pavel_simple (ok), 09:54, 22/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    деление на watch и target сам ты придаток, напомни себе определение и перестань ... текст свёрнут, показать
     

  • 1.14, жабабыдлокодер (ok), 09:35, 18/04/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >При чтении файла с правилами, содержащего ошибки, операция прерывается только после 10 ошибок (а не после первой, как раньше), что значительно ускоряет процесс отладки больших наборов правил.

    Ай да молодцы!

     
  • 1.21, Аноним (-), 10:49, 18/04/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    закос на ipfw и json
     
     
  • 2.37, Аноним (-), 15:52, 19/04/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    технически - скорее обеспечивается возможность сделать "закос"(и взаимодействие) подо что угодно, помимо перечисленного.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру