Современная версия использует другой механизм в ядре - nft.

Да, я понимаю. У нас он не собран ?

сделал тестовое задание #225610
Посмотрим как работает.

Там с миграцией на nft не всё просто:
https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables

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

У нас может поломаться efw в etcnet ещё.

(In reply to comment #1)

> Современная версия использует другой механизм в ядре - nft.

Где-то видел обсуждение, что при сборке пока ещё можно выбрать.

*** Bug 31651 has been marked as a duplicate of this bug. ***

http://git.altlinux.org/tasks/225610/

Можно попробовать.

В legacy mode я разницы с текущим не особо заметил.

Дима, что скажешь ?

(In reply to comment #9)
> В legacy mode я разницы с текущим не особо заметил.

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

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

по умолчанию iptables смотрит на iptables-legacy, но при этом появляется стек iptables-nft.

Если у тебя не задействован iptables, то отлично работает iptables-ntf.
Если же ты начал использовать iptables-legacy, то iptables-nft начинают выводить warning по этому поводу.

Ну и iptables-save не меняется, но появляется iptables-nft-save, выполняющий аналогичную функцию.

# rpm -ql iptables |grep nft
/sbin/arptables-nft
/sbin/arptables-nft-restore
/sbin/arptables-nft-save
/sbin/ebtables-nft
/sbin/ebtables-nft-restore
/sbin/ebtables-nft-save
/sbin/ip6tables-nft
/sbin/ip6tables-nft-restore
/sbin/ip6tables-nft-save
/sbin/iptables-nft
/sbin/iptables-nft-restore
/sbin/iptables-nft-save
/sbin/xtables-nft-multi
/usr/share/man/man8/xtables-nft.8.xz

Ничего не ломаем и даём возможность плавно перейти.

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

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

(В ответ на комментарий №13)
> Упакуйте её, пожалуйста, в отдельный подпакет.

+1

(В ответ на комментарий №14)
> (В ответ на комментарий №13)
> > Упакуйте её, пожалуйста, в отдельный подпакет.
> 
> +1

Судя по relnotes RHEL8, в нем
-- The nftables framework replaces iptables in the role of the default network packet filtering facility.

Таким образом, поддержка nft, пусть пока опциональная, становится для нас важной, учитывая появление клонов.

Можно тестировать:
[#229848] [test-only] EPERM (try 3) iptables.git=1.8.3-alt1

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

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

(In reply to comment #17)
> Я посмотрел и регрессий у себя не заметил.

Не регрессия, но в теории кого-то может зацепить:
$ compare_packages -- \
iptables-1.4.21-alt4.x86_64.rpm -- \
iptables-1.8.3-alt1.x86_64.rpm |grep '^-.*lib64'
--rw-r--r--  root root ,    /lib64/iptables/libipt_MIRROR.so
--rw-r--r--  root root ,    /lib64/iptables/libipt_SAME.so
--rw-r--r--  root root ,    /lib64/iptables/libipt_unclean.so

iptables-nft - это, по аналогии с федорой, отдельный подпакет и при обновлении никого зацепить не должен.

В сизифе такие изменения - нормальная практика, так что пускай цепляет.

по MIRROR, кстати, я не уверен что в ядре есть такой интерфейс. всегда пользовался для подобных целей -j TEE

(In reply to comment #19)
> (In reply to comment #17)
> > Я посмотрел и регрессий у себя не заметил.
> 
> Не регрессия, но в теории кого-то может зацепить:

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

> $ compare_packages -- \
> iptables-1.4.21-alt4.x86_64.rpm -- \
> iptables-1.8.3-alt1.x86_64.rpm |grep '^-.*lib64'
> --rw-r--r--  root root ,    /lib64/iptables/libipt_MIRROR.so

commit 73f453bb816d038792a849743d5055ad31b8ad76
Author: Florian Westphal <fw@strlen.de>
Date:   Thu Feb 19 01:17:18 2015 +0100

    extensions: remove MIRROR
    
    removed from the kernel back in 2003.

> --rw-r--r--  root root ,    /lib64/iptables/libipt_SAME.so

commit 28972c60d7595e5a4986165ea6ae62a85f20d2e6
Author: Florian Westphal <fw@strlen.de>
Date:   Thu Feb 19 01:20:15 2015 +0100

    extensions: remove SAME target
    
    removed from the kernel December 2007.

> --rw-r--r--  root root ,    /lib64/iptables/libipt_unclean.so

commit d81dc8e5f7e33646b3e56e274c46c3599275cbc1
Author: Florian Westphal <fw@strlen.de>
Date:   Thu Feb 19 01:27:36 2015 +0100

    extensions: remove 'unclean' match
    
    removed from kernel in 2003.

[#229848] EPERM (try 4) iptables.git=1.8.3-alt1
...
#240 build 242-alt8 from /gears/s/systemd.git fetched at 2019-May-28 16:26:12
...
#400 build 2.0.15-alt2 from /gears/k/keepalived.git fetched at 2019-May-28 16:12:59
...
girar-check-perms: access to systemd DENIED for ldv: does not belong to approved builders list: shaba 
systemd: Operation not permitted
girar-check-perms: access to keepalived DENIED for ldv: does not belong to approved builders list: rider shaba
keepalived: Operation not permitted

keepalived approved.

iptables-1.8.3-alt1 -> sisyphus:

Mon May 27 2019 Dmitry V. Levin <ldv@altlinux> 1.8.3-alt1
- 1.4.21 -> 1.8.3 (closes: #36371).
- Packaged -nft subpackage with nftables compatibility
  for iptables, arptables and ebtables.

Спасибо!