iptables ВСЁ

Ну вот мой банальный конфиг с шлюза: http://ix.io/1jMi

я смотрю, хотя бы оставили старую логику прохождения пакета по дефолтным цепочкам ядра (INPUT,FORWARD,OUTPUT, PRE*,POST*)

я смотрю, хотя бы оставили старую логику прохождения пакета по дефолтным цепочкам ядра

Нет, в nftables нет дефолтных цепочек.

Как там училка? )

Нет, в nftables нет дефолтных цепочек.

type filter hook input - ну теперь просто это выделили в понятие hook и ты должен вручную создать для него цепочку input. логика прохождения пакета та же.

ес-но, если ты родился вместе с json, то скобочки или javascript-style будет ближе...

Ну какой к чёрту жсон?

Логика прохождения пакета определяется подсистемой Netfilter. Netfilter никуда не делся. nftables — это другой интерфейс к тому же самому ядерному механизму.

а, ок. я думал, это уже выкатывают bpf. если бы меня спросили, я бы сказал, что менять (или добавлять) юзерский интерфейс надо только с новой kernel-подсистемой.

а, ок. я думал, это уже выкатывают bpf.

Но bpfilter тоже будет втыкаться в Netfilter.

Кстати, что самое смешное, ребята из bpfilter как раз предлагают оставить старый iptables-like интерфейс (правда, не помню, речь только про CLI или про ABI тоже).

Ну какой к чёрту жсон?

nft add rule ip filter input ip protocol vmap { tcp : jump tcp-chain, udp : jump udp-chain, icmp : jump icmp-chain }

пфф... я понимаю, что не быть троллем на лоре - значит потерять лицо, но давайте уж в маразм не скатываться. если список для vmap не представлен чем-то очень-очень похожим на json объект, я готов съесть твою шляпу.

Ну если для тебя любые фигурные скобочки ­— это жсон...

:) ммм, вот оно что) хорошо, что netfilter остается и не все у меня в голове совсем устарело)

Понимаешь, дело не в жсоне и не в скобочках, а в том, что в iptables такой структуры данных, как set или map, вообще нет.

Дело, опять же, не в скобочках, а в том, что синтаксис iptables(8), если его можно так назвать, вынуждает тебя в каждой команде повторяться, что, куда, с какой таблицей и цепочкой ты хочешь сделать. Синтаксис nft гораздо удобнее (в том числе за счёт того, что там настоящая КЗ грамматика, а не «давайте просто каждую строчку запихнём в getopt и скажем, что это конфиг»). Ты можешь вкладывать конструкции друг в друга, указывать несколько действий в одной строчке, не писать -t mangle -A FORWARD двадцать раз подряд и так далее. А то, что там скобочки — дело двадцатое. Или, по твоему, Си, например — это тоже «жсоноподобное баловство хипстоты и удел миллениалов»?

nftables свои модули, лучше чем у iptables, потому что умеют эффективнее по заверениям разработчиков.

пока всё выглядит примерно так:
- nft лучше ipt.
-чем лучше?
- чем ipt!

Ты можешь вкладывать конструкции друг в друга, указывать несколько действий в одной строчке

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

вот чем хорош iptables - у тебя куча правил и ты любое можешь удалить. или добавить. а как это выглядит в nftables?

вот чем хорош iptables - у тебя куча правил и ты любое можешь удалить. или добавить. а как это выглядит в nftables?

Да то же самое всё - любое вложенное во все эти древовидные штуки правило удаляется типа nft delete rule filter input ip saddr 1.2.3.4 drop

Ну и добавлять их так же можно, по одному, указывая «путь» вида table_name chain_name rule_definition а не писать простынки.

Можно и по номеру, nft list -a выдаст номера правил.

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

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

почему ты считаешь, что чтобы быть лучше обязательно должно быть серьёзное обоснование, с какими-то новыми фичами, эффективными на 300% алгоритмами и прочим, прочим?
для меня, чтобы быть лучше — достаточно не быть iptables.
например, мне нравится ipfw именно в плане UX. лет ему тоже не мало, но почему-то не забили болт на на интерфейс и опыт пользователя при написании конфигов, в отличии от.
достаточно не быть iptables и ты сразу становишься лучше.

с какими-то новыми фичами, эффективными на 300% алгоритмами и прочим, прочим

о каких «новых фичах» и 300% речь, если это всё тот же netfilter? чота я не понимаю логику этих хипстеров.

