Семейство утилит iptables переведут с ip_tables на BPF

Пацаны, объясните плз, никак не могу понять!!!

Вот есть файрвол netfilter - это понятно!

Есть для него 2 морды:

iptables - древнее как гомно мамонта и деприкейтед.

nftables - новой и прогрессивное, за ним будущее.

ufw - это консаольная морда над мордой iptables (от разрабов ubuntu), типа чтоб было еще легче настраивать файрвол, да??

А КАКОЕ МЕСТО здесь заниммает firewalld??? Я никак не могу понять - что он такое?? ВСЕ ПЫТАЮТСЯ ЗАМОРОЧИТЬ МНЕ ГОЛОВУ.

На обычной вики пишут:

firewalld is a firewall management tool for Linux operating systems. It provides firewall features by acting as a front-end for the Linux kernel's netfilter framework, as does iptables.

Т.е. является мордой для netfilter, как и iptables.

Затем пишут это:

firewalld's command syntax is similar to but more verbose than other iptables front-ends like Ubuntu's Uncomplicated Firewall (ufw).

Называя firewalld мордой над iptables (по аналогии с ufw).

В официальной документации вообще написано, что он может быть использован со множеством морд к netfilter - в т.е. с nftables. Вот на схеме это даже есть.

https://firewalld.org/documentation/concepts.html

НО ГДЕ ПРАВДА ВООБЩЕ?

Зашел и посмотрел зависимости - жестко зависит только от iptables.

Зависимости: iptables

Короче НИХРЕНА НЕПОНЯТНО, что такое этот firewalld? Опять Поттеринг морочить головы людям??

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

А с этим здесь кто-то спорил?

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

А с этим здесь кто-то спорил?

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

Разумеется, пока на хуки не зарегистрированы какие-либо функции, то и вызываться ничего не будет. Но макросы типа NF_HOOK(NFPROTO_IPV4, NF_INET_PRE_ROUTING, net, NULL, skb, dev, NULL, ip_rcv_finish), надеюсь все еще есть в ядре? И находятся они таки в коде в разных местах?

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

Да успокойтесь вы, коли для вас это прям так принципиально - никто и не спорит, что экземпляр структуры типа sk_buff располагается все время по одному и тому же адресу. Вам метафора: путь движения пакета по сетевому стеку не знакома, что ли? Уже даже боюсь спросить, а понятие пути исполнения кода программы знакомо?

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

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

все эти твои «точки на маршруте» ничего более чем условности и абстракции, сегодня они одни, вчера другие, завтра третьи.

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

Вообще диалог получается в духе: - Какого цвета яблоко лежит на столе? - Оно круглое и твердое. - А какого оно цвета? - Что ты виляешь, оно точно круглое и твердое. - Ну а цвет то у него какой? - Что ты виляешь? Ты хоть знаешь, что такое круглое и твердое? - Да, ладно, оно круглое и твердое. Но какой же у него цвет? - Да когда же ты наконец поймешь, что яблоко лежит на столе и оно круглое и твердое.

у тебя теперь одна програмулина взамен 100500 фигни которую накодили за 20 лет.

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

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

И как же это делается «Можно или нельзя пишутся на основании данных из пакета», если в пакете этих данных до маршрутизации еще нет?

firewalld — тупо надстройка на iptables, а-ля ufw. Ещё man direct rules, когда даже с firewalld в более-менее сложных юзкейсах требуется писать напрямую правила iptables.

Да ты просто открыл Америку. Мы то, идиоты, думали, что ядро на каждый чих копирует пакет в памяти, а он, оказывается, на месте лежит. Вот так неожиданность. Ты ещё скажи, что в HTB нет реального такого железного оцинкованного ведра с токенами, вот умора будет.

firewalld — тупо надстройка на iptables, а-ля ufw.

А что круче в этом плане по функциональности - ufw или firewalld?

И таки непонятно, в документации сказано оно еще и надстройка над nftables, и еще какой-то фигней... но требует из зависимостей именно iptables.

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

ЗЫ:

фиревалл

Facepalm :-)

И то, и то ненужно, IMHO. За функциональностью — к полноценному решению, iptables или nftables. А единственный смысл этих поделок — чтобы порты условной самбы двумя командами открыть и больше не думать. firewalld поставляется в CentOS, Fedora и пр., UFW — больше вроде на Ubuntu распространён.

надстройка над nftables, и еще какой-то фигней

Скорее всего, пока только над iptables, а остальное в планах.

И то, и то ненужно, IMHO. За функциональностью — к полноценному решению, iptables или nftables.

Так и знал! Спасибо, что укрепил мою уверенность, брат анон! Мутные поделия долой. :)

Реализуйте, пожалуйста, на nftables правило

iptables -I INPUT -p tcp --sport 80 -m string --string "Location: http://warning.bigprovider.ru" --algo bm -j DROP

А с этим здесь кто-то спорил?

