CentOS 7 Firewalld - почему такая боль?

Как пытаешься? Зоны создал, интерфейсы настроил. Правила для зон добавил? Смотри файлы в [inlnie]/usr/lib/firewalld/zones/. С зонами internal и external шлюз работает.

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

Оно так и сделано. Взята произвольная зона «external» и настроена так, чтобы подходила для WAN интерфейса. Просто разработчики не 5.2, имя руководствуясь логикой выбрали.

Удали его к чертям и поставь iptables-services/ipset-setvices. Эта хрень нужна только для всяких web-морд и прочих интерфейсов, никаких плюсов перед обычным конфигурированием живым человеком она не дает.

Только если говорить про localhost. А если надо вживую править iptables, не теряя текущего состояния conntrack'а и правил, добавленных сторонним софтом, то firewalld вполне гут. Жаль в 6 не завезли.

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

Только если говорить про localhost. А если надо вживую править iptables, не теряя текущего состояния conntrack'а и правил, добавленных сторонним софтом, то firewalld вполне гут. Жаль в 6 не завезли.

С каких это пор правила iptables сбрасывают conntrack ?

FirewallD удобен как работающее искаропки решение для локалхоста или прочих некритичных сервисов, где достаточно прописывать --add-service=. Что то серьезное на нем делать - это юзать велосипед ввиде --direct.

Зачем такое советуешь? ТС же не через задницу хочет.

iptables удобнее? Ок:

firewall-cmd --add-interface=enp2s0 --zone=internal --permanent
firewall-cmd --add-interface=tap0 --zone=internal --permanent
firewall-cmd --add-interface=enp3s0 --zone=external --permanent
firewall-cmd --add-service=openvpn --zone=external --permanent
firewall-cmd --reload

«что-то серьёзное» это например?

Что это? Что за зоны? как откроешь iptables -L так вешаться хочется, опиши конфигураци. которая тебе нужна накидаю на iptables за пару минут. А это фигне верить нельзя.

Спасибо. но я сам великий специалист по iptables. уже 10 лет назад использую ipcop. там ручками работать и работать.

я все же хочу все сделать в рамках firewalld.

centos7

интерфейсы создал через systemd-networkd

решил все делать как надо, а не как умею и помню.

Для 7 версии стандартный способ настраивать интерфейсы таки NetworkManager

Таки да, systemd-networkd сделан в основном для контейнеров systemd-nspawn.

Да самый минимум, обычныйдомашний роутер: enp3s0 смотрит в сторону ISP, enp2s0 - в LAN.

Конфа простая:Есть vpn. Из глобала всё закрыто, в локалку раздаётся интернет.

iptables -P INPUT DROP
iptables -P FROWARD DROP
iptables -P OUTPUT DROP

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m conntrack --ctstate NEW -i enp2s0 -j ACCEPT
iptables -A INPUT -m conntrack --ctstate NEW -i enp3s0 -p icmp -j ACCEPT

iptables -A FROWARD -i enp3s0 -o enp2s0 -d <локальная_подсеть> -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i enp2s0 -o enp3s0 -s <локальная_подсеть> -m conntrack --ctstate ESTABLISHED,NEW -j ACCEPT

iptables -A FROWARD -i enp3s0 -o openvpn -d <подсеть_vpn> -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i openvpn -o enp3s0 -s <подсеть_vpn> -m conntrack --ctstate ESTABLISHED,NEW -j ACCEPT

iptables -A FORWARD -i openvpn -o enp2s0 -s <подсеть_vpn> -d <локальная_подсеть> -j ACCEPT
iptables -A FORWARD -i enp2s0 -o openvpn -s <локальная_подсеть> -d <подсеть_vpn> -j ACCEPT

iptables -A OUTPUT -m conntrack !--ctstate INVALID -j ACCEPT

iptables -A POSTROUTING -o enp3s0 -j MASQUERADE

Можно конечно еще с адрес листами заморочиться и вместо дублирвоания правил для openvpn и lan цепочек добавить, но и так все понятно.

