Debian/Ubuntu: netfilter-persistent save failed — как исправить и сохранить правила nftables/iptables

Сообщение netfilter-persistent save failed в Debian и Ubuntu встречается часто, но почти никогда не означает «сломался файрвол». Обычно причина прозаичнее: смешаны nftables и iptables, выбран не тот backend, отсутствует каталог с файлами правил или сервис сохраняет одно представление правил, а загружает другое.

Самая неприятная ловушка в современных релизах — администратор настраивает правила через nft, а затем пытается сохранить их командой netfilter-persistent save, ожидая поведение старого iptables-persistent. Возможен и обратный сценарий: система работает через совместимость iptables-nft, а диагностика ведётся по старым инструкциям для iptables-legacy.

Ниже разберём, как быстро определить активный стек, где искать причину ошибки и какую схему считать правильной: через nftables или через iptables-persistent. В конце будет короткий runbook для случая, когда сервер уже в продакшене и времени мало.

Главное правило простое: у файрвола на сервере должен быть один понятный источник истины. Либо вы ведёте конфигурацию через nftables, либо через iptables-persistent. Смешанный режим почти всегда приводит к путанице.

Что делает netfilter-persistent и откуда берётся save failed

netfilter-persistent — это обёртка над плагинами из каталога /usr/share/netfilter-persistent/plugins.d. На практике она чаще всего вызывает сохранение и восстановление правил для iptables и ip6tables. Из-за этого многие ожидают, что она так же прозрачно будет работать и с nftables, но это не универсальный сценарий.

Типовые причины ошибки обычно сводятся к одному из нескольких вариантов:

• нужный backend не установлен или выбран не тот набор alternatives;
• вы используете nftables, но сохраняете правила так, будто это чистый iptables;
• отсутствуют /etc/iptables/rules.v4 и /etc/iptables/rules.v6 или нет каталога /etc/iptables;
• в одном месте правила меняются через nft, в другом — через iptables;
• после переключения между iptables-legacy и iptables-nft остались старые файлы правил;
• сервис сохраняет правила успешно, но после перезагрузки загружается уже другой механизм.

Полезно разделять две разные проблемы: ошибка при сохранении и ошибка при восстановлении после reboot. Они часто связаны, но лечатся не всегда одинаково.

Сначала определите реальный стек: nftables или iptables

Пока вы не понимаете, что именно работает на сервере, любые правки будут скорее гаданием. Сначала проверьте состояние nftables:

systemctl status nftables
nft list ruleset

Затем посмотрите версию iptables и выбранный backend:

iptables --version
ip6tables --version
update-alternatives --display iptables
update-alternatives --display ip6tables

И отдельно проверьте установленные пакеты:

dpkg -l | egrep 'nftables|iptables|iptables-persistent|netfilter-persistent'

Интерпретация обычно такая:

• если iptables --version содержит nf_tables, значит iptables работает поверх nft backend;
• если в версии видно legacy, значит используется старый xtables-стек;
• если nft list ruleset показывает полноценный ruleset, а /etc/nftables.conf существует и обслуживается сервисом, основной механизм у вас, скорее всего, nftables;
• если одновременно установлены nftables и iptables-persistent, а правила менялись разными способами, нужно искать конфликт.

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

Как быстро найти причину через логи и ручной запуск

Не ограничивайтесь текстом ошибки в консоли. Сначала проверьте, что пишет systemd:

systemctl status netfilter-persistent
journalctl -u netfilter-persistent -b
journalctl -xeu netfilter-persistent

После этого выполните сохранение вручную:

netfilter-persistent save

Если ошибка неочевидна, полезно посмотреть сами плагины, чтобы понять, что именно вызывается внутри:

ls -l /usr/share/netfilter-persistent/plugins.d/
sed -n '1,200p' /usr/share/netfilter-persistent/plugins.d/15-ip4tables
sed -n '1,200p' /usr/share/netfilter-persistent/plugins.d/25-ip6tables

Обычно сразу видно, что обёртка вызывает iptables-save и пытается записать результат в /etc/iptables/rules.v4 и /etc/iptables/rules.v6. Поэтому следующая быстрая проверка — каталог и права:

ls -ld /etc/iptables
ls -l /etc/iptables

Если каталога нет или он создан вручную с неверными правами, причина может быть именно здесь.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Сценарий №1: вы используете nftables, а сохраняете как iptables

Это самый частый случай. Правила созданы через nft add rule, фильтрация реально работает, но команда netfilter-persistent save либо падает, либо сохраняет совсем не то, что ожидалось. Причина в том, что для nftables постоянство правил обеспечивается не через iptables-persistent, а через конфигурацию самого nftables.

Корректная схема для Debian и Ubuntu выглядит так:

1. сформировать рабочий ruleset;
2. сохранить его в /etc/nftables.conf;
3. проверить синтаксис;
4. включить и перезапустить сервис nftables;
5. проверить итоговый ruleset после reboot.

Посмотреть и сохранить текущий ruleset можно так:

nft list ruleset
nft list ruleset > /etc/nftables.conf
nft -c -f /etc/nftables.conf
systemctl enable nftables
systemctl restart nftables
systemctl status nftables

После этого netfilter-persistent для такой схемы уже не нужен. Если вы полностью ведёте правила через nftables, лучше исключить параллельный механизм, чтобы не было ложного ощущения, что именно он отвечает за автозагрузку.

При необходимости можно отключить сервис:

systemctl disable --now netfilter-persistent

