LINUX.ORG.RU

Новая реализация пакетного фильтра nftables будет добавлена в ядро Linux 3.13

 , , , ,


3

3

В ветку linux-next, на базе которой будет сформировано ядро версии 3.13, добавлена новая реализация подсистемы пакетной фильтрации nftables. Разработка системы ведётся с 2009 года, её целью является замена подсистем iptables, ip6table, arptables и ebtables. Результата разработчики желают добиться путём сокращения количества (и дублей) кода уровня ядра, упрощения взаимодействия ядра и userspace-приложений, а также использования байт-кода для компилирования правил фильтрации и исполнения их в ядре.

Представленный для включения в ядро код подразумевает сосуществование старых и новой подсистем, поскольку nftables ещё требует доработки и тестирования.

Идея в целом позаимствована в реализациях Berkeley Packet Filters, применяемых в BSD-системах. При этом синтаксис пользовательских правил (утилиты nft) также напоминает синтаксис ipfw FreeBSD.

Например, для приёма icmp-сообщений echo-request, в командной строке (скрипте) необходимо набрать:

nft add rule  filter input icmp type echo-request accept

Сводный список правил формируется как иерархическая блочная структура, чем-то напоминающая pf и npf:

# nft list table filter -n  -a
table filter {
        chain output {
                 table filter hook output priority 0;
                 ip protocol tcp counter packets 82 bytes 9680 # handle 8
                 ip saddr 127.0.0.1 ip daddr 127.0.0.6 drop # handle 7
        }
}
# nft  add rule filter output position 8 ip daddr 127.0.0.8 drop 
# nft list table filter -n -a
table filter {
        chain output {
                 table filter hook output priority 0;
                 ip protocol tcp counter packets 190 bytes 21908 # handle 8
                 ip daddr 127.0.0.8 drop # handle 10
                 ip saddr 127.0.0.1 ip daddr 127.0.0.6 drop # handle 7
        }
}

>>> Подробности

★★★

Проверено: Shaman007 ()
Последнее исправление: cetjs2 (всего исправлений: 3)

Ответ на: комментарий от DNA_Seq

Наверно пока крупные проекты не пересядут на nftables.

Quasar ★★★★★
()
Ответ на: комментарий от AS

Наоборот - производительность поднимется. Данная область как раз та, где лучше понапихать гибких механизмов создания правил. А поскольку выполнение будет идти на уровне ядра, то ускорение будет приличное, если не напортачат быдлокодом. Могу привести в пример accel-pptp. Значительное повышение производительности (на порядки) за счёт реализации на стороне ядра.

Quasar ★★★★★
()
Ответ на: комментарий от jekader

Наверняка для совместимости оставят враппер с реализацией iptables.

Quasar ★★★★★
()
Ответ на: комментарий от Yustas

С точки зрения администратора это приведёт к унификации. В новости же написано.

Quasar ★★★★★
()
Ответ на: комментарий от jekader

Вот пусть этот дебил Поцеринг сваливает с линукса и делает своё kerneld.

Quasar ★★★★★
()
Ответ на: комментарий от anonymous

Это не Поцеринг - документация будет.

Quasar ★★★★★
()
Ответ на: комментарий от Dark_SavanT

Хз. Я его в продакшне 5 лет использовал, и всеравно в конечном итоге пришлось перейти на iptables + tc + htb. Потому что десятки и сотни раз приходилось ломать голову что опять не так настроено, и почему нужная очередь недобирает бендвиса. Но с точки зрения десятка примитивных правил(типа запретить/разрешить пару портов туда сюда) pf и правда очень прост и нагляден(собственно поэтому первичное решение и было построено на нём). Но, повторюсь, когда сложность фаервола(ну и трафик шейпера) растут - pf тупо неюзабелен.

Jetty ★★★★★
()
Ответ на: комментарий от Dark_SavanT

Ну и да, каждый порядочный BSDшник мне всегда доказывал что pf реально мега крут, и что это я не разобрался. Однако на практике каждый из них ни разу не строил ни одного решения больше пару офисных роутеров, с десятком правил.