Все эти firewalld, ufw, shorewall не добавляют нового функционала в iptables, они просто позволяют писать конфиги по своему. Но проще выучить обычный iptables и не задумываться над тем что там натворили авторы очередного «userfriendly» интерфейса.

> FROWARD

Ну вот видишь, ты начал косячить со 2-й строки

грамар нации 80лвл? это только пример, в реальной жизни ошибка сразу обнаружится

Вы прослушали реплику из диалога на ЧАЭС 26 апреля 1986 года.

пытаюсь сделать ... не работает

Внимательно проанализировав предоставленную информацию, осмелюсь предположить, что нарушена ритуальная чистота серверной.

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

275 байт скрипт для firewalld и 1,150 байт для iptables. Это одинаково удобно?

в реальной жизни ошибка сразу обнаружится

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

iptables -A FROWARD -i enp3s0 -o enp2s0 -d <локальная_подсеть> -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Ещё и на адрес подсети завязано. Держать это в памяти, или покупать проездной в Урюпинск?

Все эти firewalld, ufw, shorewall не добавляют нового функционала в iptables

Все эти firewalld и iptables лишь интерфейс к netfilter.

проще выучить обычный iptables и не задумываться над тем что там натворили

Проще купить DIR-300 и вообще ни о чём не думать. Но мы же не 5.2, чтобы не думать.

А потом, чтобы заработал PLEX, я выполню firewalld --add-service=plexmediaserver --permanent, а ты будешь открывать порты руками (для тебя перечислю):
32400/tcp, 1900/udp, 3005/tcp, 5353/udp, 8324/tcp, 32410/udp, 32412/udp, 32413/udp, 32414/udp,32469/tcp

Угу, пробовал я настроить этот ваш хвалёный firewalld в CentOS 7(еще в первом РЕЛИЗЕ!). Из самых эпичных багов - permanent никуда ничего не сохранял. То есть после ребута я обнаружил девственно чистый файрвол.

После этого я плюнул и настроил по-старинке через iptables.

275 байт скрипт для firewalld и 1,150 байт для iptables. Это одинаково удобно?

А ты посчитай портянку которую firewalld генерирует и попробуй в ней разобраться

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

В реальной жизни я политики в конце пропишу или еще какие меры предосторожности прийму

Ещё и на адрес подсети завязано. Держать это в памяти, или покупать проездной в Урюпинск?

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

Все эти firewalld и iptables лишь интерфейс к netfilter.

Ну ок, давай расскажи мне как голый netfilter конфигурировать. iptables сейчас наиболе актуальный интерфейс, ему на замену разрабатывают nftables, когда будет готово можно будет перейти на него. И разрабатывают те-же люди что пишут netfilter, а не васяны из редхата.

Проще купить DIR-300 и вообще ни о чём не думать.

dir300 - это ваш firewalld и есть, внутрях там тот-же linux с netfilter и iptables

а ты будешь открывать порты руками (для тебя перечислю):

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

Ни «ничего не сохранял», а конфликт был с NM - слетали зоны. Наблюдал один раз. Фиксилось правкой ifdown скрипта. Со следующим обновлением починили.

Один раз потребовало внимания, зато уже более двух лет экономит ресурсы. Или вы без тестирования обновляете боевые сервера?

Один раз потребовало внимания, зато уже более двух лет экономит ресурсы

Подобные баги в сверхстабильной CentOS -> повод не юзать это вообще.

Плюс, я посмотрел на результирующий вариант, в котором больше половины правил было с --direct и портянкой из команд для iptables и не понял где там экономия. Особенно с учетом, что там стоит проприетарный софт, скрипты которого даже на systemd еще не перешли, про описания служб для firewalld они еще лет 10 знать не будут похоже )))

Или вы без тестирования обновляете боевые сервера?

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

А ты посчитай портянку которую firewalld генерирует и попробуй в ней разобраться

Посмотрел. Что непонятного там? Да и зачем оно мне, когда firewalld работает.

В реальной жизни я политики в конце пропишу или еще какие меры предосторожности прийму