да, ты.
сначала говорил о «разных цепочках сетевого стека ядра» принимая netfilter за IP имплементацию.
прикручивал туда фильтрацию несколько раз, считая, что это нечто единое. netfilter и IP. а на деле оказалось, что это две разные штуки, и теперь ты начинаешь «с этим здесь кто-то спорил?».

Вам метафора: путь движения пакета по сетевому стеку не знакома, что ли?

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

Остальные способы, боюсь, слишком специфичны.

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

Ну это вообще заявление ни о чем. Завтра вообще может быть что угодно.
Вообще диалог получается в духе: - Какого цвета яблоко лежит на столе? - Оно круглое и твердое.

нет.
когда ты рассуждаешь по «пакете-путешественнике», он не лежит на столе и не яблоко, он может быть в ядре, через OVS и управляться через Ryu по OpenFlow и в этот момент знания о нетфильтре чуть менее чем нерелевантны.
а может быть где-то в нейтроне от openstack и тогда вообще никто (наверное даже хипстеры разработчики) не знает что там с ним происходит, потому что эта жопа какая-то. лучше вообще даже не знать. пусть это будут абстракции.
вдруг он в ЯРфильтре от Дениски, через ижицу путешествует. пофигу на нетфильтр опять.

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

и ещё, в свете вышесказанного.

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

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

Ну, давай же. Пока что ты не ответил.

Ну ладно давай так, я наверное запутался в топике уже. Зачем мне знать исходящий интерфейс ?

P.S. Я всегда знал что такое route и что такое netfilter и если кто то думает что netfilter выполняет функции маршрутизации типа ( prerouting ) то он сам ССЗБ. Встречал даже таких которые думают что таблица маршрутизации всего одна ;)

Ну ладно давай так, я наверное запутался в топике уже. Зачем мне знать исходящий интерфейс ?

Например, чтобы на одном из интерфейсов сделать snat. Или не пустить определённые пакеты. Hint: одна и та же сеть может быть доступна сначала через один интерфейс, а через минуту уже через другой. И на разных интерфейсах могут быть разные условия.

P.S. Я всегда знал что такое route и что такое netfilter

Топик показывает, что это не так.

если кто то думает что netfilter выполняет функции маршрутизации типа ( prerouting ) то он сам ССЗБ. Встречал даже таких которые думают что таблица маршрутизации всего одна ;)

Есть люди, которые системный блок процессором называют, и что? Как это относится к теме?

Топик показывает, что это не так.

Короче я запутался. Я рулю серверами где интерфейсы объединены в бонды те разделены на кучу вланов и на них висят бриджи (для квм). До 50 сетей с одного порта ... все логично просто и понятно. что было и с ipchains и iptables и сейчас с firewalld.

Можно конечно наплодить сущностей и самому потом запутаться но я стороник дзена пистона.

Сомнительно. Как можно рулить чем-то, связанным с сетью на linux, и не знать packet flow.

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

Ну это нормально.

Мое «не знание» что куда движется тем не менее помогает строить эффективные и не тормозные сети

Не ври, если это так, твои сети не сложнее обычной домашней сети. Дай догадаюсь - ты тот самый приходящий настройки ТПЛинков и обжимальщик витой пары?

в отличие от админов локал-хостов :)

Не угадал :-)

Которые даже не могут объяснить зачем нужно знать исходящий интерфейс

Тебя носом в пост ткнуть?

хотя какой будет исходящий и так видно по таблицам маршрутизации

Ясен пень. Я тебе об этом и говорю. Или ты не умеешь читать? Я тебе говорил, что ДО маршрутизации исходящий интерфейс не известен.

ЗЫ: Посмотри уже на схему, и не позорься больше.

OMG, я тут твои темы почитал, это просто песня. Защита ip6

И этот человек считает себя компетентным.

А разве через nftables уже так можно?

Ну и что ? Я например вообще не считаю ВАС понимающем в вопросе или не понимающем мне это как то фиолетово. Просто ВЫ толком не объяснили зачем вам нужно знать исходящие интерфейсы ...

Ну это ваше право.