Jetty ★★★★★
()
Ответ на: комментарий от Quasar

Я о том, что мне удобно, когда я правила для NAT/фаервола могу бахнуть прямо в скрипте, ну или вызвать один скрипт из другого.

leg0las ★★★★★
()

использования байт-кода ... в ядре

Приплыли... Впрочем, я сижу на 2.6.32 и мне пофиг.

anonymous
()

синтаксис значительно хуже стандартного iptables

Синтаксис значительно хуже стандартного iptables.

Уже справедливо заметили, что:

1 - стандартные для Linux и POSIX тучи библиотек а ля getopt к этому уже не прикрутишь;

2 - визуально всё сливается;

3 - появляется куча служебных слов (add, protocol, daddr, ...), которые более нельзя использовать для названий дочерних цепочек, матчей и таргетов, и про это надо постоянно помнить.

Надеемся, что в плане гибкости настроек ничего не испортят.

А что там будет с производительностью - ещё посмотрим.

anonymous
()
Ответ на: комментарий от Jetty

Хз. Я его в продакшне 5 лет использовал

И что, считаешь это весомым аргументом против pf?

Но, повторюсь, когда сложность фаервола(ну и трафик шейпера) растут - pf тупо неюзабелен.

Жуткое 4.2...а еще регистрат.

anonymous
()
Ответ на: комментарий от Jetty

Однако на практике каждый из них ни разу не строил ни одного решения больше пару офисных роутеров

А Карсноярский Алюминеваый считается для тебя «решением с больше чем пара роутеров»?

anonymous
()

Ради объективности, стоит заметить что в комплекте с nf_tables идут юзерспейсные библиотеки разной степени низкоуровневости. Утилита nftables построена на их основе.

Ну и сырой netlink для настоящих джедаев.

Так что стабильный, красивый и разнообразный ГУЙ для новой технологии обеспечен. Скриптописатели же могут разработать примитивы любого рода сложности.

Кроме того, множество плюшек поимеют разработчики веб-интерфейсов, автоматических конфигураторов, и эмбедщики.

Macil ★★★★★
()
Ответ на: комментарий от anonymous

Боюсь что красноярский алюминевый это и есть «офисный роутер». Сомневаюсь что там что-то более сложное. Ну разве что больше кабелей и свитчей...

Jetty ★★★★★
()
Ответ на: комментарий от anonymous

вся суть GPL, или им втулят блоб, или надо идею побыстрому брать в BSD

я так понимаю, что это не первая идея, которую стырили у бсдешников
а сколько те сами стырили ...

kto_tama ★★★★★
()
Ответ на: комментарий от Jetty

лол. Все с тобой ясно, даже к ванге не ходи.

anonymous
()
Ответ на: комментарий от Jetty

ни одного решения больше пару офисных роутеров

Бздуны работают с железными маршрутизаторами и прекрасно понимают, что фильтровать трафик на писюках - удел пионерии.

anonymous
()

Хорошая задумка.

После использования ipfw, iptables выглядел совсем не admin-friendly.

dvl36
()
Ответ на: комментарий от jekader

синтаксисом от iptables

Для таких в аду отдельное место будет.

anonymous
()
Ответ на: комментарий от a1batross

А есть для л2тп? :3

ВНЕЗАПНО

# zgrep -i l2tp /proc/config.gz
CONFIG_L2TP=y
# CONFIG_L2TP_DEBUGFS is not set
CONFIG_L2TP_V3=y
CONFIG_L2TP_IP=m
CONFIG_L2TP_ETH=m
CONFIG_PPPOL2TP=m

И уже давно, с 2.6.24 вроде бы.

om-nom-nimouse ★★
()
Ответ на: комментарий от anonymous

Начнем с протоколов с адовой кучей дублирующего кода в ядре

Анонимус, акстись. Iptables то тут при чем?

oskar0609
()
Ответ на: комментарий от Jetty

У меня при попытке сделать достаточно развесистый скрипт настраивающий iptables в зависимости от обстоятельств и настроек извне - было очень много жопоболи. К сожалению на bsd такое делать не пытался, ибо встройка.

