Проект Netfilter представил (http://marc.info/?l=netfilter&m=139022350623824&w=2) первый ориентированный на конечных пользователей выпуск пакетного фильтра Nftables 0.099 (http://netfilter.org/projects/nftables/index.html), а также релиз (http://netfilter.org/news.html#2014-01-20a) сопутствующей библиотеки libnftnl 1.0.0 (http://netfilter.org/projects/libnftnl/), предоставляющей низкоуровневый API для взаимодействия с подсистемой nf_tables. Напомним, что подсистема nf_tables включена в состав ядра Linux 3.13 (https://www.opennet.ru/opennews/art.shtml?num=38845), а в рамках пакета Nftables поставляются компоненты, работающие в пространстве пользователя. Одновременно опубликован (http://marc.info/?l=netfilter-devel&m=139026112504105&w=2) пакет nftables-plus 0.099, который включает в себя дополнительные патчи (http://xtables.de/) для улучшения удобства использования утилиты nftables.
В рамках проекта Nftables развивается новая реализация пакетного фильтра, унифицирующая интерфейсы фильтрации пакетов для IPv4, IPv6, ARP и сетевых мостов, и нацеленная на замену iptables, ip6table, arptables и ebtables. Для реализации поставленной задачи Nftables предоставляет на уровне ядра лишь общий интерфейс, не зависящий от конкретного протокола и предоставляющий базовые функции обработки пакетов, построенные с использованием типовых компонентов инфраструктуры Netfilter, в том числе применяются существующие хуки, система отслеживания состояния соединений, компоненты организации очередей и подсистема ведения лога.Непосредственно логика фильтрации и специфичные для протоколов обработчики компилируются в байткод в пространстве пользователя, после чего данный байткод загружается в ядро при помощи интерфейса Netlink и выполняется в специальной виртуальной машине. Подобный подход позволяет значительно сократить размер кода фильтрации, работающего на уровне ядра и вынести все функции разбора правил и логики работы с протоколами в пространство пользователя. Например, для реализации поддержки фильтрации нового протокола все изменения могут быть внесены в пользовательском пространстве без обновления кода ядра.
Для формирования правил фильтрации предлагается использовать утилиту nft, которая проверяет корректность правил и транслирует их в байткод. Правила могут добавляться не только инкрементально, но и загружаться целиком из файла на диске. Синтаксис правил не похож (https://home.regit.org/netfilter-en/nftables-quick-howto/) на iptables и отличается использованием иерархических блочных структур вместо линейной схемы. Язык классификации правил основан на реальной грамматике, при обработке которой используется сгенерированный в bison парсер. Для обеспечения обратной совместимости с линейными правилами предоставляется специальная прослойка, позволяющая использовать iptables/ip6tables поверх инфраструктуры Nftables.
Пример правил:
<font color="#461b7e">
table filter {
chain input {
table filter hook input priority 0;
ct state established accept
ct state related accept
meta iif lo accept
tcp dport ssh counter packets 0 bytes 0 accept
counter packets 5 bytes 5 log drop
}chain output {
table filter hook output priority 0;
ct state established accept
ct state related accept
meta oif lo accept
ct state new counter packets 0 bytes 0 accept
}
}
</font>URL: http://marc.info/?l=netfilter&m=139022350623824&w=2
Новость: https://www.opennet.ru/opennews/art.shtml?num=38901
> унифицирующая интерфейсы фильтрации пакетов для IPv4, IPv6Ура!!!
---
Кто уже юзал, - там порядок следования правил в цепочке важен?
Или впаяли какой-нибудь искусственный интеллект
"Ура!!!" будет, когда в ядре появится MPLS/VPLS, а nftables будет и по метке фильтровать, и по IP.
Ладно MPLS, пусть хотя бы multicast поддержку сделают для NAT, невозможно через маршрутизатор на Linux IPTV смотреть без костылей типа udpxy.
А зачем мультикастовое прокси в ядре?
> Ладно MPLS, пусть хотя бы multicast поддержку сделают для NAT, невозможно через
> маршрутизатор на Linux IPTV смотреть без костылей типа udpxy.А что-то типа
iptables -t filter -A INPUT -d 224.0.0.0/4 -i eth0 -j ACCEPT
iptables -t filter -A INPUT -s 224.0.0.0/4 -i eth0 -j ACCEPT
iptables -t filter -A FORWARD -d 224.0.0.0/4 -j ACCEPT
iptables -t filter -A FORWARD -s 224.0.0.0/4 -j ACCEPT
>> Ладно MPLS, пусть хотя бы multicast поддержку сделают для NAT, невозможно через
>> маршрутизатор на Linux IPTV смотреть без костылей типа udpxy.
> А что-то типа
> iptables -t filter -A INPUT -d 224.0.0.0/4 -i eth0 -j
> ACCEPT
> iptables -t filter -A INPUT -s 224.0.0.0/4 -i eth0 -j ACCEPT
> iptables -t filter -A FORWARD -d 224.0.0.0/4 -j ACCEPT
> iptables -t filter -A FORWARD -s 224.0.0.0/4 -j ACCEPTА IGMP? Linux IGMP не NAT'ит.
> А IGMP? Linux IGMP не NAT'ит.И это очень хорошо. :)
Если вы посмотрите в стандарт IGMP v3, то он surprisingly скажет вам, что получатель от роутера отличается тем, что в IGMP-пакете роутера должен быть IP-адрес интерфейса, с которого идёт IGMP-запрос, а в IGMP-пакете получателя (конечного хоста) в IGMP-пакете должны быть нули (IP-адрес 0.0.0.0) -- так, кстати, их друг от друга отличать и полагается.
Вы что имеете в виду под NAT'ом IGMP? NAT 0.0.0.0 в куда-нибудь?
igmpproxy
а для выпресчата по вланам групповой мультикаст? сейчас только фряха с мроутедом может это делать
( ... задумался ... )А что вы, собственно, имеете в виду?
Как и зачем NAT'у взаимодействовать с мультикастным потоком?
Для того, чтобы "из некоторой точки пространства", под которым в данном случае подразумевается пространство IP-connected узлов к тебе на узел полился мультикаст, всё, что тебе нужно -- это попросить твой роутер подписать тебя на нужную тебе мультикастную группу.
Для этого существует соответствующий тип IGMP-запроса, который идёт от твоего компьютера (ТВ-приставки, etc) на твой Linux-роутер.
И НИКОМУ ДРУГОМУ этот запрос вообще не предназначен, зачем его куда-то во что-то там NAT'ить?
В обратную же сторону поток польётся с IP-адресом отправителя каким-то там (ну, с адресом источника) и с IP-адресом получателя из сети класса D -- собственно, IP-адресом мультикастной группы, на которую тебя подписал твой маршрутизатор. Здесь тоже, вроде как, NAT'ить особо нечего.
Всё, что тебе нужно -- это научить твой Linux-роутер реагировать соответствующим образом на IGMP -- либо как stub-роутер, транслируя IGMP-запрос дальше ОТ СВОЕГО ИМЕНИ (google://igmpproxy), либо как нормальный PIM-роутер (google://xorp). И, опять-таки, ни первый, ни второй вариант NAT'ов не предусматривают.
> Для этого существует соответствующий тип IGMP-запроса, который идёт от твоего компьютера
> (ТВ-приставки, etc) на твой Linux-роутер.Вот он у меня там на Linux-роутере и помирает, запрос этот.
> Всё, что тебе нужно -- это научить твой Linux-роутер реагировать соответствующим образом
> на IGMP -- либо как stub-роутер, транслируя IGMP-запрос дальше ОТ СВОЕГО
> ИМЕНИ (google://igmpproxy), либо как нормальный PIM-роутер (google://xorp).Ага, я читал это, и это: «напоследок могу лишь посоветовать посматривать на статистику $IF_IN при пользовании igmpproxy. известно, что [далеко] не всегда "отписка" проходит корректно и это вполне может забить канал рано или поздно (при активной смене каналов вы быстро заметите если что-то пойдёт не так...)» именно так у меня и забивалось, нехочу это ставить.
Почему нельзя было сделать некий проброс IGMP надёжно в ядре? :(
>> Для этого существует соответствующий тип IGMP-запроса, который идёт от твоего компьютера
>> (ТВ-приставки, etc) на твой Linux-роутер.
> Вот он у меня там на Linux-роутере и помирает, запрос этот.Ну да, all is working as designed.
> Ага, я читал это, и это: «напоследок могу лишь посоветовать посматривать на
> статистику $IF_IN при пользовании igmpproxy. известно, что [далеко] не всегда "отписка"
> проходит корректно и это вполне может забить канал рано или поздно
> (при активной смене каналов вы быстро заметите если что-то пойдёт не
> так...)» именно так у меня и забивалось, нехочу это ставить.Я не очень понимаю, что тут имеется в виду.
Если мы говорим об IGMP v1, тогда это его неустранимая проблема, если потеряется пакет на отписку (ну, например, из-за flaky network, прогруженной суровым мультикастным трафиком), "тады ой" -- IGMP v1 не предусматривает механизмов какой-либо "пересинхронизации" между двумя смежными мультикаст-маршрутизаторами.
Но в 2014 году все давно используют IGMP v3, у которого таких проблем нет.
> Почему нельзя было сделать некий проброс IGMP надёжно в ядре? :(
Потому, что IGMP вообще не пробрасывается. Он, если угодно, "регенерируется".
> Потому, что IGMP вообще не пробрасывается. Он, если угодно, "регенерируется".Сейчас когда вспоминал, кстати, вычитал: "Luckily, starting from 2.6.34, the kernel has IGMP snooping feature for the software bridges" у меня 2.6.32-5-amd64 попробую как-нибудь после обновления ещё раз, возможно с IGMP snooping получится завести без user mode утилит.
>> Потому, что IGMP вообще не пробрасывается. Он, если угодно, "регенерируется".
> Сейчас когда вспоминал, кстати, вычитал: "Luckily, starting from 2.6.34, the kernel has
> IGMP snooping feature for the software bridges" у меня 2.6.32-5-amd64 попробую
> как-нибудь после обновления ещё раз, возможно с IGMP snooping получится завести
> без user mode утилит.Это совершенно другая песня.
Если ваш провайдер готов выдать вам дополнительный IP-адрес для ТВ-приставки, тогда, конечно, надо её забриджить на внешний интерфейс и не полировать моск. :)
Но иногда провайдер лезет в головку полового члена и хочет, чтобы ему за каждый адрес бапке плотили -- ну, жадные есть провайдеры, что уж тут.
Впрочем, тогда можно вообще поставить свитч, включить в него ТВ-приставку, аплинк от провайдера и Linux-роутер, ибо IGMP Snooping в свитчи встроен с незапамятных времён.
> Если ваш провайдер готов выдать вам дополнительный IP-адрес для ТВ-приставки, тогда, конечно,
> надо её забриджить на внешний интерфейс и не полировать моск. :)То есть через NAT не будет работать? Блин :(
>> Если ваш провайдер готов выдать вам дополнительный IP-адрес для ТВ-приставки, тогда, конечно,
>> надо её забриджить на внешний интерфейс и не полировать моск. :)
> То есть через NAT не будет работать? Блин :(Можно поставить бридж меж tap и выходным фейсом (если их два иль больше),
а ebtables_ом заворачивать весь мультикаст на tap %)
> То есть через NAT не будет работать? Блин :(на фрибсд можно сделать так - https://www.opennet.ru/tips/info/2649.shtml
и имеющемуся на той же машине нату это никак не мешает
работает гораздо надежней чем igmpproxy
>> То есть через NAT не будет работать? Блин :(
> на фрибсд можно сделать так - https://www.opennet.ru/tips/info/2649.shtml
> и имеющемуся на той же машине нату это никак не мешает
> работает гораздо надежней чем igmpproxy1. слава богу не все настолько укуренные чтобы ставить домой рутер на фряхе чтобы интернеты с теливизерем смотреть.
2. на linux ebtables это делается много проще -- но быэсдэшнеги как всегда..
>"Ура!!!" будет, когда в ядре появится MPLS/VPLS, а nftables будет и по метке фильтровать, и по IP.Реквестуй в проект http://sourceforge.net/projects/mpls-linux/ включение, наконец-таки, его в ванильное ядро.
>>"Ура!!!" будет, когда в ядре появится MPLS/VPLS, а nftables будет и по метке фильтровать, и по IP.
> Реквестуй в проект http://sourceforge.net/projects/mpls-linux/ включение, наконец-таки,
> его в ванильное ядро.MPLS™ Patenetd by IBM® Corporation ©.
Опенбздуны реализацию протокола, запатентованного, Cisco Systems (R) включили, назвав его по другому.
Да и к тому же.
"Организация Open Invention Network (OIN), ставящая перед собой цель защиты экосистемы Linux от патентных претензий. ... В число участников OIN входят такие компании, как IBM, Sony, Philips, Red Hat, Novell, NEC, Oracle, HP, Juniper, Facebook, Google, Cisco, Rackspace Hosting, Symantec, Fujitsu, LG, HTC."
> когда в ядре появится MPLS/VPLSА зачем он там? Вы собрались делать из пЫонернетовских писюков на BSD core router'ы? У пЫонерии или писюки слишком крутые стали или оптимизма сильно дофига oO.
Да нормально, если гигабит до семи-десяти в сторону аплинков.
netflow пишется, BGP стоит, клиенты довольны.
Правда, не на BSD, а на линуксе, и не MPLS, а IPv4/ethernet,и не core, а border © армянское радио.
> Да нормально, если гигабит до семи-десяти в сторону аплинков.
> netflow пишется, BGP стоит, клиенты довольны.
> Правда, не на BSD, а на линуксе, и не MPLS, а IPv4/ethernet,и
> не core, а border © армянское радио.Кстате да, две 4-6-ядерные машинки на ксеонах за 120-150 тыров каждая (две только ради надежности) с линухами, BIRD'ом и VRRP в качестве бордера спокойно протянут до 10-15 гиг в чистом роутинге, да еще и с фулвьюхой, возможно, не одной, и с PBR, и даже с несложным шейпером при необходимости. Аналог по стоимости найти сложновато.
Прикольно http://www.isoc.org/inet2000/cdproceedings/1h/1h_2.htm
> там порядок следования правил в цепочке важен?Естественно. Каждому правило ставится в соответствие номер-идентификатор (handle), которые можно вывести командой nft list -a
Ну вот к примеру у правила table filter hook output priority 0;
по-моему вообще неважен порядок, тут главное само наличие.Просто проскакивает частый косяк в iptables между -I и -A,
INSERT суёт в начало таблицы, ADD - в конец.сделал iptables -t filter -I ля-ля-ля -j RETURN и через месяц только вдуплил,
что у тя все остальные правила тупа не работали, хоть в iptable -L все красиво.
> Ну вот к примеру у правила table filter hook output priority 0;
> по-моему вообще неважен порядок, тут главное само наличие.Это не правило, а метаданные цепочки. У них и handle нет.
> Просто проскакивает частый косяк в iptables между -I и -A,
> INSERT суёт в начало таблицы, ADD - в конец.А еще -I умеет совать после правила с заданным номером.
> сделал iptables -t filter -I ля-ля-ля -j RETURN и через месяц только вдуплил,
> что у тя все остальные правила тупа не работали, хоть в iptable -L все красиво.Бывает.
> А еще -I умеет совать после правила с заданным номером.Вот ещё, это же считать надо :)
>> А еще -I умеет совать после правила с заданным номером.
> Вот ещё, это же считать надо :)Зачем считать? --line-numbers же показывает номера.
судя по отсутствию активности вы открыли ему новый мир :)
> Ну вот к примеру у правила table filter hook output priority 0;
> по-моему вообще неважен порядок, тут главное само наличие.
> Просто проскакивает частый косяк в iptables между -I и -A,
> INSERT суёт в начало таблицы, ADD - в конец.Это не баг, это фича, и ей нужно пользоваться.
-A удобен для запрещающих равил
-I для разрещающих, а если еще указать номер правила -I 13 - то вообще красота будет :)
Да, но там есть функция insert, вставляет нужное в нужное.
Это замена iptables?
когда допилят, да.
пока ещё сыроват для продакшна, но поиграться уже можно.
А чем старый аналог плох был?
Кривой архитектурой. Четыре велосипеда, полученные путем копипасты одного и того же кода, и потом десять лет развивавшиеся независимо друг от друга (ну, кроме ip+ip6, их более-менее синхронизировали).
> А чем старый аналог плох был?Там ты программил правила на почти асме, а тут синтаксис до си заапгрейдили :).
> Там ты программил правила на почти асме, а тут синтаксис до си заапгрейдили :).Разница в синтаксисе далеко не такая существенная.
Это замена iptables, ip6tables, arptables и ebtables
> ....arptables...то есть, типа, iptables не умел отлавливать пакеты по мак-адресам, да ?
о чём ты, мальчик?
> о чём ты, мальчик?Перепутал, с кем не бывает :))
>Подобный подход позволяет значительно сократить размер кода фильтрации, работающего на уровне ядра и вынести все функции разбора правил и логики работы с протоколами в пространство пользователявот чем это лучше? скажите нубу плиз.
> вот чем это лучше? скажите нубу плиз.Для пользователя - мало чем. А вот для разработчиков - очень даже лучше. Не надо поддерживать четыре разных фаервола - это раз, кроме того, для добавления модуля фаервола (которые iptables -m и iptables -j) нужно было патчить и ядро, и управляющую программу. Теперь патчить ядро не надо.
А как будет работать «система отслеживания состояния соединений»? Логику её модулей тоже придётся на BPF писать?
> А как будет работать «система отслеживания состояния соединений»? Логику её модулей тоже придётся на BPF писать?А ее не трогали. Как работала, так и работает.
> Для пользователя - мало чем.Для пользователя будет заметно, когда его роутер перестанет перегреваться на торрентах :-)
>> Для пользователя - мало чем.
> Для пользователя будет заметно, когда его роутер перестанет перегреваться на торрентах
> :-)Мда, такого бреда...
> Для пользователя будет заметно, когда его роутер перестанет перегреваться на торрентах :-)Радиатор+термопаста. В особо запущенных случаях - кулер. Ну и руки из правильного места.
Похоже, что оно не поддерживает ipset, вместо этого вводя свой аналогичный велосипед.
Конечно, ipset за несколько лет гораздо лучше вылизан по скорости и потреблению памяти, да еще имеет критически важную фичу, которой нет в ntf - таймауты.
table filter {
chain input {
table filter hook input ...пока синтаксис выглядит не очень, зачем одно и тоже два раза повторять, неясно.
> table filter {
> chain input {
>
> table filter hook input ...
> пока синтаксис выглядит не очень, зачем одно и тоже два раза повторять,
> неясно.А можно и не повторять
table filter {
chain inbound {
table filter hook input ...
например.Имя цепочки - на выбор пользователя, имена хуков netfilter - стандартные.
table filter же всё равно два раза.
> table filter же всё равно два раза.На самом деле, во второй раз - type filter. А в первый раз - опять-таки можно переименовывать.
>> table filter же всё равно два раза.
> На самом деле, во второй раз - type filter. А в первый
> раз - опять-таки можно переименовывать.ну назвали бы type тогда :) понятно, спасибо!
> ну назвали бы type тогда :)Так и назвали. См. примеры http://people.netfilter.org/wiki-nftables/index.php/Simple_r...
В новости просто приводится слегка устаревший синтаксис из более раннего источника.
>> ну назвали бы type тогда :)
> Так и назвали. См. примеры http://people.netfilter.org/wiki-nftables/index.php/Simple_r...
> В новости просто приводится слегка устаревший синтаксис из более раннего источника.логичней было бы сократить
table ip filter {
chain input {
type filter hook input priority 0;
}
доtable ip filter {
chain input {
hook priority 0;
}
>[оверквотинг удален]
> chain input {
>
> type filter hook input priority 0;
> }
> до
> table ip filter {
> chain input {
>
> hook priority 0;
> }type разный бывает, например, mangle или nat, так что ни разу не логично сокращать, как ты предлагаешь.
NATить и манглить в таблице фильтр низя.
> NATить и манглить в таблице фильтр низя.На самом деле, если очень хочется - то можно :)
Я вот в таблице nat DROP'аю, например, чего делать, в общем-то, тоже "нельзя". Но можно и даже нужно, если хочется жестко залимитировать число сессий на кастомера, а в filter/mangle этого не сделать, потому что там идет куча пакетов с NOTRACK, и обрабатывать connlimit на каждый такой пакет - убийство. Матч по ctstate там - тоже нихреновый lookup. Поэтому был выбран вариант похерить все "нельзя", и сделать дроп там, где его сделать наиболее оптимально. NOTRACK в NAT не попадает, уже обработанные коннекты - тоже.
В нынешнем iptables со товарищи, при создании соответствующей таблицы автоматически создаются захардкоженный набор цепочек с жестко заданными именами (INPUT, OUTPUT, FORWARD, PREROUTING, POSTROUTING - набор зависит от конкретной таблицы), подсоединенные к одноименным хукам netfilter. В nftables ненужные цепочки можно просто не создавать, а созданные - называть так, как удобнее.
> В нынешнем iptables со товарищи, при создании соответствующей таблицы автоматически создаются
> захардкоженный набор цепочек с жестко заданными именами (INPUT, OUTPUT, FORWARD, PREROUTING,
> POSTROUTING - набор зависит от конкретной таблицы), подсоединенные к одноименным хукам
> netfilter. В nftables ненужные цепочки можно просто не создавать, а созданные
> - называть так, как удобнее.Не понял, и в iptables создаём какие угодно цепочки с любыми именами.
> Не понял, и в iptables создаём какие угодно цепочки с любыми именами.Как насчет цепочек, создаваемых автоматически?
Теперь наверное фильтры настраивать легко станет?
> Теперь наверное фильтры настраивать легко станет?Да примерно так же. Исторически сложилось, что легкость настройки фильтров зависит преимущественно от IQ настройщика. И это практически не зависит от ОС.
Я бы сказал более наглядно (если считать для конечного пользователя)
Вообще если первый критерий — простота и наглядность, то можно взять ufw.
> Вообще если первый критерий — простота и наглядность, то можно взять ufw.nftables примерно настолько же просто и наглядно, но при этом несравненно мощнее и гибче.
Все-таки, ufw - это всего лишь надстройка над iptables, и там гибкость принесена в жертву простоте.
> Вообще если первый критерий — простота и наглядность, то можно взять ...Cisco ASA за 300$ и не ипать моск.
>> Вообще если первый критерий — простота и наглядность, то можно взять ...
> Cisco ASA за 300$ и не ипать моск.Не! професиАналы негодуют.
только DIR-100, только хардкор.
> Cisco ASA за 300$ и не ипать моск.Ща придет sfdtudio и покажет тебеи как офис на 100 компов роутит 20-баксовая мыльница. И даже не дохнет при этом :).
>> Cisco ASA за 300$ и не ипать моск.
> Ща придет sfdtudio и покажет тебеи как офис на 100 компов роутит
> 20-баксовая мыльница. И даже не дохнет при этом :).Если внешка на 10 мбит, это неудивительно.
>> Cisco ASA за 300$ и не ипать моск.
> Ща придет sfdtudio и покажет тебеи как офис на 100 компов роутит
> 20-баксовая мыльница. И даже не дохнет при этом :).Я тоже люблю хардкор.
Можно будет с помощью этой штуки фильтровать трафик пользователя, цгруппы и приложения?
По UID и GID - можно. По cgroups и приложению - нет. AFAIK, Поттеринг пытался это пропихнуть, но его патч завернули по причине "поттеринг".
Потому что он опять пытался решать задачу, которая никому нафиг не сдалась. Фильтрация по приложениям, командным строкам, контрольным группам - бред собачий.
Было бы не плохо
Очень даже сдалась. Просто вы себе использование cgroups мыслите не вполне современно.
А сейчас это всё более и более легковесный контейнер, скорее даже чрезвычайно легковесная VM, хотя и формально некорректно так назвать, но с точки зрения юз-кейса - вполне.
Вот же ж. Единственный полезный телодвижений от Лёни, и на тебе.
А все остальные, которые вредные - радостно прогрессируют.
Что-то с этой планетой не так..
ipfwadm, ipchains, iptables, nftables... прям как в басне крылова "квартет"
>[оверквотинг удален]
> ct state established accept
>
> ct state related accept
>
> meta oif lo accept
>
> ct state new counter packets 0
> bytes 0 accept
> }
> }Что-то как-то слишком просто, нет, я понимаю что они сделали обязательым условием соблюдать количество отступов от края, и вообще весь такой синтаксис - это спасибо, теперь "не средние умы" не будут скучать, но обязательно нужно сделать так, чтобы перед применением правил весь этот код компилировался в бинарный файл, и в последующем использовался ядром, без возможности обратного восстановления конечно - ведь есть ручка и бумага, а если будет как раньше, когда можно было посмотреть правила по iptables -L -n - ну это ж совсем по детски, для ламеров так сказать.
И еще нужно сделать недокуметированную возможность использования символа ";" - реверс-инженеринг очень увлекательная задача.
> без возможности обратного восстановления конечноДурачок? nft list никто не отменял, вообще-то.
кстати вдруг кто споткнётся при сборке nftables вылетает ошибка и не генерятся доки/маны:openjade:/usr/share/sgml/docbook/stylesheet/dsssl/modular/print/dbbibl.dsl:704:4:E: flow object not accepted by port; only display flow objects accepted
Done.ставим openjade 1.3 и всё пучком (вылет идёт на openjade 1.4).
Юзерспейс там пока конечно ужасный... просто адовый. Эта зараза не хочет автоматически очищать таблицы, и даже flush всех цепочек не сбрасывает, приходится удалять по одному. Еще пока так и не понял - как вывести весь конфиг, а не конкретную таблицу.Бэкпортировал nftables в ядро CentOS 6.5, юзерспейс тоже адаптировал, сейчас немножко погоняю (filter уже проверил, NAT проверил), и выложу ссылку для желающих потестировать на "классике".
del
Для желающих nftables в CentOS'е - экспериментальный бэкпорт nftables в ядро CentOS 6.5.
круто-круто, только вот на сайте по любым другим ссылкам ошибка:This is b2evolution version 5.0.6-stable.
You cannot use the application before you finish configuration and installation.
Database schema is not up to date!
You have schema version «10200», but we would need «11110».
Please use the installer to finish your configuration/installation now.
> круто-круто, только вот на сайте по любым другим ссылкам ошибка:Уже нет.
> Похоже, что оно не поддерживает ipset, вместо этого вводя свой аналогичный велосипед.
> Конечно, ipset за несколько лет гораздо лучше вылизан по скорости и потреблению
> памяти, да еще имеет критически важную фичу, которой нет в ntf
> - таймауты.Мне вот вообще интересно, iptables умеет разные модули, в которых можно [было] написать что угодно, какие угодно проверки, причем единственное ограничение - это возможности языка С.
Теперь же получается будет ограничение - возможности виртуальной машины. И никаких модулей.
Мне как-то кажется, что оптимизировать проверки под С проще, чем под возможности виртуальной машины.
>Непосредственно логика фильтрации и специфичные для протоколов обработчики компилируются в
>байткод в пространстве пользователя, после чего данный байткод загружается в ядро при
>помощи интерфейса Netlink и выполняется в специальной виртуальной машине, напоминающей BPF
>(Berkeley Packet Filters).Какие цели проекта? Пока я считаю, что проект в целом - "хотим свой велосипед, круглое - не модно, хотим овальное и розовое".
> Какие цели проекта? Пока я считаю, что проект в целом - "хотим
> свой велосипед, круглое - не модно, хотим овальное и розовое".Чтобы далеко не ходить за примером, спрошу у уважаемой публики:
Как будет реализован модуль с функционалом, аналогичным модулю recent ?
> Как будет реализован модуль с функционалом, аналогичным модулю recent ?Есть подозрение, что это правильнее всего будет делать на базе set'ов.
>> Как будет реализован модуль с функционалом, аналогичным модулю recent ?
> Есть подозрение, что это правильнее всего будет делать на базе set'ов.как же, "на базе set-ов" сделать функционал, когда прилетевший пакет добавит IP в некий список, обновит timestamp записи, либо удалит этот IP оттуда?
>>> Как будет реализован модуль с функционалом, аналогичным модулю recent ?
>> Есть подозрение, что это правильнее всего будет делать на базе set'ов.
> как же, "на базе set-ов" сделать функционал, когда прилетевший пакет добавит IP
> в некий список, обновит timestamp записи, либо удалит этот IP оттуда?если написать разлаписто а не одним правилом то вроде-как взлетает -- т.е. xt_recent set'ами заменить в пhинципе реально.
> как же, "на базе set-ов" сделать функционал, когда прилетевший пакет добавит IP
> в некий список, обновит timestamp записи, либо удалит этот IP оттуда?Позволю себе пофантазировать (синтаксис пока не соблюдаю, но концепт должен быть понятен).
rule ip saddr 1.2.3.4 set add myrecent saddr timeout 60
rule ip daddr 2.3.4.5 set del myrecent saddr timeout 60
rule set myrecent saddr drop
> rule ip saddr 1.2.3.4 set add myrecent saddr timeout 60
> rule ip daddr 2.3.4.5 set del myrecent saddr timeout 60
> rule set myrecent saddr dropНасколько я понял, таймауты там не поддерживаются как класс. Можно оперировать только данными в реальном времени.
>> rule ip saddr 1.2.3.4 set add myrecent saddr timeout 60
>> rule ip daddr 2.3.4.5 set del myrecent saddr timeout 60
>> rule set myrecent saddr drop
> Насколько я понял, таймауты там не поддерживаются как класс.понял не правильно
+1 тоже интересует вопрос о работе старых модулей на новом iptables. Надеюсь, что модули вообще можно будет использовать !?
> +1 тоже интересует вопрос о работе старых модулей на новом iptables. Надеюсь,
> что модули вообще можно будет использовать !?Хитрость в том, что не менее половины "старых модулей" там просто не нужно, ибо реализуется штатно, без необходимости лезть в ядро. Максимум - добавление новых типов match в userspace.
с match модулями как-раз всё понятно, и эта виртуальная машина тут очень при чём. НО, что делать с target модулями, как сохранять состояния, работа с памятью?
> с match модулями как-раз всё понятно, и эта виртуальная машина тут очень
> при чём. НО, что делать с target модулями, как сохранять состояния,
> работа с памятью?С target-модулями ничего особо хорошего. С другой стороны - скорее всего поддержка xtables в итоге так и будет запилена в основные функции. Сейчас поддержка модулей xtables есть, но в userspace поддерживается только из xtables-iptables. Причем в ядре есть поддержка как match, так и target.
> с match модулями как-раз всё понятно, и эта виртуальная машина тут очень
> при чём. НО, что делать с target модулями, как сохранять состояния,
> работа с памятью?да вот не всё понятно. кроме данных непосредственно пакета есть куча разнообразных данных, доступных в ядерных структурах пакета / соединения.
> да вот не всё понятно. кроме данных непосредственно пакета есть куча разнообразных
> данных, доступных в ядерных структурах пакета / соединения.Эти данные так же доступны для BPF, как и сам пакет.
>> да вот не всё понятно. кроме данных непосредственно пакета есть куча разнообразных
>> данных, доступных в ядерных структурах пакета / соединения.
> Эти данные так же доступны для BPF, как и сам пакет.proof?
>> +1 тоже интересует вопрос о работе старых модулей на новом iptables. Надеюсь,
>> что модули вообще можно будет использовать !?
> Хитрость в том, что не менее половины "старых модулей" там просто не
> нужно, ибо реализуется штатно, без необходимости лезть в ядро. Максимум -
> добавление новых типов match в userspace.Хорошо, "не менее половины старых модулей". А что со второй половиной?
Допустим, надо сделать проверку значения realm (есть такой же модуль в iptables).
Как это "без необходимости лезть в ядро" реализовать?
Модули же иделогически не поддерживаются.
> Как это "без необходимости лезть в ядро" реализовать?
> Модули же иделогически не поддерживаются.И все-таки именно за этим не придётся лезть в ядро - уже реализовано. А при добавлении новой метаинформации в сетевой стек, логично, что и список будет пополняться.
@NFT_META_RTCLASSID: realm value of packet's route (skb->dst->tclassid)
> Хорошо, "не менее половины старых модулей". А что со второй половиной?
> Допустим, надо сделать проверку значения realm (есть такой же модуль в iptables).
> Как это "без необходимости лезть в ядро" реализовать?Метаданные пакета (входящий интерфейс, исходящий интерфейс, realm, mark, connmark и т.д.) тоже доступны для BPF.
>> Хорошо, "не менее половины старых модулей". А что со второй половиной?
>> Допустим, надо сделать проверку значения realm (есть такой же модуль в iptables).
>> Как это "без необходимости лезть в ядро" реализовать?
> Метаданные пакета (входящий интерфейс, исходящий интерфейс, realm, mark, connmark и т.д.)
> тоже доступны для BPF.vlan тэг? QinQ ? тожа нет?
Ну почитай же ты документацию. Они там библиотеку для этого сделали.
> Ну почитай же ты документацию. Они там библиотеку для этого сделали.где документация, я вот не нашел. мой гугол меня подводит?
где написано как расширять ?
где расаписан flow пакета
где описание взаимодействия с route'ингом
Честно говоря, прибываю в ужасе от нового синтаксиса правил.. Сделали более громоздкий и длинный синтаксис, променяв годами проверенный стандартный. Хорошо, что пока поддерживается оба варианта. Надеюсь, кто-нибудь напишет конвертер старого синтаксиса под новый, если они решат его выпилить в более новых версиях.
>Честно говоря, прибываю в ужасе от нового синтаксиса правил.. Сделали более громоздкий и
>длинный синтаксис, променяв годами проверенный стандартный.А всё потому, что там сидят кодеры, а не разработчики, и их цель - писать код, код, код, больше кода, давайте всё перепишем. Сделать _проект_ они неспособны.
Они это поделие уже почти 5 (пять) лет пишут. Какой результат - мы видим.
> А всё потому, что там сидят кодеры, а не разработчики, и их
> цель - писать код, код, код, больше кода, давайте всё перепишем.
> Сделать _проект_ они неспособны.Окей, идите на винду, там исключительно разработчики :)
> Они это пoделие уже почти 5 (пять) лет пишут. Какой результат -
> мы видим.С 2009 по 2013 разработкой nftables никто не занимался, были более срочные задачи.
> Честно говоря, прибываю в ужасе от нового синтаксиса правил.. Сделали более громоздкий
> и длинный синтаксис, променяв годами проверенный стандартный.Годами проверены только громоздкость, неудобство и запутанность "стандартного" синтаксиса.
Так что новый - вполне в тему.
>> Честно говоря, прибываю в ужасе от нового синтаксиса правил.. Сделали более громоздкий
>> и длинный синтаксис, променяв годами проверенный стандартный.
> Годами проверены только громоздкость, неудобство и запутанность "стандартного" синтаксиса.
> Так что новый - вполне в тему.ставь подпись неасилятор
Это поделие нахер не надо, пока не будет нормальной документации... :(add rule ip filter input meta dnat set tcp dport map { 80 => 192.168.1.100, 8888 => 192.168.1.101 }
This is typical port redirection that depends on the destination port.
Thus, if the destination port is 22, then the packet is dnatted to 192.168.1.100.
Ладно, тут хотя бы понятно, что очепятка, но вот такой шедевр тех. документации повергает в уныние:Prepending new rules
To prepend new rules through the insert command:
$ sudo nft insert rule filter output ip daddr 192.168.1.1 counter
:( :( :(
Это поделие надо по другой причине - оно практически унифицирует интерфейс, лазить в ядро за добавлением новых типов match будет практически не нужно. Плюс производительность - она должна быть серьезно выше, чем у iptables/xtables. userspace - десятое - разных userspace'ов под это можно налепить по вкусу и цвету.
>Плюс производительность - она должна быть серьезно выше, чем у iptables/xtablesПочему производительность у псевдокода виртуальной машины должна быть выше чем производительность скомпилированного С-кода, исполняющегося непосредственно CPU ?
>>Плюс производительность - она должна быть серьезно выше, чем у iptables/xtables
> Почему производительность у псевдокода виртуальной машины должна быть выше чем производительность
> скомпилированного С-кода, исполняющегося непосредственно CPU ?если говорить про match модули -- то можно предположить что
виртуальная машина проста как два пальца и накладных расходов минимум (ещё не смотрел)
текущий вариант представляет таблицу вызовов и это накладывает какие-то ограничения (с ограничениями не встречался)к тому-же самое смешное что не так давно почти на все архитектуры был запилен bpf-jit и кроме того google-пограмисты подарили нам всем xt_bpf, который практически решил проблемы написания match модулей.
modinfo xt_bpf
filename: /lib/modules/3.12-0.bpo.1-amd64/kernel/net/netfilter/xt_bpf.ko
alias: ip6t_bpf
alias: ipt_bpf
license: GPL
description: Xtables: BPF filter match
author: Willem de Bruijn <willemb@google.com>
depends: x_tables
intree: Y
vermagic: 3.12-0.bpo.1-amd64 SMP mod_unload modversionsдругое дело что подобный подход не применим на target, и возможно какое-то подобие виртуальной машины было-бы востребовано, но опять=же возникает вопрос почему было не расширить тот-самый bpf-jit функциями позволяющими работать с памятью и sk_buff и менять содержимое.
> другое дело что подобный подход не применим на target, и возможно какое-то
> подобие виртуальной машины было-бы востребовано, но опять=же возникает вопрос почему было
> не расширить тот-самый bpf-jit функциями позволяющими работать с памятью и sk_buff
> и менять содержимое.- Зачем всю функциональность запихивать в виртуальную машину?
- Зачем убирать возможность работы native-C модулей? Нужно унифицировать *-tables? Ну так унифицируйте. Не хватает возможности внятно конфигурировать это дело? Да, понятно, меняйте синтаксис правил.Рассмотрим примерчик:
table filter {
chain input {
type filter hook input priority 0;
}что такое "type filter hook input priority 0;" ? Это указание использовать "chain input" в стандартном хуке input - т.е. для пакетов входящих соединений.
Зачем тогда делать "table filter {}" c вложенным "chain input {}" ? Это чистый синтаксический сахар, который сделан "по образу и подобию iptables".
Т.е. читать этот пример надо так:table MY_FILTER_CHAINS {
chain MY_INPUT_CHAIN_NAME {
type filter hook input priority 0;
}и уже становится понятно, почему возникает "дублирование" слов filter и input в "type filter hook input".
Идем дальше.
"type filter hook input priority 0;"Про "type" всё чуть более ясно - они видимо предполагают делать на его основе проверку, чего можно пихать в chain, а чего нельзя, например запретить пихать nat-правила в filter.
Но его (type) можно было бы сделать опциональным, ведь фильтровать, например, ведь можно где угодно :-)А что мешало "hook" вынести за пределы chain {} ?
Например, что будет в случае:
table filter {
chain input {
type filter hook input priority 0;
}table otherfilter {
chain otherinput {
type filter hook input priority 0;
}да, умный юзерспейс должен будет обнаружить два приоритета 0...
а почему бы не сделать
hook filter.input {
priority 0 table MY_FILTER_CHAINS chain MY_INPUT_CHAIN_NAME;
}Тогда можно было бы
hook filter.input {
priority 0 table MY_FILTER_CHAINS chain MY_INPUT_CHAIN_NAME;
priority 5 table MY_FILTER_CHAINS chain MY_OTHER_CHAIN_NAME;
}hook filter.forward {
priority 0 table MY_FILTER_CHAINS chain MY_INPUT_CHAIN_NAME;
}А в некоем идеале слоя совместимости и так:
hook filter.forward {
priority 0 iptables;
}где iptables - имя "некоего native-C модуля".
=)
>[оверквотинг удален]
> }
> hook filter.forward {
> priority 0 table MY_FILTER_CHAINS chain MY_INPUT_CHAIN_NAME;
> }
> А в некоем идеале слоя совместимости и так:
> hook filter.forward {
> priority 0 iptables;
> }
> где iptables - имя "некоего native-C модуля".
> =)кратко ИМХО о userspace -- мне (я думаю многим другим кто уже привых) новый систаксис сильно не нравится. но во 1 -- это именно дело привычки, а во 2-ых -- предоставленный "слой совместимости" вполне может быдет более популярен, чем то что оне там напридумывали. В общем случае на userspace можно положить -- бсдшнеги моляться на ipfw шный синтаксис а фломастеры по прежнему разного вкуса.
>[оверквотинг удален]
>> hook filter.forward {
>> priority 0 table MY_FILTER_CHAINS chain MY_INPUT_CHAIN_NAME;
>> }
>> А в некоем идеале слоя совместимости и так:
>> hook filter.forward {
>> priority 0 iptables;
>> }
>> где iptables - имя "некоего native-C модуля".
>> =)
> но во 1 -- это именно дело привычкида это понятно.
> а во 2-ых -- предоставленный "слой совместимости" вполне
> может быдет более популярен, чем то что оне там напридумывали.ну если они _всю_ функциональность запихнут, то почти пофиг, в каком формате конфигурить, напрямую в новом или через "слой совместимости" ака "трансляторы".
Только вот с "запихнуть всю функциональность" будут нехилые проблемы.Да в общем, они _это_ пилили 5 (пять) лет, на "всю функциональность" уйдет еще лет 10 (десять). Жаль только, что это в апстрим приняли _в таком виде_.
Ну, "виртуальная машина" там - одно название. Суть та же таблица команд и вызовов, псевдокод. Разница только в том, что если раньше цепочку вызовов собирало само ядро, причем каждый match вызывался отдельно, выполняя, возможно, и ненужные совершенно операции, то теперь цепочка вызовов собирается userspace'ом, возможно, оптимизированно. Грубо говоря - все match'и разбили до элементарных примитивов.Пример: xt_iprange
if (info->flags & IPRANGE_SRC) { ... }
if (info->flags & IPRANGE_DST) { ... }Если я хочу матчить только по SRC - нафига мне каждый раз проверять флаг для SRC/DST? Это прекрасно может сделать юзерспейс, и оставить из этого только один матч. Мелочь, а приятно. А внутри еще и:
m ^= !!(info->flags & IPRANGE_SRC_INV);
Опять же, нафига? Проверка инвертированного диапазона. Юзерспейс прекрасно знал, что матч инвертирован, и мог сменить match на не-match еще до передачи в ядро. Зачем эти лишние операции на каждый пакет.
Еще один плюс - возможность хукать несколько хуков на разные участки прохождения пакета (разным софтом, к примеру, с разными приоритетами). Или исключать хуки совсем. Если нам не нужно фильтровать output, к примеру - зачем этот хук? В iptables он есть, и занимает время. Если нам не нужен nat на PREROUTING и OUTPUT - этих хуков тоже не будет.
В принципе, определенная оптимизация имеет место быть. Операции "на каждый пакет" заменяются разовыми при генерации псевдокода.
> В принципе, определенная оптимизация имеет место быть. Операции "на каждый пакет" заменяются
> разовыми при генерации псевдокода.вот именно что по сути это state machine "компилируемая" для ядра в юзерспейсе. и конечно сдесь есть здравое звено. чего только стоит отсутствие парсинга аргументов в ядре...
НО минус то тоже огромный -- КАК это расширять?
>[оверквотинг удален]
> description: Xtables: BPF filter match
> author: Willem de Bruijn
> <willemb@google.com>
> depends: x_tables
> intree: Y
> vermagic: 3.12-0.bpo.1-amd64 SMP mod_unload modversions
> другое дело что подобный подход не применим на target, и возможно какое-то
> подобие виртуальной машины было-бы востребовано, но опять=же возникает вопрос почему было
> не расширить тот-самый bpf-jit функциями позволяющими работать с памятью и sk_buff
> и менять содержимое.ИМХО McHardy на этот раз сильно перемудрил, как таковой виртуальной машины я там не разглядел - код конечно вполне приличный, но как только оно начнёт обростать фичами начнёться беда, как его нормальным способом расширять я пока не понял.
>как его нормальным способом расширять я пока не понял.Вот-вот. Золотые слова.
А с таким подходом теперь запилят нормальный юзерспейсный фаервол? С показом кто куда идет, счетчиком трафика по приложениям и т.д....
> А с таким подходом теперь запилят нормальный юзерспейсный фаервол? С показом кто
> куда идет, счетчиком трафика по приложениям и т.д....Оно совершенно для другого. Хотите считать трафик по приложениям - настраивайте selinux, и матчите по secmark.
> А с таким подходом теперь запилят нормальный юзерспейсный фаервол?Нет. Это никому не нужно. (Никому из разработчиков, разумеется)
Ответы на некоторые вопросы:
https://home.regit.org/wp-content/uploads/2013/09/2013_kerne...