LINUX.ORG.RU

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

 , , ,


3

5

На конференции Netfilter Workshop разработчики сетевой подсистемы ядра Linux объявили о скором переходе ставших традиционными утилит конфигурирования netfilter (iptables, ebtables, arptables) с ядерной подсистемы ip_tables на Berkeley Packet Filter/x_tables, предоставляющей более гибкие возможности по управлению обработкой проходящих через Linux сетевых пакетов и возможно большей производительностью обработки за счёт использования JIT-компилятора.

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

Также доступен транслятор для перевода правил iptables в синтаксис «родной» утилиты новой подсистемы ядра (nft): iptables-translate.

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



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

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

Вот есть файрвол 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? Опять Поттеринг морочить головы людям??

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

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

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

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

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

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

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

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

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

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

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

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

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

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

zloy_starper ★★★
()
Ответ на: комментарий от system-root

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

anonymous
()

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

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

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

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

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

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

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

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

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

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

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

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

system-root ★★★★★
()
Ответ на: комментарий от zloy_starper

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

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

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

system-root ★★★★★
()
Последнее исправление: system-root (всего исправлений: 1)
Ответ на: комментарий от Black_Shadow

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не угадал :-)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я, в свою очередь приведу пример, как это делается в 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
Но использовать такое правило в INPUT у тебя всё равно не получится, потому что транзитные пакеты туда не попадают. Валяй, придумывай выход.

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

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

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

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

Black_Shadow ★★★★★
()
Последнее исправление: Black_Shadow (всего исправлений: 2)
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

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

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 

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

Блин, да ты же сам тут пишешь, что когда 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'у исходящего интерфейса.

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

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

iptables -t nat -A POSTROUTING -o eth2 ! -s 84.83.82.81/24 -j MASQUERADE
Но это к делу не относится.

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

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

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

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

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

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

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

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

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

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

занавес.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

system-root ★★★★★
()
Ответ на: комментарий от Black_Shadow

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

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

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