Всё-равно опечатаешься и поедешь в Урюпинск. Хоть за «прийниймайся».

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

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

Ну ок, давай расскажи мне как голый netfilter конфигурировать.

Зачем, когда есть firewalld и iptables? Васяна с лора бомбит, что в red hat смогли написать интерфейс к netfilter, а он - нет?

dir300 - это ваш firewalld и есть, внутрях там тот-же linux с netfilter и iptables

Нет, dir300 это ваше не думать. А мы умеем подумать и выбрать удобство без ущерба к надёжности.

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

Команда всё-равно в 4 раза длиннее поулчится.
И я знаю какие порты откываются. Дальше что?
А бинарники при апдейте точно изменятся. Не обновлять систему?
Ты не умеешь xml читать?

Подобные баги в сверхстабильной CentOS -> повод не юзать это вообще.

Багтрекер любого дистрибутива открой и ужаснись.

Товарищей, внедряющих такое в режиме «херак-херак и в продакшен» хочется попросить вон из профессии.

Купи RHEL - будут гарантии, а бесплатно берёшь - потрудись проверить. Не нравится - напиши сам.

Плюс, я посмотрел на результирующий вариант...

Где этот вариант? Один случай на сотню инстансов? Не экономия это, ага.

Особенно с учетом, что там стоит проприетарный софт, скрипты которого даже на systemd еще не перешли...

Лишний повод не использовать проприетарное г-но.

Всё-равно опечатаешься и поедешь в Урюпинск. Хоть за «прийниймайся».

опечататься и в firewalld можно

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

Нормально там все получается и прозрачно.

Зачем, когда есть firewalld и iptables?

Затем, что netfilter модуль ядра и на прямую ты его не настроишь, для этого есть инструменты типа iptables, а все эти firewalld надстройки над iptables

Команда всё-равно в 4 раза длиннее поулчится.

Зато одна команда, а что там генерирует firewalld никому не известно.

опечататься и в firewalld можно

Только при этом сеанс SSH не прервётся.

Нормально там все получается и прозрачно.

Ты своё нормально в килобайт с лишним уже показал, где с firewalld ¼Кб достаточно.

firewalld надстройки над iptables

Пруф?

Феерично, у вас там всё в мире firewalld, доступ к маршрутизатору в урюпинске через «FORWARD», а косячное правило в firewalld не разоврвёт текущую сессию, а проявится только после перезагрузки.

доступ к маршрутизатору в урюпинске через «FORWARD»

Ваша фантазия. Он опечатается в

iptables -A INPUT -m conntrack --ctstate NEW -p tcp --dport 22 -j ACCEPT

косячное правило в firewalld не разоврвёт текущую сессию, а проявится только после перезагрузки

Вернёмся к началу? Где выше риск опечатки? Ну и, если сервер далеко, открой ещё одно подключение к нему: получилось - всё хорошо, не получилось - не закрывай текущую сессию и ищи ошибку. И с firewalld можно проверить что ты понаоткрывал

# firewall-cmd --list-services --zone=external
ssh openvpn

log4tmp

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

Выше было правильно написано, что нужно править текущий набор правил в ядре, а не файл /etc/iptables.conf, если сильно ошибся, то просто нужно перезагрузить удалённый сервер.

Опечатается он или нет в правиле ″--ctstate NEW″ не страшно, на первое место он поставил ″--ctstate ESTABLISHED,RELATED″, текущее соединение по ssh не разорвётся.

Или вообще забудет открыть этот порт, как выше уже забыл про openvpn.

Вобще это было ваше условие:

Из глобала всё закрыто

Хотя в целом, непонятно зачем log4tmp полез писать какие-то правила, когда для этого случая действительно проще DIR-300.

Если будет нужен не MASQUERADE, а SNAT и не для всех адресов, так как есть ipsec, если будет много тунелей с динамическим именами интерфейсов (ppp), если сервисы нужно открывать для списков адресов, и несколько каналов в интернет и т.д. тогда будет интерестно посмотреть, в какой ужос привратится firewall-cmd. Потому что быстро скатимя в ″firewall-cmd --direct″, только там, в отличии от ″iptables″ нет ″--insert-rule″ или ″--remove-rule Номер_Правила″.