Сам не знаю :( Жаль, если инструмент, позиционируемый как полная замена iptables, не будет соответствовать iptables по функциональности.

Семейство утилит iptables переведут с ip_tables на BPF (комментарий)

Доступно это вообще то вход а не выход.

OMG. SNAT всегда делается в POSTROUTING. Представь, что у тебя надо сделать snat на аплинке. Тебе для этого надо знать, из какого интерфейса пакет выходит. Очень странно, что мне приходится объяснять, как делать NAT человеку, который считает себя специалистом по сетям. Впрочем, свою некомпетентность ты давно доказал.

И что без правил --to-source ?

P.S. Вы не волнуйтесь пожалуйста, еще немного, если вы не сдадитесь конечно, я научу ВАС применять ВАШИ же знания на практике. Нужно не тупо делать а просто немного подумать ...

Почему без --to-source? Ты думать вообще не способен? SNAT надо сделать на конкретном исходящей интерфейсе. Расскажи мне, как ты это будешь делать ДО роутинга. Вот просто приведи пример рабочего правила.

Я, в свою очередь приведу пример, как это делается в POSTROUTING:

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 1.2.3.4

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

ip_tables: SNAT target: used from hooks PREROUTING, but only usable from INPUT/POSTROUTING

ЗЫ: мне, честно говоря, абсолютно не интересно спорить с тобой насчёт таких элементарных вещей. Почитай мануалы от iptables, есть даже на русском https://ru.wikibooks.org/wiki/Iptables

Да я не про это, просто силюсь понять когда оно не будет совпадать. ip addr | grep eth0

Допустим, ты делаешь SNAT на адрес, который уже находится на исходящем интерфейсе. Приведи пример, как ты это сделаешь до роутинга. А исходящий интерфейс тебе надо знать, потому что только на нём тебе нужен SNAT, а на других не надо. Ты никогда не настраивал NAT?

PS: Ты можешь заменить SNAT на MASQUERADE, в данном случае это сути не меняет.

Я считают, он не позиционируется как замена iptables. Это скорее работа надо ошибками, которая открывает новые архитектурные возможности проекта.

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

Стоп у ВАС тут какая то игра слов. Семейство утилит iptables переведут с ip_tables на BPF (комментарий) вопрос стоял не в том что делать это после раутинга а как узнать выходной интерфейс. Если я знаю что нужно указывать в --to-source то соответственно я и интерфейс исходящий знаю.

Исходящий интерфейс был примером. И если ты знаешь, что указать в --to-source, тебе всё равно нужен исходящий интерфейс. Потому что только на одном интерфейсе тебе нужен snat, на других не надо. Хватит писать глупости и позориться. Если так уверен в своей правоте, приведи пример рабочего правила, а я тебе объясню, почему оно не подходит.

пример ? Это хорошо, вот ВАМ ваш же пример :

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 1.2.3.4 

nmcli c show id eth0 | grep IP4.ADDRESS
IP4.ADDRESS[1]:                         1.2.3.4/24 

Напиши рабочее правило для iptables без критерия -o. Так яснее?

Не ясно. И непонятно зачем ?

Блин, да ты же сам тут пишешь, что когда netfilter делает snat ему не нужно знать исходящий интерфейс. Вот я тебе и говорю, чтобы ты привёл пример правила, когда это не нужно. Такие случаи есть, но они специфические. В случае классического NAT, когда у тебя на сервере больше 1 интерфейса, ты не сможешь сделать SNAT без информации об исходящем интерфейсе. А эта информация появляется только после роутинга. То есть, в цепочках POSTROUTING.

Пример:
сервер с 3 интерфейсами:
eth0 - LAN (10.0.0.1/16)
eth1 - DMZ (84.83.82.81/24)
eth2 - uplink в сторону провайдера (94.93.92.91/29)

В LAN помимо 10.0.0.0/16 есть ещё 10.1.0.0/16, 10.2.0.0/16,10.3.0.0/16 ..... 10.n.0.0/16. В DMZ ситуация та же.

Задача: делать SNAT только для тех пакетов, которые пришли из LAN и уходят в uplink провайдера.

Я предлагаю это делать так:

iptables -t mangle -A PREROUTING -i eth0 -j MARK --set-mark 0x1
iptables -t nat -A POSTROUTING -o eth2 -m mark --mark 0x1 -j MASQUERADE

Заметь, между eth0 и eth1 никаких NAT'ов быть не должно. Расскажи, как ты будешь писать правила без указания netfilter'у исходящего интерфейса.

Я бы сделал в одну строку типа :

iptables -t nat -A POSTROUTING -o eth2 ! -s 84.83.82.81/24 -j MASQUERADE

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

Ладно забили, как я и предполагал возникла игра слов.

Я бы сделал в одну строку типа :

Не подходит. Я написал, что там не одна сеть, а много. Но, действительно, не суть. Опять же правило с критерием -o.

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

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

у пакета сразу же готовая структура данных

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

занавес.

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

помоему у пакета сразу же готовая структура данных

Действительно занавес. Тебе говорят, что некоторые вещи о пакете сразу не известны, а ты говоришь, что всё готово изначально. Ну или это опять недопонимание.

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

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

у пакета сразу же готовая структура данных

https://en.wikipedia.org/wiki/Field_(computer_science)
атрибуты не возникают, они уже есть. их значения... я процитирую тоже сообщение:

просто что-то может его менять в процессе

и это «что-то» необязательно файервол. это абстрактное что-то.

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

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

и по моим ответам тебе, прям сразу понятно, что думал я «исходящий интерфейс пакета известен сразу»

Ага, именно так.

у это штуки все поля заранее известны

а как ты узнаешь значение поля до какого-то момента, а?

вот тебе поле, добавляй\меняй значения

ааа! я так и знал! ты считаешь, что всё известно заранее!

теперь, после антракта, у нас цирковое представление с клованами?

исходящий интерфейс пакета известен сразу

Да. Он вычисляется на основании адреса назначения.

Он вычисляется в процессе, и не известен, например, в цепочках PREROUTING.