Фаервол на сервере чаще всего вспоминают в плохой момент: когда отвалился SSH после “небольшой правки”, когда после перезагрузки правила исчезли, или когда Docker внезапно начал жить своей жизнью. В 2026-м путаница обычно не из-за кривых рук, а потому что iptables и nftables могут сосуществовать, маскироваться друг под друга и по-разному сохранять конфигурацию. Разберемся, что реально выбрать на VPS, как не закрыть себе доступ и как перейти на nftables спокойно.

В чем разница на практике

iptables — старый, привычный инструмент. Его любят за то, что под него тысячи гайдов, скриптов и готовых “вставил и работает”. Но он тяжело масштабируется по логике: большие правила превращаются в кашу, наборы IP делать неудобно, а поддержка через месяцы становится пыткой.

nftables — более современный фаервол. Он быстрее в поддержке, удобнее в структуре и в целом лучше подходит для продакшна, потому что конфиг получается цельным, читаемым и нормально обновляется. На свежих Debian и Ubuntu он часто уже является “первым классом”, а iptables может работать через слой совместимости, что и создает эффект: “я правил одно, а изменилось другое”.

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

Как понять, что у тебя сейчас

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

sudo nft list ruleset
sudo iptables -S
sudo iptables -V

Если nft list ruleset показывает живой набор таблиц и цепочек, а в iptables пусто или странно — ты уже в nft-мире. Если наоборот, значит сервер живет на iptables или legacy-режиме.

Минимальный nftables, который не отрежет SSH

Ниже конфигурация для типичного VPS: SSH и веб открыты, все остальное закрыто. Она подойдет для Debian 12 и Ubuntu 24.04.

sudo apt-get update
sudo apt-get install -y nftables
sudo systemctl enable --now nftables

Записываем правила в системный конфиг:

sudo tee /etc/nftables.conf >/dev/null <<'EOF'
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority 0;
    policy drop;

    ct state established,related accept
    iif lo accept

    tcp dport 22 accept
    tcp dport {80, 443} accept

    ip protocol icmp accept
    ip6 nexthdr icmpv6 accept
  }

  chain forward {
    type filter hook forward priority 0;
    policy drop;
  }

  chain output {
    type filter hook output priority 0;
    policy accept;
  }
}
EOF

sudo nft -f /etc/nftables.conf
sudo nft list ruleset

Как проверить, что все ок: SSH-сессия не должна оборваться, сайт должен открываться по 80/443, а nft list rulesetдолжен показывать таблицу inet filter с policy drop на input.

Как перенести правила с iptables без сюрпризов

Если iptables у тебя уже настроен и работает, не надо “рубить” его за один заход. Первое, что стоит сделать — снять текущую картину:

sudo iptables -S

Чтобы быстрее собрать аналог в nftables, можно переводить отдельные правила и понимать, как оно выглядит “в новом синтаксисе”:

sudo iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT

Так миграция идет по-человечески: ты не угадываешь, а сверяешься. Дальше логика простая: повторяешь критичные входящие правила (SSH, веб, панели, нужные порты), проверяешь доступность, только потом чистишь лишнее.

Частые поломки и как чинить за минуту

Самый популярный фейл — включили drop и забыли открыть SSH. Если доступ еще есть, моментально добавь правило:

sudo nft add rule inet filter input tcp dport 22 accept

Вторая частая история — после перезагрузки правила “исчезли”. Обычно виноват сервис или конфиг не подхватился. Проверка:

sudo systemctl status nftables --no-pager
sudo nft list ruleset

С Docker отдельный нюанс: он может создавать свои цепочки и менять маршрутизацию трафика. Если у тебя контейнеры и сложная сетка, правила нужно проверять после старта Docker, а не “в вакууме”.

Фаервол — это не “для галочки”. Он решает две вещи: не дает лишнему трафику долбить сервисы и помогает не угробить доступ к серверу. На практике большинство проблем — это не атаки, а человеческий фактор: миграция, обновление, перезагрузка, конфликт инструментов. В HSTQ такие вещи выгодно закрывать “под ключ”: мы поставим и настроим nftables или аккуратно оставим iptables там, где это разумно, проверим сохранение правил после ребута, учтем Docker/панели/прокси, и оставим понятный конфиг, который ты не возненавидишь через месяц.

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