Если вы используете более сложные наборы правил, пригодятся отдельные разборы по SNAT с несколькими IP в nftables и динамическим наборам и blocklist в nftables.

Сценарий №2: вы сознательно используете iptables-persistent

Если ваша схема завязана именно на iptables-save и iptables-restore, тогда диагностика должна идти по классическому пути. Сначала посмотрите текущее состояние правил:

iptables -S
ip6tables -S

Затем попробуйте сохранить правила вручную, без обёртки:

iptables-save > /etc/iptables/rules.v4
ip6tables-save > /etc/iptables/rules.v6

Если ошибки появляются уже здесь, проблема не в netfilter-persistent, а в backend, правах, модуле ядра или состоянии подсистемы. Если ручное сохранение прошло успешно, а netfilter-persistent save всё равно падает, смотрите плагины и окружение сервиса.

Полезно проверить и пакеты:

apt policy iptables-persistent netfilter-persistent
dpkg -L iptables-persistent
dpkg -L netfilter-persistent

Иногда помогает переустановка пакетов с пересозданием служебных файлов:

apt install --reinstall iptables-persistent netfilter-persistent
netfilter-persistent save
systemctl restart netfilter-persistent
systemctl status netfilter-persistent

Проверьте переключение между legacy и nft backend

Одна из самых частых причин — старые правила были созданы в режиме iptables-legacy, а сейчас бинарники переключены на iptables-nft, или наоборот. Тогда сохранение и восстановление начинают вести себя непредсказуемо.

update-alternatives --display iptables
update-alternatives --display ip6tables
update-alternatives --display arptables
update-alternatives --display ebtables

Если вы меняете alternatives, после этого лучше заново сформировать и пересохранить правила, а не полагаться на старые rules.v4 и rules.v6.

Сценарий №3: save работает, но после перезагрузки правила не те

В этом случае проблема уже не в сохранении, а в автозагрузке. Сначала проверьте, какие сервисы включены:

systemctl is-enabled netfilter-persistent
systemctl is-enabled nftables

Самая частая причина — одновременно активны две конкурирующие схемы. Например, nftables.service поднимает один ruleset, а затем netfilter-persistent восстанавливает другой. В результате после reboot сервер работает не по тому набору правил, который вы тестировали вручную.

Проверка после перезагрузки должна быть буквальной:

systemctl status nftables
systemctl status netfilter-persistent
nft list ruleset
iptables -S
ip6tables -S

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

Если на сервере также работает контейнерная среда, отдельное внимание стоит уделить тому, как она меняет сетевые таблицы. Для таких случаев полезен материал про взаимодействие Docker с iptables и nftables.

Частые практические причины ошибки

Нет каталога /etc/iptables

Если каталога нет, создайте его и повторите ручное сохранение:

install -d -m 0755 /etc/iptables
iptables-save > /etc/iptables/rules.v4
ip6tables-save > /etc/iptables/rules.v6

Проблема только с IPv6

Иногда ломается не iptables-save, а именно ip6tables-save. Такое бывает, если IPv6 частично отключён, но сервис всё равно пытается сохранить или восстановить rules.v6. Здесь лучше ориентироваться на журнал systemd, а не на общее сообщение об ошибке.

Синтаксическая ошибка в nftables-конфиге

Если используете nftables, всегда проверяйте конфиг до применения:

nft -c -f /etc/nftables.conf

Это кажется мелочью, но именно такая проверка экономит много времени при поиске причин, почему правила не поднимаются после reboot.

Смешение runtime-правил и файловой конфигурации

Часть правил могла быть добавлена вручную, часть — лежать в конфиге, часть — создаваться контейнерами или orchestration-слоем. В такой ситуации сохранение может зафиксировать промежуточное состояние, которое не должно становиться постоянным.

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

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Короткий runbook: что проверить за 5 минут

1. Проверьте версии и backend: iptables --version и nft list ruleset.
2. Посмотрите активные сервисы: systemctl status nftables и systemctl status netfilter-persistent.
3. Изучите журнал: journalctl -u netfilter-persistent -b.
4. Проверьте наличие файлов /etc/iptables/rules.v4, /etc/iptables/rules.v6, /etc/nftables.conf.
5. Сделайте ручное сохранение через нативный инструмент, а не только через обёртку.
6. Оставьте один механизм автозагрузки правил.
7. Проверьте фактический ruleset после reboot.

Что выбрать в итоге

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

Если инфраструктура давно построена вокруг iptables-save, мигрировать только ради моды не обязательно. Гораздо важнее консистентность: один backend, один способ хранения, одна процедура проверки после изменений.

И ещё один практический совет: при удалённой правке файрвола всегда держите вторую SSH-сессию и заранее планируйте rollback. Саму ошибку netfilter-persistent save failed это не исправит, но от потери доступа спасает регулярно.

Итог

Ошибка netfilter-persistent save failed почти всегда сводится к одной из трёх причин: выбран не тот инструмент для текущего стека, смешаны nftables и iptables, либо есть базовая проблема с backend, файлами или синтаксисом.

• для nftables сохраняйте правила в /etc/nftables.conf и используйте nftables.service;
• для iptables работайте через iptables-save, ip6tables-save и netfilter-persistent как обёртку;
• не держите две конкурирующие схемы автозагрузки на одном сервере;
• после изменений проверяйте не только сохранение, но и итоговое состояние после перезагрузки.

Именно такой подход обычно и решает проблемы из серии nftables rules not saved, iptables rules not persistent и netfilter-persistent failed без экзотики и бесконечной борьбы с симптомами.