Вернёмся к началу?

Вернёмся. Изначально firewalld разрабатывался ущербно, в первых версиях не было ″--runtime-to-permanent″, что провоцировало в HOWTO, форумах и т.д. советовать плохое, а именно ″--permanent″. Опечатался и потерял открытую сессию ssh — точно самому ехать далеко, так как презагрузка ситуацию не исправит. А открытая сессия может потерятся легко — выключили свет, упал канал в инет дома или там в урюпинске, сам случайно закрыл.

И с firewalld можно проверить что ты понаоткрывал

Можно, и на это всё. Нет ни счётчиков пакетов у правил, ни ″-j TRACE″, чтобы как-то понять,

В части описанного «защитником fireненужноД» укажу только на одну ошибку policy DROP. Вот она с большей вероятностью может привести к «дальней поездке».
Во всем остальном «бред сивой кобылы» (я не про вас, а про «защитника») когда «непонятно что», «непонятно как» генерит кучу правил , нельзя быть уверенным в том что fw работает так как тебе нужно. Даже мелочь в виде libvirt с дэфолтным nat и то обхожу стороной, проще бридж руками поднять и правила в iptables написать.

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

а сервер домашний, если что либо запорол, можно и до вечера подождать.

Нет, это ваша фантазия, что ошибка в аргументах команды iptables ведёт к поездке к удалённому серверу. ... И этот кто-нибудь в состоянии перезагрузить сервер или это можно сделать через KVM.

Кого-нибудь может и машина сбить. Я намеренно утрирую. Сути не меняет - доступ к серверу пропал.

Вобще это было ваше условие:

Перед этим сказал, что есть vpn и в командах firewall-cmd явно открыл его. Не надо к словам придираться. Забыл - так забыл.

А открытая сессия может потерятся легко

В такой ситуации я fwd и ipt равны. От этого он перестал оптимизировать трудозатраты?

Можно, и на это всё.

А в том, что есть, упрощает работу. Чего нет - допишут потом. Тебе всё сразу надо? Напиши сам - хватит ныть!

Изначально firewalld разрабатывался ущербно

Москва не сразу строилась. Багзила iptables пуста?

в какой ужос привратится firewall-cmd

Если нужен, а вдруг это, а если то. Вот когда «если» наступит, тогда и руками в iptables полезешь. Тебе голова на что дана, кушать или инструментарий по задаче выбирать?

текущее соединение по ssh не разорвётся.

наглое 4.2. скопипасть правила в .sh и запусти по ssh

Удивляют господа, которым дают удобный инструмент для простых задач, а они возмущаются. Это неосиляторство, или что? Старый добрый ipt ни кто не отобрал. Надо рулить кучкой сервисов в зонах - делай это парой команд. Надо сложную цепочку правил - выключи fwd и пользуйся ipt. Чего боимся?

когда «непонятно что», «непонятно как» генерит кучу правил ,

anc, почему тогда мне понятно что и как? А когда непонятно iptables -L прочитать можно. Да, сложнее, а как ты хотел? Выше абстракция, сложнее конфиг.

Сути не меняет - доступ к серверу пропал.

Ну пропал доступ к маршрутизатору по ssh, FORWARD в нём продолжает работать, найдётся другой обслуживающий, кто сможет Ctrl+Alt+Del нажать.

В такой ситуации я fwd и ipt равны

Они не равны, так как все учат делать ″firewall-cmd --permanent″. Откатить ошибочные измения простым дейстивим (перезагрузкой сервера) не получится.

Багзила iptables пуста?

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

Вот когда «если» наступит,

«Если» у меня наступил давно и не проходит, дома в сервер-маршрутизаторе 3 сетёвки и 4 тунеля, не так давно было два провайдера, сейчас один, но всё думают прикрутить к серверу USB-3G на постоянную. На работе как-то аналогично. И ssh у меня не на 22 порту, так что public (default) мне всё равно править.

