iptables: разбор старых правил и миграция на nftables

Старый файрвол на сервере или домашнем роутере часто живёт годами: правила добавлялись «на минутку», часть из них устарела, а часть конфликтует с новыми. Переход на nftables не должен начинаться с команды flush ruleset. Сначала нужно понять, что реально работает, сохранить счётчики и только потом переводить правила. Ниже — практический разбор унаследованного набора iptables и пошаговая миграция без потери доступа к машине. Общая настройка nftables с нуля здесь не рассматривается: важен именно перенос работающего набора.

Два iptables в одной системе

Современные дистрибутивы поставляют iptables как обёртку над nftables (iptables-nft), но рядом может остаться и классический iptables-legacy. Это разные наборы правил: команда iptables -L показывает только тот бэкенд, на который указывает альтернатива. Первым делом выясните, с чем вы имеете дело.

iptables --version
update-alternatives --display iptables
iptables-save -c | head -40

Строка (nf_tables) означает, что правила лежат в общем хранилище nftables, а (legacy) — что используется старый модуль. На Debian и Ubuntu переключение выполняют через update-alternatives --config iptables; на RHEL и производных смотрят установленные пакеты и не смешивают iptables-services с nftables.

Инвентаризация правил

iptables-save даёт машинно-читаемый снимок, а iptables -S — те же правила в виде команд. Для анализа полезны счётчики: они показывают, какие правила действительно срабатывали с момента загрузки.

sudo iptables -S
sudo iptables -L -n -v --line-numbers
sudo iptables-save -c > ~/iptables-backup-$(date +%F).rules

Не спешите удалять правила с нулевыми счётчиками. Счётчик обнуляется при перезагрузке и после iptables -Z, а редкое правило может просто ждать своего события. Сначала снимите статистику, поработайте неделю и сравните показания. Отдельно проверьте политики цепочек: DROP на INPUT без разрешения для SSH — классическая причина потерять доступ.

Обратите внимание на порядок. В iptables срабатывает первое подходящее правило, поэтому ранний ACCEPT делает бесполезными все последующие запреты. Комментарии -m comment --comment упрощают разбор, но в старых наборах их часто нет. Выпишите сервисы, доступные снаружи, и сверьте с правилами.

Где хранятся правила

Само по себе работающее правило исчезнет после перезагрузки, если его не сохранили. В Debian и Ubuntu этим занимается netfilter-persistent, файлы лежат в /etc/iptables/rules.v4 и rules.v6. В RHEL-семействе — /etc/sysconfig/iptables. Проверьте, какой механизм включён, иначе после миграции вы получите два конкурирующих набора.

systemctl status netfilter-persistent
ls -l /etc/iptables/rules.v4 /etc/sysconfig/iptables
sudo iptables-restore --test < /etc/iptables/rules.v4

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

Что мешает механическому переводу

Утилита iptables-restore-translate преобразует сохранённый набор в синтаксис nftables. Она справляется с большинством цепочек, match-модулей и target’ов, но результат нужно читать, а не применять вслепую. Матчи вроде recent, отдельные возможности owner и нестандартные target’ы могут потребовать ручной переписки через множества и meta-выражения.

iptables-restore-translate -f ~/iptables-backup-2026-11-06.rules > ~/migrated.nft
iptables-translate -t nat -A POSTROUTING -o eth0 -j MASQUERADE
grep -nE 'recent|owner|TEE|TPROXY' ~/iptables-backup-2026-11-06.rules

Вторая команда переводит одно правило и удобна для проверки спорных мест. Третья ищет в исходнике конструкции, которые почти наверняка потребуют внимания. Не забывайте про IPv6: правила ip6tables переводятся отдельно, и «забытый» IPv6 — распространённая дыра при миграции. Отдельная ловушка — NAT: в nftables цепочки привязываются к хукам prerouting и postrouting, и при ручной правке легко потерять masquerade.

Установка nftables и проверка синтаксиса

Пакет nftables обычно уже установлен. Конфигурация по умолчанию — /etc/nftables.conf; в Debian и Ubuntu служба читает его при старте. Перед применением обязательно запустите проверку: nft -c разбирает файл и сообщает об ошибках, ничего не меняя.

sudo apt install nftables
sudo nft -c -f ~/migrated.nft
sudo nft -f ~/migrated.nft
sudo nft list ruleset -a

Если проверка прошла, правила применяются атомарно. Ключ -a показывает handles — по ним удобно удалять отдельные элементы. Сохраните рабочий набор в /etc/nftables.conf и включите службу, иначе после перезагрузки останется пустой файрвол. Перед включением проверьте правило для SSH и доступ по консоли.

Проверка паритета

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

sudo nft list ruleset
sudo conntrack -L 2>/dev/null | head -20
ss -tlnp

Проверяйте с внешнего хоста, а не с самого сервера: локальные запросы обходят часть цепочек. Для отладки конкретного пакета в nftables есть трассировка: временное правило с meta nftrace set 1 и команда nft monitor trace показывают путь пакета по цепочкам. Не оставляйте трассировку включённой — она заметно нагружает систему.

Сосуществование и откат

Главное правило: не держите два активных набора правил. iptables-nft и нативный nftables пишут в одно пространство таблиц, поэтому nft list ruleset покажет и правила Docker, и ваши цепочки. iptables-legacy живёт отдельно и может незаметно фильтровать трафик параллельно. Перед миграцией выясните, кто ещё управляет файрволом: Docker, libvirt, Kubernetes, fail2ban.

Docker на современных дистрибутивах использует iptables-nft и создаёт собственные цепочки. Если вы вручную переписываете таблицу filter, не удаляйте цепочки DOCKER-* и не отключайте net.ipv4.ip_forward: контейнеры потеряют сеть. Лучше добавлять свои правила в отдельную цепочку и вызывать её из INPUT.

План отката готовится заранее: сохранённый iptables-save, доступ по второму SSH-порту или консоли, отключённая служба nftables. Если после перезагрузки доступ пропал, вернуть старый набор можно через iptables-restore и переключение альтернативы.

Чек-лист миграции

• Определите бэкенд: legacy или nft.
• Сохраните правила и счётчики в отдельный файл.
• Найдите все места, где правила создаются автоматически.
• Переведите IPv4 и IPv6 отдельно.
• Проверьте файл через nft -c до применения.
• Протестируйте доступ с внешнего хоста.
• Включите автозагрузку и проверьте поведение после перезагрузки.
• Оставьте план отката на неделю.

Итог

Миграция с iptables на nftables — это не переписывание команд, а инвентаризация того, что накопилось. Снимок со счётчиками, проверка синтаксиса и тест с внешнего хоста занимают меньше времени, чем восстановление доступа после неудачного flush. Переводите правила постепенно, не смешивайте бэкенды и держите сохранённый старый набор под рукой.