firewalld 2.5.1 исправил переход правил между зонами и политиками

firewalld 2.5.1 вышел 7 августа 2026 года как корректирующий релиз без новых функций. Центральное исправление меняет завершение цепочек OUTPUT и POSTROUTING, чтобы обработка трафика не продолжалась в других зонах или политиках после уже найденного соответствия.

firewalld 2.5.1 устраняет «дрейф» между зонами и политиками

Разработчики firewalld выпустили версию 2.5.1 всего через месяц после крупного обновления 2.5.0. На странице релиза команда прямо называет эту версию bug-fix only release: новых возможностей здесь нет, список изменений состоит из четырёх исправлений.

Самое заметное из них связано с внутренней диспетчеризацией правил. firewalld строит набор цепочек, через которые сетевой пакет проходит в зависимости от зоны, направления трафика и активных политик. В версии 2.5.0 эта логика получила переработку многоступенчатой диспетчеризации, а теперь выяснился побочный эффект: в некоторых цепочках выполнение могло вернуться в верхний уровень и продолжить поиск в других зонах или политиках.

В исправляющем коммите разработчики называют такое поведение «drifting» — дрейфом. Для цепочек OUTPUT и POSTROUTING завершение теперь происходит через ACCEPT. Раньше там использовался RETURN, который после изменений в 2.5.0 мог возвращать обработку в общую цепочку диспетчеризации.

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

OUTPUT и POSTROUTING теперь завершаются через ACCEPT

Исправление затрагивает две важные точки обработки сетевого трафика.

OUTPUT относится к пакетам, которые создаёт сама Linux-система. Это, например, исходящее соединение серверного процесса к базе данных, DNS-запрос локальной службы или обращение приложения к внешнему API.

POSTROUTING применяется позднее, когда маршрут пакета уже выбран. На этом этапе часто работают правила трансляции адресов, включая NAT и masquerading.

В firewalld 2.5.1 генераторы правил для iptables и nftables изменены одинаково: для OUTPUT и POSTROUTING используется ACCEPT, тогда как PREROUTING сохраняет RETURN. В комментарии к коду разработчики отдельно поясняют причину для PREROUTING: на этой стадии ещё нельзя надёжно определить, предназначен пакет локальной машине или будет отправлен дальше.

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

Проверка составных зон больше не ограничивает имя вложенного XML-файла

Второе исправление касается check_config, то есть проверки конфигурации firewalld перед её применением. В версии 2.5.0 проверка была расширена для combined zones — составных зон, конфигурация которых разбивается на несколько XML-файлов внутри каталога зоны.

После этого появилась лишняя проверка длины имени для вложенных файлов. В firewalld 2.5.1 код различает обычные XML-файлы зон и файлы внутри каталога составной зоны. Для последних проверка длины имени отключается.

По изменению в исходном коде видно, что функция обхода конфигурации теперь передаёт отдельный признак check_name_len. Это точечная коррекция поведения, появившегося после расширения проверки combined zones в предыдущем релизе.

Практический эффект касается систем, где конфигурация зоны разделена на несколько файлов. firewalld должен оценивать содержимое такой структуры как единое описание зоны, а имя отдельного вложенного XML-файла больше не попадает под ограничение, рассчитанное на самостоятельный объект конфигурации.

firewall-cmd получил две небольшие правки интерфейса и документации

Оставшиеся два изменения заметно меньше по масштабу.

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

Второе исправляет документацию firewall-cmd: из описания удалён повторяющийся параметр --permanent. Функциональность команды от этого не меняется, правка устраняет дублирование в справочном тексте.

В сумме официальный changelog 2.5.1 содержит четыре пункта:

• исправлено завершение OUTPUT и POSTROUTING через ACCEPT;
• скорректирована проверка имён файлов в составных зонах;
• устранён лишний перевод строки при пустом сообщении firewall-cmd;
• удалено повторное упоминание --permanent в документации.

В релиз-нотах firewalld 2.5.1 нет упоминаний CVE или отдельного бюллетеня безопасности. Проект описывает выпуск именно как исправление ошибок.

Версия 2.5.1 корректирует изменения, появившиеся после firewalld 2.5.0

Предыдущий релиз firewalld 2.5.0 вышел 8 июля 2026 года и имел другой масштаб. Он добавил автоматическую тёмную тему в firewall-config, предупреждение при изменении конфигурации через watcher и описание сервиса Apache Solr. Одновременно команда переработала диспетчеризацию зон и политик, ускорила проверки конфигурации и внесла ряд исправлений в nftables, D-Bus и policy handling.

Именно связь с 2.5.0 объясняет, почему небольшой патч получил заметное изменение внутри механизма обработки правил. Коммит с ACCEPT прямо ссылается на более раннюю переработку zone/policy dispatch и на проблему, возникшую после появления многоступенчатой схемы.

firewalld сохраняет прежнюю модель управления Linux-фильтрацией

Архитектурно релиз 2.5.1 ничего не меняет. firewalld по-прежнему выступает динамическим менеджером сетевого экрана Linux, управляет зонами, политиками, NAT, IPv4 и IPv6 и умеет работать с разделением runtime- и permanent-конфигурации. Изменения можно применять во время работы системы без обязательного перезапуска демона.

Проект используется как стандартный инструмент управления firewall в Fedora, RHEL, CentOS, SUSE и openSUSE. Поэтому даже короткий корректирующий выпуск затрагивает базовый сетевой компонент, который в серверной инфраструктуре часто находится между приложением и низкоуровневыми правилами nftables или iptables.

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