скопипасть правила в .sh и запусти по ssh

Это ничего не даст, сначала нужно будет переименовать интерфейсы (enp2s0), потом очистить iptables, вечером, если будет время, сделаю.

Удобный инструментарий для простых задач это DIR-300 и прочие мыльницы, там хотя бы нельзя создать завалы из ″firewall-cmd --direct″. Вот приходишь ты на новую работу, админ уволился уже пару месяцев как, но оставил после себя жуть в файерволе. Если это просто iptables это одно, а иначе страшно.

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

Это LOR, хотя и мёртвый, а не служба техподдержки. Вам высказывают мнение как правильно на настоящий момент готовить firewalld — удалить.

Хотите задавать конкретные вопросы, пожалуйста. Но при таком описании задачи, когда вы не привели не списка интерфейсов, ни одной команды ″firewall-cmd″, ни желаемого прохождения пакетов, вобще удивительно, что вам хоть что-то написали. Думаете, что назвали зону ″idnet″ и все сразу поймут, что это канал в интеренет?

А когда непонятно iptables -L прочитать можно. Да, сложнее, а как ты хотел? Выше абстракция, сложнее конфиг.
Выше абстракция, сложнее конфиг.

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

А когда непонятно iptables -L прочитать можно.

Возможно вы не поняли, что я хотел сказать. Добавление неведомых мне правил и которые могут «внезапно» измениться из-за очередного обновления/бага в такой системе как fw не очень «впечатляет».
Предлагаете каждый раз перечитывать всю портянку iptables-save, для того что бы быть уверенным в том что не появилась «дыра» ? Спасибо, но это не упрощение работы - это именно усложнение.

ЗЫ Кстати выше упоминали nftables, ваш firewalld готов к нему? Или тоже будете «догонять» - «Москва не сразу строилась.»

Загрузил правила от log4tmp, да, там действительно есть одна критичная опечатка, блокирующая уже открытые ssh-сессии — отсутствие пробела между ″!″ и ″--ctstate″. Остальное, как ″FROWARD″ и отсутствие ″-t nat″ не закроет открытую по ssh-сессию.

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

и ″-P OUTPUT DROP″

Вот! Я выше писал что любая (не только OUTPUT) policy DROP может привести к «дальней поездке». Один косяк в разрешающих правилах и собирайся в дорогу. Разумнее по старому принципу, в конце цепочек добавлять DROP.

Ну пропал доступ к маршрутизатору по ssh, FORWARD в нём продолжает работать, найдётся другой обслуживающий, кто сможет Ctrl+Alt+Del нажать.

В любом случае это время.

Они не равны, так как все учат делать ″firewall-cmd --permanent″. Откатить ошибочные измения простым дейстивим (перезагрузкой сервера) не получится.

Те, кто firewall-cmd --help до --runtime-to-permanent не дочитал, должны пару раз купить билет, чтобы стимул дочитать появился. К тому же после [inlnie]firewall-cmd --reload у неопытного юнца есть шанс исправить ошибку, а в случае с iptables - связь пропадёт сразу.
Ну и --remove-service=ssh вряд ли по ошибке вместо --add-service=http написать можно.

Возможно, лет через 5 они firewalld до приемлемого уровня.

Именно. firewalld не «говно», он «не готов ещё» для полноценной замены iptables. Но в большинстве случаев --{add,remove}-service достаточно. И тут firewall-cmd значительно удобнее ручного указания портов и интерфейсов.

«Если» у меня наступил давно и не проходит… И ssh у меня не на 22 порту, так что public (default) мне всё равно править.

И что? Хочешь --add-service=freeipa --zone=corp и потом --{add,remove}-interface=tun45 --zone=corp пишешь несколько --direct. Не хочешь - пользуешь iptables. Повторюсь: хочешь всего и сразу - оплати разработку, или допиши сам.

Это ничего не даст, сначала нужно будет переименовать интерфейсы

Тебе всегда о явных вещах явно указывать нужно?