тот же netfilter, но, теже кучи айпишников, ведь не в него грузится, а как-то хранится в структурах модулей, по ним делается поиск и всякое такое, типа принятие решения. в nftables заявляют лучшую производительность. «Faster packet classification through enhanced generic set and map infrastructure.»

типа принятие решения

какого решения? где? единственное, что реально фильтрует - это netfilter. остальное всё лишь способы залить в него нужные правила. эктеншны работают медленее.

чота я решила почитать про архитектуру этого nft и некоторые вещи прямо-таки пугают:

Move most rule handling to userspace. ... Instead, the nft tool would ask the kernel to load a number of bytes starting at a particular offset.

https://developers.redhat.com/blog/2016/10/28/what-comes-after-iptables-its-s...

и это они на каждый пакет дёргают передачу из кернела в юзерспейс? нет, есть варианты, когда весь стек обрабатывается в юзерспейсе. но когда на каждый пакет (который нужно пропускать или отбрасывать) идут запросы данных в кернел - это как-то кхм.

или я что-то не понимаю? в общем, надо смотреть код. что там наворотили.

надо смотреть код

будешь? тогда запишим тебя в гуру этого дела и будем кастовать.

netfilter — это механизм. Дай пакет, выбрось пакет, пометь пакет, заNAT'ь пакет. Всё. iptables, nftables, bpfilter — это программируемая логика. Если хочешь так считать, три разных виртуальных машины, исполняющие код, который написал админ. Производительность работы файрволла зависит в первую очередь от них.

Странно, что тебе приходится всё это объяснять; судя по интенсивности твоих криков в ядерных тредах, ты вроде как должна знать внутреннюю архитектуру Linux как свои пять пальцев.

единственное, что реально фильтрует - это netfilter. остальное всё лишь способы залить в него нужные правила.

Это неправда (выделение моё). Смотри выше.

и это они на каждый пакет дёргают передачу из кернела в юзерспейс?

Нет.

или я что-то не понимаю?

Скорее так.

Дай пакет, выбрось пакет, пометь пакет, заNAT'ь пакет. Всё.

а что ещё нужно? причём ты когда ядро собираешь, ты туда можешь включать те или иные фичи (и это модули ядра). а можешь не включать, если тебе какие-то протоколы не нужны нафиг или там какое-нибудь отслеживание коннектов - можешь не юзать.

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

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

Дай пакет, выбрось пакет, пометь пакет, заNAT'ь пакет. Всё.

а что ещё нужно?

Вот ты действительно не понимаешь, что я написал в том сообщении?

а тут предлагают вундервафлю в юзерспейсе, которая будет на каждый пакет дёргать данные из кернела в юзерспейс

ты можешь писать расширения. но они будут в кернеле. а тут предлагают расширения в юзерспейсе

И это снова неправда.

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

И это снова неправда.

что неправда? чуть ли не самая жирная часть ядра - это обработчики сетевых протоколов и разных возможностей для фильтрации. ты можешь написать свой. я даже как-то этим баловалась.

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

понимаешь, есть два пути оптимизации скорости: либо засунуть всё в ядро (монолитный кернел) и тогда будет быстро, потому что приоритеты и вот это всё. либо всё полностью вытащить из кернела и прямо в юзерспейсе весь TCP/IP стек парсить и тогда не будет переходов между кернелом и юзерспейсом. я изучала оба подхода. мне юзерспейсный вариант даже больше нравится, потому что он устойчивее. но когда дёргают пакеты из кернела, а обработчик предлагают делать в юзерспейсе - это какая-то лажа. и чем развесистее юзерспейсный обработчик - тем она хуже.

что неправда?

Неправда то, что я процитировал.

Слушай, ну ты либо прикидываешься, либо совсем недалёкая. С какого места разжевать нужно?

обработчик предлагают делать в юзерспейсе

По ходу, обработчик не в юзерспейсе

With the new nftables virtual machine approach, you will most likely not need such upgrade to support a new protocol. A relatively simple nft userspace software update should be enough to support new protocols.

Там какая-то виртуальная машина (в ядре), в которую из юзерспейса будут загружаться эти протоколы, обработчики, я так понимаю, типа байт-кода для жабы

А если создать правила через nft и сделать iptables-save(или наоборот), что будет?

Понимаешь, дело