Dark_SavanT ★★★★★
()

Так в нетбсд вместо «стандартных библиотек» просто встроили lua script в ядро, да и не парятся. У них, судя по всему, скоро вообще один единственный синтаксис конфигурирования ядра останется, на все подсистемы...да еще обширные возможности пилить прототипы будущих реализаций появятся прямо в скриптах ядра. Вот, думаю, куда надо стремится, а не очередной синтаксис изобретать. Все же готовое есть, что велосипедить то. lua очень производительна, генерит байткод и в ядро как показывает нетбсд ее встроить реально...да и придумывалась lua как встраиваемый высокопроизводительный скрипт.

i3draven ★★
()
Ответ на: комментарий от Dark_SavanT

было очень много жопоболи.

так и думал, глядя на твою аватарку xD

anonymous
()
Ответ на: комментарий от Dark_SavanT

У меня при попытке сделать достаточно развесистый скрипт настраивающий iptables в зависимости от обстоятельств и настроек извне - было очень много жопоболи.

Пользуйся netlink. Будь мужчиной!

Сабж проблему должен порешать, ибо юзерспейс-библиотеки.

Macil ★★★★★
()
Ответ на: комментарий от anonymous

Бздуны сами себе цискари, они опытные, сцуко.

anonymous
()
Ответ на: комментарий от Dark_SavanT

Потому что не надо делать это скриптом :-) Ни в БСД, ни в Линукс. Для этого есть таблицы, а дальше iptables(впрочем как и ipfw) просто класифицирует трафик и отправляет в соответствующую таблицу... Но нет же, скрипт пишут :)

Jetty ★★★★★
()
Ответ на: комментарий от NaN

не осознал яваскриптоподобности честно говоря. почему не c-подобный, если ты о скобках?

AndreyKl ★★★★★
()

честно говоря iptables мягко говоря нудноваты. может это будет лучше.

AndreyKl ★★★★★
()
Ответ на: комментарий от pekmop1024

а в новой штуке что можно будет одной строкой?

AndreyKl ★★★★★
()
Ответ на: комментарий от a1batross

Да, и pppd требует. А про процессор - процессор он жрёт только когда сам, без ядерного модуля работает.

om-nom-nimouse ★★
()
Ответ на: комментарий от om-nom-nimouse

А, разобрался уже. Оказывается, у xl2tpd есть юз kernel, который сообственно и работает с ядром, но не находит модуль и работает сам, отчего и жрет ЦПУ.

Спасибо! ^^

a1batross ★★★★★
()
Последнее исправление: a1batross (всего исправлений: 1)
Ответ на: комментарий от Jetty

Есть файлик с настройками, на их основе надо при каждом запуске выставлять правила для фаерволла. Правила раскиданы по цепочкам, всё вроде нормально. Но - появляется такая незадача, внешний интерфейс может меняться с одного на другой и при этом надо делать много дополнительной работы - типа вычистки правил по цепочкам и очередного их пересоздания с изменившимися параметрами. Ибо не сервер, где можно выставить один раз, глобально и надёжно.

Главная жопоболь была даже не в iptables, а в том, как правильно раскидать его настройку по разным скриптам, которые срабатывают в разных ситуациях, вычистить старые правила, не задев те, которые нужны, добавить новые правила и молиться, что ты нигде не накосячил.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от Dark_SavanT

Вот видишь, все от нежелания думать - создаешь бридж для «внешнего» интерфейса и роутишь трафик в него. Интерфейс-члены добавляются туда динамически... Просто, правда?

Jetty ★★★★★
()
Ответ на: комментарий от Dark_SavanT

нет. ppp интерфейсы не бриджуются.

Осиль уже опции ip-up/ip-down, unit, а еще лучше /etc/network/interfaces (или схожие) ;)

Macil ★★★★★
()
Ответ на: комментарий от Shadow

Кстати описанная выше проблема точно так же характерна как для Linux+iptables так и для FreeBSD+pf/ipfw. Так что ваш коментарий как минимум не корректен.

Jetty ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.