Удобный инструментарий для простых задач это DIR-300 и прочие …админ уволился уже пару месяцев как, но оставил после себя жуть в файерволе. Если это просто iptables это одно, а иначе страшно.

DIR-300 - это проприетарный дырявый чёрный ящик. И он не удобен.
Если это firewalld, то у тебя есть список зон, сервисов и интерфейсов, а так же скрипт с последовательным вызовом firewall-cmd --direct, почти как в iptables-save. Допилят перманентный директ, думаю, будет и возможность их список посмотреть удобно. Т.о. вопрос опять в привычках.

следующая версия firewalld сгенерит по старому набору зон/сервисов такой же набор правил.

Не тот порт не в той зоне откроет? Оформишь багрепорт, или ошибок в других проектах не бывает? Или переходишь с rhel7 на rhel8 без тестирования, сразу на боевых машинах?

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

firewall-cmd --add-service=<sname> --zone=<zname> есть усложнение? Что у вас с логикой?
А то, что iptables -L сложнее выходит, так ipt в зоны по другому не умеет.

Добавление неведомых мне правил и которые могут «внезапно» измениться из-за очередного обновления/бага в такой системе как fw не очень «впечатляет».

У вас шлюзы на Fedora? А от бага в netfilter как защищаетесь?
Установочные скрипты всех пакетов проверяете на отсутствие iptables -A && iptables-save? Или таки каждый раз iptables -L?

Кстати выше упоминали nftables, ваш firewalld готов к нему?

Он не мой. И вопрос этот адресовать нужно тем, кто кричит: «только %appname%, и никаких %otherapp%». Я пользуюсь и fwd, и ipt. По ситуации. nftables толком не пробовал ещё.

Загрузил правила от log4tmp, да, там действительно есть одна критичная опечатка

mky, потребовалось загрузить правила? А глазами ошибку не увидели? А как же «iptables всегда проще»?

Вам высказывают мнение как правильно на настоящий момент готовить firewalld — удалить.

Вы несёте чушь. Правильно в настоящий момент не удалять fwd, а изучить и определить для себя, через что рулить нетфильтром. ТС хочет firewalld посмотреть, а вы заладили «Сжечь демона! На костёр его!». Может ТС не хочет с вами бояться нового?

В любом случае это время.

Это обычно быстрее, чем физически доехать до сервера.

″--runtime-to-permanent″ не было в 7.0. Те, кому делать нечего, пусть перечитывают всю документацию по каждой новой версии firewalld, а я лучше подожду. Сегодня разработчики сделали одно, завтра решат, что порты сервисов нужно брать не из /etc/services, послезавтра решат, что службы сами должны конфигурировать firewalld и открывать себе любые порты...

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

Тебе всегда о явных вещах явно указывать нужно?

Кому и где эти вещи явные, непонятно, возможно вам в ваших фантазиях. Напомню, что log4tmp дал такие комментарии:

iptables прекрасно правится на живую командами

В реальной жизни я политики в конце пропишу

Засунуть эти правила в скрипт и выполнить на удалённой машине, было ваше, а не log4tmp.

А моя реплика про переименовывание интерфейсов служила пояснением, почему я не стал делать это прямо в момент прочтения комментария.

DIR-300 - это проприетарный дырявый чёрный ящик.

DIR-300 он такой как есть и меняется мало, в отличии от непонятно куда мутирующего firewalld.

Не тот порт не в той зоне откроет?

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

А как же «iptables всегда проще»?

iptables проще и понятнее при добавлении правил по одному, когда сразу ловятся опечатки, а не копипастнутый скриптом. И не всегда, а когда конфигурация становится сложнее, чем может DIR-300.

Может ТС не хочет с вами бояться нового?

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

А от бага в netfilter как защищаетесь?

Встречный вопрос, если такое будет, как firewalld от этого защитит?

Установочные скрипты всех пакетов проверяете на отсутствие iptables -A && iptables-save?

А у меня нет пакетов которые рулят fw. Исключение libvirt на поддиванном для тестирования и то как писал выше эту часть послал нафиг.
И в данном случае вы «передергиваете» fwd рулит правилами, значит проверять все-таки надо, даже вы признали что он еще «не готов».

