так legacy

Устаревшим утилитам будет присвоен постфикс "-legacy".

Это что ?

Это что ?

Это просто то, что они будут работать с устаревшей реализацией фильтров пространства ядра.

прсто многие до сих пор ошибочно полагают что системд был заменой инита а потом разросся, но он с самого начала предполагался как замена сразу всего что связано с запуском, работой и анализом состояния сервисов и являлся jack-of-all-trades системным мэнэджэром... а потом разросся..

cgroups давно отменили?

1. да вроде даже обросший костыллями иптейблс фильтрует в одном месте.. основной профит тут отбросить костыли дублирующие код по 10 раз..
2. это всё уже реализовали и добавили и стабильно внедрили в году 2015м когда iptables-compat появился..
3. опять же фильтрация происходит в одном месте порой даже не в ядре потому что есть сетевые карты умеющие обрабатывать хардварно правила в bpf. добавить тут можно работу через вм eBPF которая производительней чем та что в nft..

изначально речь была не о том, что нельзя, а о том, что неудобно.

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

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

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

Сами себе же противоречите. Если фильтрация может выполняться в каких-то случаях сетевой картой, то уже как минимум она будет вестись в двух местах - в сетевухе и в ядре. Так как в любом случае сетевуха не сможет реализовывать все возможные типы фильтрации, то что-то еще должно будет делать ядро. Конечно, такая сетевуха может здорово разгрузить ядро, никто не спорит. Только это все еще более усложняет фильтрацию. А что, если весь набор правил bpf в сетевуху не поместится - там же не 4 гига памяти.

jack-of-all-trades системным мэнэджэром... а потом разросся..

... однако за время пути собака могла подрасти (с) Маршак

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

так ладно давай смотреть на это как iptables - 8 разных инспекторов с кучей разрозненных списков каждый из которых проверяет отдельно

nftables одна инспекция которая проверяет по оптимизированному списку

правила bpf это весьма компактный байткод.

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

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

Ни тот ни другой :)

Это категория софта, для которой критична обратная совместимость. А чтобы быть обратно совместимым с systemd, надо запилить большую часть systemd... Так что всё, поезд ушёл.

Различные атрибуты и свойства сетевого пакета возникают на разных стадиях его обработки.

помоему у пакета сразу же готовая структура данных, дальше просто ссылка на него кидается куда-то, где с ним хотят пообщаться плотнее.
и вообще пакет — он пакет Шрёдингера, он уже определён при получении\отправлении, просто что-то может его менять в процессе.
а улучшено может быть всё что угодно, достаточно просто не быть iptables и это сразу улучшение.

Как ты до маршрутизации узнаешь, какой выходной интерфейс у пакета? И вообще, до маршрутизации в некоторых случаях не известен адрес назначения. Это так, к примеру.

https://github.com/torvalds/linux/blob/master/include/linux/skbuff.h#L590

Что ты мне хотел этим сказать?

расширшу.
хочешь сменить\добавить интерфейс, меняешь в @mac_header, а хочешь что-то с айпишниками сделать — то в @network_header
а дальше, кому надо, разберётся как отправить эту структуру.

Так давно уже перешли на firewalld.

Так этож вроди как надстройка над iptables.

А пример можно ? И лучше сразу не про устаревший ipv4.

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

Пля, начитался там выше, сам стал язык корёжить.

Да блин, для серверов все это, для серверов, для больших дядей из Netflix-а и подобных, которым надо фильтровать эти пакеты на скоростях которые iptables-ам недоступны. На нас маленьких десктопных юзеров им срать с огромной колокольни.

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

А ему пофиг: «кому надо, разберётся как отправить эту структуру» Вот такие «спецы» с пеной у рта «топят» за всякие системды и прочие вяленды.

Да блин, для серверов все это, для серверов, для больших дядей из Netflix-а и подобных, которым надо фильтровать эти пакеты на скоростях которые iptables-ам недоступны. На нас маленьких десктопных юзеров им срать с огромной колокольни.

Да, похоже, что обратная сторона популярности начинает все больше и больше оказывать негативное влияние на Линукс. Парадокс. Низкая популярность системы - будешь мучиться, как минимум, с отсутствием драйверов под более менее свежее железо. Большая популярность системы - либо набегут всякие уродцы, которые будут своими глупыми поделками превращать её в какой-нибудь Виндовс, или же крупные коммерческие компании начнут рвать её на части, лочить для своих нужд, корёжить до неузнаваемости опять же для своих нужд.

