Когда речь заходит о сетевой защите Linux-сервера, до сих пор встречаются два мира: привычный iptables и более современный nftables. А в «облачной» реальности добавляется третий слой — cloud firewall и security groups на стороне провайдера. В результате админ может одновременно иметь правила «в облаке», правила в ядре (nft/iptables) и ещё правила, которые выглядят как iptables, но на самом деле применяются через совместимый слой iptables-nft.
Ниже — практическая раскладка: чем iptables отличается от nftables, как устроен stateful firewall в Linux, где чаще всего ломается логика inbound/outbound, и как «слоить» правила с security groups так, чтобы не получить неожиданные дырки или самоблокировку.
Три слоя фильтрации: cloud firewall, host firewall и приложение
На VDS/VM защита трафика обычно живёт сразу в нескольких местах — и это нормально, если роли чётко разделены:
- Cloud firewall / security groups — фильтрация на стороне провайдера, до попадания пакета на интерфейс VM. Удобно отсекать «лишние» публичные порты на периметре.
- Host firewall — фильтрация в самой ОС (
iptables/nftables). Тут проще учитывать интерфейсы, VPN, приватные сети, контейнерные подсети, маршрутизацию. - Уровень приложения — allowlist/ACL в сервисе (Nginx, Postgres, SSH
Matchи т.д.). Это не замена фаервола, но сильный дополнительный барьер.
Практическое правило: cloud firewall — это «грубый периметр» и страховка от человеческого фактора; host firewall — «последнее слово» перед сокетом и место для контекстной логики (включая egress).
Типичная ошибка: считать, что security groups достаточно. Минимальный stateful firewall в ОС нужен хотя бы для локальных сетей/VPN, egress-контроля и защиты от сюрпризов со стороны контейнеров и автоконфигов.
iptables в 2026: модель, сильные и слабые стороны
iptables — классический интерфейс к netfilter в ядре Linux. Он оперирует таблицами (filter, nat, mangle и др.), цепочками (INPUT, OUTPUT, FORWARD) и правилами, которые проверяются последовательно.
Сильные стороны iptables
- Проверено временем: много рецептов, документации, привычная терминология.
- Совместимость: часть софта и панелей всё ещё генерирует именно iptables-правила.
- Привычный дебаг: линейное прохождение цепочки часто проще читать «глазами».
Слабые стороны iptables
- Сложность на масштабе: большие allow/deny-листы превращаются в «простыни» правил и цепочек.
- Наборы адресов исторически через отдельную сущность: чаще всего подключали
ipset(это рабочий подход, но дополнительная поверхность управления). - Путаница с бэкендом: команда
iptablesможет управлять либо legacy-реализацией, либо nftables через совместимость (iptables-nft).
Самая частая проблема в эксплуатации: админ думает, что «правит iptables», но часть политики уехала в nftables (или наоборот). В итоге разные команды показывают «разную правду», а при перезагрузке/обновлении пакетов это может выстрелить.
Если вы поднимаете новый проект, удобнее заранее выбрать единый подход к хостовому фаерволу. На практике это проще делать на отдельной VDS, где вы полностью контролируете сеть и правила, и можете безопасно тестировать изменения через консоль/второй SSH-сеанс.
nftables: почему он вытесняет iptables
nftables — современная подсистема и язык описания правил, пришедший на смену iptables. Он унифицирует IPv4/IPv6 (family inet), даёт встроенные структуры данных (sets, maps) и позволяет применять изменения более атомарно.
Что обычно нравится в nftables
- Единые правила для IPv4/IPv6: через
inetменьше шанс «забыть IPv6». - Sets/maps — нативно: большие списки адресов/портов становятся читабельнее и легче обслуживаются.
- Атомарность: можно применять конфигурацию целиком, уменьшая риск самоблокировки при частичном применении.
- Явные хуки: цепочки привязаны к hook’ам (input/output/forward/prerouting/postrouting) и priority, легче понимать место срабатывания.
Где nftables обычно «цепляет» новичков
- Синтаксис: после iptables нужно переучиваться и менять привычки.
- Инструменты вокруг: часть экосистемы всё ещё генерирует iptables-правила, и это нужно учитывать.
- Миграция сложного NAT: перенос требует аккуратной валидации и тестового окна.
Если у вас уже есть связка контейнеров и хостового фаервола, полезно отдельно разобраться, как именно они взаимодействуют. По теме рекомендую материал: Docker и firewall: iptables/nftables без сюрпризов.
Stateful firewall: «состояния» и conntrack без магии
И iptables, и nftables умеют stateful-подход: учитывать состояние соединений через conntrack. На практике чаще всего нужны состояния:
- new — пакет инициирует новое соединение;
- established — пакет относится к уже установленному соединению;
- related — пакет связан с существующим соединением (например, некоторые служебные/вспомогательные потоки).
Польза stateful-фаервола в том, что вы разрешаете вход на конкретный сервис (new), а обратный трафик (established/related) пропускается автоматически. Это критично для корректной логики inbound/outbound и для строгого egress.
Если строите строгий outbound allowlist, всегда начинайте с разрешения established/related. Иначе «сломаете» ответы и получите эффект «порт открыт, но ничего не работает».
iptables-nft: как понять, что «iptables» на самом деле nftables
На современных дистрибутивах пакет iptables может работать в двух режимах:
- legacy — классический iptables-бэкенд;
- nft — совместимость, когда команды iptables управляют правилами nftables.
Это удобно для миграции, но опасно, если одновременно:
- часть правил пишется «нативно» через
nft, - часть — через
iptables, - а часть — вообще «прилетает» от Docker/Fail2ban/панели.
Чтобы быстро оценить ситуацию, используйте базовую диагностику:
iptables --version
update-alternatives --display iptables
nft list rulesetАдминский вывод: выберите один «источник правды» и придерживайтесь его. Если цель — nftables, фиксируйте правила в конфиге nftables, а iptables-nft оставляйте только как временную совместимость для конкретных компонентов.
Inbound/Outbound политика без самострелов: рабочий чек-лист
Надёжная политика почти всегда собирается из базовых принципов:
- Default deny на вход: запрещаем всё, разрешаем нужное.
- Established/related — в начале, чтобы не ломать ответы.
- Loopback разрешён всегда, иначе ломаются локальные сервисы и агенты мониторинга.
- Админские порты (SSH/VPN) — по возможности ограничиваем по источнику (офис/VPN/bastion).
- Egress выбираем осознанно: либо «разрешить всё», либо allowlist под задачи и требования.
Что чаще всего забывают при outbound (egress)
- DNS: приложению может требоваться UDP/TCP 53 к резолверам (или альтернативная схема, если вы её используете).
- NTP/chrony: UDP 123 для синхронизации времени (важно для TLS и корректных логов).
- Репозитории и обновления: если egress режется, закладывайте доступ к зеркалам/прокси обновлений.
- OCSP/CRL: при жёстком egress некоторые клиенты могут начинать «странно» вести себя с TLS.
Если вы активно используете списки адресов и хотите обновлять их без простоя, nftables обычно выигрывает благодаря динамическим set’ам. См. также: динамические sets в nftables для блоклистов.
Security groups vs host firewall: как не конфликтовать
Хорошая схема «слоения» выглядит так:
- В cloud firewall/security groups оставляете только необходимые публичные входящие порты (например, 80/443; SSH — по возможности только с доверенных IP).
- На хосте реализуете контекст: разные интерфейсы (public/private/VPN), межсервисные правила, docker-bridge, egress-ограничения, локальные allowlist’ы.
Важно: если вы закрыли порт «в облаке», до ОС пакет не дойдёт, и вы не увидите его в локальных логах. Поэтому при отладке «почему не коннектится» всегда проверяйте оба уровня.
Производительность и масштабирование правил: когда разница ощущается
В типовом веб-проекте разница в производительности между аккуратно настроенными iptables и nftables чаще всего не будет ключевой. Она становится заметнее, когда:
- у вас большие allow/deny-листы (сотни/тысячи сетей);
- много однотипных правил по портам/подсетям;
- нужны частые обновления правил без «мигания» политики;
- важно сопровождение IPv4+IPv6 без дублирования.
В таких случаях nftables обычно проще и безопаснее в эксплуатации: sets/maps уменьшают объём правил, а атомарность применения снижает риск временно открыть лишнее или «отрезать» себя.
Как выбрать: практичные сценарии
1) Новый сервер, правила пишете руками
Выбирайте nftables: меньше легаси, проще с IPv6, удобнее с наборами и поддерживаемостью.
2) Есть софт, который генерирует iptables
Либо оставайтесь на iptables, но зафиксируйте бэкенд (legacy или nft), либо мигрируйте на nftables и не ведите параллельно два независимых конфига.
3) Нужен строгий outbound allowlist (egress control)
Реализуемо и там, и там, но в nftables обычно проще держать большие списки и матрицу правил (sets). Главное — не забыть established/related, DNS, время и обновления.
4) Уже настроен cloud firewall и публичных портов минимум
Держите host firewall минимальным, но обязательным: loopback, состояния, явные разрешения нужных сервисов и защита от самоблокировки SSH. А периметр и «грубую» фильтрацию оставьте security groups.
Типичные ошибки при переходе на nftables
- Параллельные миры: часть правил в nftables, часть через iptables-nft, часть в legacy iptables.
- Непонимание hook/priority: правило корректное, но цепочка привязана не к тому hook или с неправильным priority.
- Забытый IPv6: «закрыли всё» для IPv4, а IPv6 остался широким. Таблицы family
inetпомогают избежать этого. - Сложный NAT без тестов: при контейнерах и маршрутизации легко получить фильтрацию «не там, где ожидали».
Отдельно проверяйте TLS-сценарии: при строгом egress иногда ломаются проверки цепочки/статуса сертификатов. Если вы планируете управлять TLS централизованно и предсказуемо, удобнее использовать нормальный сертификат и понятный цикл продления. На практике это проще закрывать через SSL-сертификаты под ваш домен и сервисы.
Итоги: короткий выбор iptables vs nftables
iptables — нормальный выбор для легаси и совместимости, если схема уже работает и у вас есть инструменты, завязанные на iptables. Но критично понимать бэкенд (legacy или nft) и не смешивать источники правил.
nftables — предпочтительный выбор для новых инсталляций и для систем, где важны поддерживаемость и масштабирование: единая логика для IPv4/IPv6, удобные sets, атомарность и более чистая модель хуков.
В связке с cloud firewall/security groups лучший результат даёт слоистая защита: периметр режем в облаке, контекст и egress — на хосте, а критичные сервисы дополнительно ограничиваем на уровне приложений.
Если нужно принять решение быстро: для новой VDS берите nftables и держите правила «истиной» в одном месте. Cloud firewall используйте как внешний периметр, а не как единственный слой защиты.