Понимаю, чего тут не понять. Предложили более универсальный синтаксис, чтобы поглотить ipset. На данный момент развития it индустрии - json наиболее любимое (не мной) решение. В примере не только скобочки, а такое же разделение элементов.

p.s.

Скобочки, запятые и пр. я не люблю за то, что в bash cmd и bash скриптах их приходится экранировать. А bash скрипты - мой очень привычный инструмент.

p.p.s.

Вот только русских слов типа КЗ не надо. Это мне как ЭВМ режет ухо и нифига не понятно. Давайте пользоваться терминами от лидеров индустрии.

по поводу производительности. встреваю в ваш разговор с Iron_Bug с тестами (а сам заодно и синтаксис сравню):

https://developers.redhat.com/blog/2017/04/11/benchmarking-nftables/

цитирую выборочно:

As before, the intuitive nftables setup performs worse than iptables, though this time the margin is much bigger.

В данном сравнении разница в производительности определяется разницей между in-kernel системами: netfilter vs modified netfilter (new nftables virtual machine subsystem).

nftables — это другой интерфейс к тому же самому ядерному механизму.

хмм... я тебя не так понял. я думал, ты имеешь ввиду другой _юзерский_ интерфейс: новая утилита, новый json-like синстаксис. однако это также и новый фреймвор для классификации пакетов в виде простой вируальной машины (типа ява-машины) внутри ядра. А логика прохождения действительно сохраняется.

какого решения? где? единственное, что реально фильтрует - это netfilter.

выходит, что nftables заменяет (или опционально добавляет?) парсер пакетов внутри netfilter. и вот тут начинаются споры о производительности и сравнения.

и это они на каждый пакет дёргают передачу из кернела в юзерспейс?

слава богу нет. такая опция есть, но только для особых случаев.

три разных виртуальных машины, исполняющие код, который написал админ

я сразу говорю, что придираюсь к словам, но на самом деле только две из них правильно называть виртуальными машинами. логично, что любой админский конфиг преобразуется в машинную форму, но старый классификатор (не nftables, не bpf) цитирую «has protocol awareness built-in so deeply into the logic that the code has had to be replicated four times» (https://lwn.net/Articles/564095/)

Не пробовал. Но по-идее должно как-то работать, не зря же iptables-nft-save сделали.

Вот только русских слов типа КЗ не надо. Это мне как ЭВМ режет ухо и нифига не понятно. Давайте пользоваться терминами от лидеров индустрии.

CS, так понятнее?

я думал, ты имеешь ввиду другой _юзерский_ интерфейс: новая утилита, новый json-like синстаксис. однако это также и новый фреймвор для классификации пакетов в виде простой вируальной машины (типа ява-машины) внутри ядра. А логика прохождения действительно сохраняется.

Да, совершенно верно. Новый интерфейс, новый классификатор, но тот же самый Netfilter.

я сразу говорю, что придираюсь к словам, но на самом деле только две из них правильно называть виртуальными машинами. логично, что любой админский конфиг преобразуется в машинную форму, но старый классификатор (не nftables, не bpf) цитирую «has protocol awareness built-in so deeply into the logic that the code has had to be replicated four times»

Ну тут можно поспорить. В любом случае ты пишешь список действий, который компилируется в некий байт-код и исполняется ядром по порядку для каждого пакета. Только в случае iptables набор команд этой машины очень-очень высокоуровневый.

Ну тут можно поспорить.

Основываясь на предыдущем опыте, я не сомневаюсь, что ты готов спорить с кем угодно.:) Смысла в этом мало (как и в прошлый раз), потому что опять же весовые разные. Jonathan Corbet - и кернел девелопер со стажем, и редактор lwn.

ах да, и я забыл упомянуть в этом треде systemd. на днях journald у меня просто задыхался на ноуте(!), отъедая 50% одного ядра. ну а ты продолжай спорить, конечно.:)

Основываясь на предыдущем опыте, я не сомневаюсь, что ты готов спорить с кем угодно.:)

Конечно. А что ещё делать, если большинство людей несут херню?

Смысла в этом мало (как и в прошлый раз), потому что опять же весовые разные. Jonathan Corbet - и кернел девелопер со стажем, и редактор lwn.

И снова глупая апелляция к авторитету. Скучно.

Скучно

ну прости) я-то не за спорами сюда прихожу. а спорщика ты на лоре найдешь. в спорщиках здесь недостатка нет)