Он не мой. И вопрос этот адресовать нужно тем, кто кричит: «только %appname%, и никаких %otherapp%». Я пользуюсь и fwd, и ipt. По ситуации. nftables толком не пробовал ещё.

Я не корректно сформулировал. Мне действительно интересно с nftables он будет работать или такого даже в планах пока нет? Единственное ЗА изучение нового интерфейса может быть только в том что он будет унифицирован как для iptables так и для nftables.
Если посмотреть на историю, был ipfw потом ipchains потом iptables у них разные возможности и как следствие разный интерфейс в части написания правил. Переезд между ними, особенно ipchains - iptables, вызывало проблему в части изучения. Собственно у nftables сделали возможность загружать правила в формате iptables, что бы не было по началу жуткой попоболи.

Может ТС не хочет с вами бояться нового?

Теперь про fwd - если он ориентирован исключительно под «iptables» то смысла изучать/пилить что-то «новое» которое уже скоро станет «старым» абсолютно нет. Если бы это было лет 12 назад, тогда смысл еще мог быть. А так тратить время на изучение того же самого что работает годами, хорошо документировано, плюс куча готовых примеров в инете, да еще и стрематься за возможные баги... ну нафиг...

Новое (которое не приносит новых возможностей, а только как вы написали очередная абстракция, т.е. усложнение) не всегда есть хорошо: "...и что работает? Работает. Каждый день? Каждый день. И не глючит? Не глючит. Сынок, главное ничего не трогай."

ЗЫ

А то, что iptables -L сложнее выходит, так ipt в зоны по другому не умеет.

Увеличение кол-ва правил таки снижает производительность.

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

Походу «шагнул» - поэтому и не пишет. Как «вылезет» из «будушего» так получиться написать :)

Конфиг больше получается, но не сложнее, чем руками писать. И организован так, чтобы можно было без особых проблем добавлять/удалять изолировано работающие правила. Мне крайний раз libvirt подгадил, т.к. он напрямую использует iptables и прописывает свои правила с помощью iptables ... -I. В таком раскладе, что fwd, что стандартный сервис ipt (который по сути делает flush и iptables-restore), не справляются, т.к. оба запускаются раньше чем libvirtd.

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

Direct и так перманентный есть. А кому не хватает — iptables или direct с passthrough.

Пример с одного из серверов:

<?xml version="1.0" encoding="utf-8"?>
<direct>
  <rule priority="1" table="filter" ipv="ipv4" chain="INPUT">-p tcp -m tcp --dport 80 -m conntrack --ctstate NEW -m policy --dir in --pol ipsec -j ACCEPT</rule>
  <rule priority="1" table="filter" ipv="ipv4" chain="INPUT">-p tcp -m tcp --dport 443 -m conntrack --ctstate NEW -m policy --dir in --pol ipsec -j ACCEPT</rule>
</direct>

Сегодня разработчики сделали одно, завтра решат, что порты сервисов нужно брать не из /etc/services, послезавтра решат, что службы сами должны конфигурировать firewalld и открывать себе любые порты...

Так порты и протоколы и оттуда и не берутся. Они описаны в /usr/lib/firewalld/services/<service>.xml и /etc/firewalld/services/<service.xml>, как это описано в документации.

Разработчики берут порты из /etc/services, во всяком случае, мне так казалось и так было написано у них на сайте.

А оказывается всё хуже, они черпают порты из астрала, например, в /etc/services для openvpn указано два порта — udp и tcp, а у них, в openvpn.xml, только udp порт. Причём, в отличии от ntp, которого нет в tcp, в случае openvpn реально используется tcp, например, Microtik.

В случае openvpn tcp или udp определяется исключительно конфигом на сервере.

Какая разница оттуда они притащили информацию для написания конкретного xml? Хотят — берут порты из педивикии, хотят — с официального сайта, хотят — из IANA registry. Что-то не работает в варианте «из коробки» — идёте в багтрекер.