С iptables, мне по крайней мере, еще не все понятно, но остальное не внушает оптимизма.

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

столько лет тут топил за системды и вяленды, притворяясь главным SRE гугула, а тут пришёл и разрушил мою легенду.
ну нафига?

Harsha Sharma, 18 years old from India, gave a talk explaining her work on nftables to the rest of Netfilter contributors

Ну всё, приехали

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

Я то как раз не могу. Поэтому и спрашиваю здесь, как это сумели сделать нынешние разрабы, которые хотят выкинуть iptables. И не один я интересуюсь.

А вот вы тут о чем, речь ведете - не могу понять. Сначала зачем-то постите здесь структуру sk_buff. Затем утверждаете, что коли в структуре описаны нужные поля, то тот, кому надо сам разберется, что с пакетом делать. Теперь, вдруг удивляетесь, как можно «через тыщу слоёв абстракции по одному вопросу на лоре сказать куда пойдёт пакет»? Сами с собой что-ли разговариваете?

Это норма. В случае с Дениской Поповым операционную систему тоже «по достоинству оценили все ведущие специалисты». Чем индусы хуже?

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

Ведь, условно говоря, в ядре нет какого-то одного места, где сетевой пакет был бы полностью определен.

это кто написал?

Сначала зачем-то постите здесь структуру sk_buff

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

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

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

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

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

Я признаю, что моя фраза про то, что в ядре нет какого-то одного места, где сетевой пакет был бы полностью определен несколько неточна и может быть трактована по разному. Но все-таки думаю, что те, кто понимают, как устроен сетевой стек ядра, должны были понять, что речь именно о том, что именно значения полей структуры sk_buff в общем случае выставляются по мере следования пакета по сетевому стеку. В какой-то точке все значения будут определены (или почти все). Только, во-первых, у разных пакетов эта точка может находиться в разных местах. А во-вторых, разумно некоторые пакеты отфильтровывать до того, как они дойдут до этой точки, если уже ясно, что они должны быть сброшены, например.

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

Я то тут при чем? С какой стати меня это должно волновать? Меня интересует, как при текущей реализации сетевого стека разработчики нового поколения сетевого фильтра сумели реализовать фильтрацию в одном месте. Об этом по крайней мере явно, или неявно заявляется. Или это писатели новостей все перевирают (криво излагают)? Или это разработчики все врут? А на самом деле внутри все осталось также, только язык написания правил поменялся? Зачем тогда это делается - заняться нечем, что ли?

Ещё раз. До того, как пакет прошёл маршрутизацию, ты не можешь знать, через какой интерфейс выйдет твой пакет, так как ещё не известен маршрут.

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

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

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

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

тогда поговорим.

Сюрприз, сюрприз: IP_PRE_ROUTING IP_POST_ROUTING IP_LOCAL_INPUT IP_LOCAL_OUTPUT IP_FORWARD

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

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

Да блин, для серверов все это, для серверов, для

Не понял, что тебя так взбудоражило.

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

По существу есть, что ответить, или дальше будете волынку тянуть?

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

И? Как до маршрутизации ты узнаешь выходной интерфейс?

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

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

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

да хватит уже вихлять то а?
ещё с сайтом нетфильтра поспорь нахер.

netfilter is a set of hooks inside the Linux kernel that allows kernel modules to register callback functions with the network stack.

какой модуль загрузишь дёргать хуки — то и получишь.
ничего не загрузишь — ничего не получишь.
цепочки млять стека.

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

Указанные хуки вызываются сетевым стеком ядра в разных точках на маршруте следования пакета? Все пакеты проходят все эти точки на своем маршруте обработки в сетевом стеке ядра? Значения полей sk_buff заполняются/модифицируются по ходу прохождения пакета по своему маршруту в сетевом стеке ядра?

Если ответы будут: да, нет, да, то собственно главный вопрос, который меня интересует: как при такой архитектуре ядра разработчики в новом поколении сетевого фильтра смогли свести весь функционал по фильтрации в одной точке?

Не знаете? Так и скажите. Не хотите отвечать? Так и скажите.

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

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

свести весь функционал по фильтрации в одной точке

и вот ещё, если ты говоришь про nftables — это это для тебя весь функционал в одном приложении\«точке», а не для пакета, пакету вообще фиолетово, это просто данные.
у тебя теперь одна програмулина взамен 100500 фигни которую накодили за 20 лет.

Ну пусть переводят, давно пора.

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

Транслятор полезная штука, хотя улчше сразу вникать в новые команды.