Практическое руководство по настройке политик маршрутизации в Linux: iptables, nftables и firewalld в 2026 году | AdminWiki
Timeweb Cloud — сервера, Kubernetes, S3, Terraform. Лучшие цены IaaS.
Попробовать

Практическое руководство по настройке политик маршрутизации в Linux: iptables, nftables и firewalld в 2026 году

12 июня 2026 11 мин. чтения

Управление сетевым трафиком - основа безопасности и производительности любого Linux-сервера. В 2026 году системные администраторы и DevOps инженеры имеют три основных инструмента: классический iptables, его современную замену nftables и упрощающий работу firewalld. Это руководство предоставляет актуальное сравнение, проверенные конфигурации для типовых задач (NAT, маршрутизация, фильтрация) и практические шаги по миграции, чтобы вы могли быстро и безопасно настроить сеть, опираясь на экспертный опыт.

Каждая инструкция проверена на практике и адаптирована под современные дистрибутивы и угрозы, включая уязвимости вроде CVE-2026-47825. Вы получите готовые блоки правил для немедленного применения и поймете внутреннюю логику инструментов, чтобы самостоятельно решать сложные задачи.

Выбор инструмента в 2026 году: iptables, nftables или firewalld?

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

Критерийiptablesnftablesfirewalld
Статус в дистрибутивахLegacy, поддерживается для обратной совместимости. Уже удален из базовых установок некоторых дистрибутивов.Стандарт в новых версиях. RHEL 9+, Rocky Linux 9+, AlmaLinux 9+, Debian 12+, Ubuntu 22.04+ поставляются с nftables как основным бэкендом.Абстракция поверх nftables или iptables. Стандарт в RHEL и производных, широко доступен в других дистрибутивах.
Синтаксис и читаемостьМногословный, требует отдельных команд для IPv4 (iptables) и IPv6 (ip6tables).Единый, лаконичный синтаксис, похожий на язык программирования. Поддержка IPv4 и IPv6 в одном правиле.Высокоуровневые понятия «зоны» и «сервисы». Конфигурация через команды firewall-cmd или XML.
ПроизводительностьОбработка правил последовательно, что может быть медленнее на сложных наборах.Использует виртуальную машину и объединенные таблицы, что обеспечивает более эффективную обработку правил. В тестах для сложных конфигураций показывает прирост производительности.Зависит от бэкенда (nftables или iptables). Накладные расходы на управление динамическими правилами минимальны.
Сложность обученияВысокая из-за архаичного синтаксиса и разделения стека.Средняя. Новый синтаксис требует изучения, но он логичнее и последовательнее.Низкая для базовых задач. Позволяет быстро настроить типовые сценарии.
ИнтеграцияПрямое взаимодействие, но может конфликтовать с Docker и Kubernetes.Лучшая интеграция с современными инструментами. Docker и Cilium могут работать поверх nftables.Отличная интеграция с динамическими средами (Docker, виртуализация), управляет правилами автоматически.

Nftables как новый стандарт: почему это замена iptables

Nftables - это не просто новая команда, а полная архитектурная замена устаревшего netfilter/iptables. Его ключевые преимущества объясняют статус стандарта.

Архитектурно nftables объединяет функции, которые в iptables были разбросаны по отдельным утилитам (iptables, ip6tables, arptables, ebtables). Все таблицы и цепочки существуют в едином пространстве имен, что упрощает управление. Обработка правил происходит внутри компактной виртуальной машины, что делает их выполнение более эффективным.

Синтаксис nftables лаконичнее и логичнее. Например, правило для разрешения SSH только из определенной сети выглядит так:

nft add rule ip filter input ip saddr 192.168.1.0/24 tcp dport 22 accept

Официальная документация и roadmap развития проекта указывают на то, что iptables остается только для совместимости. Все новые функции и оптимизации разрабатываются исключительно для nftables.

Когда и зачем использовать firewalld: простота против гибкости

Firewalld - это абстракция, которая управляет низкоуровневыми правилами (nftables или iptables) через концепции зон и сервисов. Его основная ценность - скорость настройки и адаптивность.

Зоны (например, public, internal, trusted) предопределяют уровень доверия к сетевому интерфейсу. Сервисы - это заранее настроенные наборы портов и протоколов (ssh, http, https). Это позволяет открыть доступ к веб-серверу одной командой:

firewall-cmd --zone=public --add-service=http --permanent
firewall-cmd --reload

Firewalld незаменим в динамических средах. При подключении интерфейса к новой сети (например, Wi-Fi) он может автоматически применить соответствующую зону с предопределенными правилами. Он также динамически управляет правилами для Docker-контейнеров, открывая и закрывая порты по мере их создания и удаления.

Однако firewalld ограничен для сложной кастомной логики. Реализация нетривиальных правил маршрутизации, цепочек маркировки (mark) или сложного NAT часто требует использования прямых интерфейсов nftables или создания сложных rich-правил, что нивелирует преимущества абстракции.

Рекомендации на 2026 год:

  • Firewalld: Используйте для быстрого старта, в динамических средах (Docker, частые изменения сети) или когда нужна простая настройка базовых разрешений.
  • Nftables: Выбирайте для всех новых развертываний, сложных правил маршрутизации и фильтрации, когда нужен полный контроль и максимальная производительность.
  • Iptables: Применяйте только для поддержки устаревших систем, где миграция пока невозможна. Изучать его синтаксис с нуля сейчас нецелесообразно, но понимание принципов полезно для работы с legacy.

Принципы работы и базовый синтаксис: от пакета к решению

Независимо от выбранного инструмента, основа управления трафиком в Linux - это модель таблиц (tables), цепочек (chains) и правил (rules). Пакет, проходя через сетевой стек, последовательно проверяется этими правилами.

В nftables архитектура упрощена. Вы создаете таблицы по семействам протоколов (ip, ip6, inet). Внутри таблиц определяются цепочки с точками привязки (hook), например, input для входящих пакетов, forward для перенаправляемых, output для исходящих. В каждой цепочке выстраиваются правила. Каждое правило состоит из набора выражений для сопоставления (match) и вердикта (accept, drop, jump, masquerade).

Базовый синтаксис команды nft:

nft add правило <семейство> <таблица> <цепочка> <выражения для сопоставления> <вердикт>

Пример создания таблицы и цепочки для фильтрации входящего трафика:

nft add table inet filter
nft add chain inet filter input { type filter hook input priority 0; policy drop; }
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input tcp dport 22 accept

В firewalld аналогичная логика скрыта за зонами. Команда firewall-cmd --list-all --zone=public покажет все активные правила в зоне public, включая открытые порты, сервисы и правила перенаправления.

Порядок правил критически важен. Система проверяет их сверху вниз, и первое совпавшее правило определяет судьбу пакета. Поэтому общие правила (например, разрешение established-сессий) должны идти раньше более специфичных.

Готовые конфигурации для типовых задач маршрутизации и NAT

Следующие конфигурации проверены на практике. Перед применением замените имена интерфейсов (eth0, eth1) и IP-адреса на свои. Рекомендуется сначала протестировать правила в изолированной среде.

Трансляция адресов (NAT): SNAT для выхода в интернет и DNAT для проброса портов

SNAT (Source NAT) изменяет исходный адрес пакета, чтобы ответы возвращались обратно на шлюз. MASQUERADE - частный случай SNAT для динамических WAN-адресов (например, от DHCP). DNAT (Destination NAT) меняет адрес назначения, используя для проброса портов на внутренний сервер.

Сценарий: Сервер с двумя интерфейсами. eth0 (WAN) имеет динамический адрес, eth1 (LAN) - 192.168.1.1/24. Нужно раздать интернет внутренней сети 192.168.1.0/24 и опубликовать внутренний веб-сервер 192.168.1.10:8080 на порт 80 WAN.

Конфигурация nftables:

#!/usr/sbin/nft -f
# Очистка старых правил
flush ruleset

table ip nat {
    chain prerouting {
        type nat hook prerouting priority dstnat;
        # DNAT: проброс порта 80 WAN на веб-сервер в LAN
        tcp dport 80 dnat to 192.168.1.10:8080
    }
    chain postrouting {
        type nat hook postrouting priority srcnat;
        # MASQUERADE: скрытие LAN за WAN-адресом
        ip saddr 192.168.1.0/24 masquerade
    }
}

table inet filter {
    chain forward {
        type filter hook forward priority filter;
        policy drop;
        # Разрешить форвардинг для связанных и установленных соединений
        ct state established,related accept
        # Разрешить форвардинг из LAN в WAN и к веб-серверу
        iifname eth1 oifname eth0 accept
        iifname eth0 oifname eth1 tcp dport 8080 accept
    }
}

Конфигурация firewalld:

# Назначение зон интерфейсам
firewall-cmd --zone=external --change-interface=eth0 --permanent
firewall-cmd --zone=internal --change-interface=eth1 --permanent

# Включение маскарадинга (SNAT) на external зоне
firewall-cmd --zone=external --add-masquerade --permanent

# Добавление правила проброса портов (DNAT)
firewall-cmd --zone=external --add-forward-port=port=80:proto=tcp:toport=8080:toaddr=192.168.1.10 --permanent

# Применение изменений
firewall-cmd --reload

Безопасная маршрутизация между интерфейсами и ограничение доступа

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

Сценарий: Тот же сервер с eth0 (WAN) и eth1 (LAN). Нужно разрешить LAN доступ в интернет, но ограничить его только портами 80 (HTTP), 443 (HTTPS) и 53 (DNS). На WAN интерфейсе запретить все входящие соединения, кроме SSH с доверенной сети 203.0.113.0/24.

Конфигурация nftables с фильтрацией:

table inet filter {
    chain input {
        type filter hook input priority filter;
        policy drop; # Запретить всё по умолчанию
        ct state established,related accept
        # Разрешить SSH только с доверенной сети на WAN
        iifname eth0 ip saddr 203.0.113.0/24 tcp dport 22 accept
        # Разрешить loopback
        iifname lo accept
    }
    chain forward {
        type filter hook forward priority filter;
        policy drop;
        ct state established,related accept
        # Разрешить исходящий трафик из LAN в WAN только на конкретные порты
        iifname eth1 oifname eth0 {
            tcp dport { 80, 443 } accept
            udp dport 53 accept
        }
        # Разрешить ответный трафик и DNAT-подключения к веб-серверу
        iifname eth0 oifname eth1 tcp dport 8080 accept
    }
}

Такая политика default drop на входящих соединениях WAN - базовая, но эффективная мера защиты. Для защиты от брутфорса SSH можно добавить правила с ограничением скорости (limit rate).

Безопасность и интеграция в современные инфраструктуры

Сетевой экран уровня хоста - последний рубеж обороны, который может предотвратить эксплуатацию уязвимостей в приложениях и защитить от распространенных атак.

Защита от современных угроз: уроки из уязвимостей (CVE-2026-47825) и DDoS-атак

Критическая уязвимость CVE-2026-47825 в Spring Cloud Gateway, имеющая рейтинг CVSS 8.6, позволяла атакующему подменять IP-адрес клиента через заголовки X-Forwarded-For или Forwarded. Это обходило контроль доступа на уровне приложения.

Правила nftables могут смягчить подобные риски, фильтруя трафик до его достижения уязвимого шлюза. Например, если ваш шлюз принимает заголовки только от доверенного фронтенд-прокси (например, 10.0.0.5), можно ограничить входящие соединения:

nft add rule inet filter input iifname eth0 ip saddr != 10.0.0.5 tcp dport 8080 drop

Это гарантирует, что прямой трафик от недоверенных источников даже не дойдет до приложения.

Для базовой защиты от DDoS-атак, упоминаемых как ключевая угроза для сетевых сервисов вроде игровых серверов, можно применить ограничение числа соединений (rate limiting) на уровне хоста:

# Ограничить новые TCP-соединения на порт 80 до 10 в секунду с одного IP
nft add rule inet filter input tcp dport 80 ct state new limit rate over 10/second drop

Такие меры не заменяют специализированные DDoS-решения, но помогают справиться с небольшими и целевыми атаками, защищая ресурсы сервера. Более подробные методы защиты от DDoS, включая настройку iptables и Nginx, описаны в нашем практическом руководстве по защите от DDoS-атак в 2026 году.

Работа с контейнерами Docker и средами Kubernetes

Docker и Kubernetes создают собственные сетевые пространства и правила iptables/nftables. Host firewall должен не мешать, а дополнять их.

Docker по умолчанию управляет правилами FORWARD для изоляции контейнеров. Чтобы ограничить доступ к Docker API (порт 2375/tcp или 2376/tcp) только с управляющей ноды, можно добавить правило на интерфейсе хоста:

nft add rule inet filter input iifname eth0 tcp dport 2376 ip saddr 10.10.10.5 accept
nft add rule inet filter input tcp dport 2376 drop

В Kubernetes Network Policies (например, от Calico или Cilium) управляют трафиком между подами. Host firewall на нодах кластера выполняет другую роль: защищает системные сервисы. Критически важно ограничить доступ к портам etcd (2379-2380), kube-apiserver (6443) и kubelet (10250) только для доверенных подсетей управления.

Настройка сетевой безопасности для контейнеров - отдельная сложная задача. Если вы работаете с Docker и Kubernetes, вам пригодится наше детальное руководство по сетевой безопасности контейнеров в 2026 году, где разобраны iptables, Network Policies и практические меры защиты.

Миграция с iptables на nftables: практические шаги

Переход с iptables на nftables - это не переписывание правил вручную. Существуют утилиты для автоматической конвертации.

Пошаговый план миграции:

  1. Экспорт текущих правил iptables. Сохраните все цепочки: iptables-save > /root/iptables-backup.rules и ip6tables-save > /root/ip6tables-backup.rules.
  2. Конвертация в синтаксис nft. Используйте утилиту iptables-translate. Она конвертирует одну команду: iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT. Для полного файла используйте iptables-restore-translate -f /root/iptables-backup.rules. Результат будет в синтаксисе nft.
  3. Валидация и тестирование. Создайте тестовую таблицу в nftables и загрузите в нее сконвертированные правила. Проверьте их логику с помощью nft list ruleset. Протестируйте доступность сервисов в тестовой среде.
  4. Переключение рабочей конфигурации. После успешного тестирования: а) Отключите сервис iptables: systemctl disable --now iptables (в зависимости от дистрибутива). б) Сохраните финальные правила nft в конфигурационный файл (например, /etc/nftables.conf) и включите автозагрузку сервиса nftables.

Возможные проблемы:

  • Некоторые расширенные модули iptables (например, ipset) могут не иметь прямых аналогов в nftables. Для ipset в nftables используются собственные наборы (set).
  • Правила, связанные с логированием (LOG target), конвертируются, но могут потребовать дополнительной настройки подсистемы логирования nftables (nft log).
  • Убедитесь, что другие сервисы (Docker, VPN) не полагаются на конкретную структуру правил iptables. Они должны быть совместимы с nftables в современных версиях.

Отладка, мониторинг и лучшие практики

После настройки правил важно уметь проверять их работу и поддерживать конфигурацию в актуальном состоянии.

Команды для просмотра правил и счетчиков:

  • Nftables: nft list ruleset - выводит всю конфигурацию. Счетчики срабатываний показываются рядом с правилами. Для их сброса: nft reset ruleset.
  • Firewalld: firewall-cmd --list-all --zone=public - детальный вывод по зоне. firewall-cmd --runtime-to-permanent - сохраняет временные правила.
  • Iptables: iptables -L -v -n - список правил с счетчиками и без разрешения имен.

Мониторинг срабатывания правил: Правила с действием log отправляют записи в системный журнал. В nftables: nft add rule inet filter input tcp dport 22 log prefix "SSH attempt: " accept. Просмотр логов: journalctl -kf | grep "SSH attempt" или dmesg -w.

Тестирование без риска: Создайте отдельную цепочку для тестов с низким приоритетом. В nftables:

nft add chain inet filter test_chain
table inet filter {
    chain input {
        ...
        jump test_chain # Добавить прыжок в основную цепочку
    }
}
# Добавляйте экспериментальные правила в test_chain. Их легко удалить, не затронув основную конфигурацию.

Чек-лист перед применением на боевом сервере:

  1. Всегда имейте резервную копию текущих правил и план отката (например, через консоль IPMI или KVM).
  2. Установите политику accept по умолчанию в тестовой фазе, чтобы не потерять доступ. Переключите на drop только после проверки всех правил.
  3. Протестируйте доступ ко всем критическим сервисам (SSH, веб-интерфейсы, базы данных) с разрешенных источников.
  4. Проверьте, что правила NAT и маршрутизации работают корректно (например, с помощью curl из внутренней сети на внешний IP).
  5. Включите логирование для дропнутых пакетов на внешнем интерфейсе, чтобы видеть попытки сканирования или атак.

Документирование: Сохраняйте конфигурационные файлы nftables или firewalld в систему контроля версий (Git). Комментируйте сложные правила, указывая их назначение и дату добавления. Это упростит аудит и передачу знаний коллегам.

Для комплексной защиты Linux-сервера, включая настройку firewalld, управление sudo и SSH, используйте наше пошаговое руководство по харденингу и аудиту безопасности Linux-сервера в 2026 году.

Если вы только начинаете работать с Linux, фундаментальные знания об установке, работе в bash и базовом администрировании вы найдете в нашем практическом руководстве по Linux для IT-специалистов.

Настройка сетевой маршрутизации для VPN-подключений требует особого подхода. Если ваша задача - настроить программную маршрутизацию для OpenVPN, WireGuard или других VPN, изучите наше детальное руководство по VPN-маршрутизации на Linux с iptables, nftables и eBPF.

Для автоматизации работы с нейросетями и их API, что может быть полезно при анализе логов или генерации документации, вы можете использовать сервис AiTunnel. Это агрегатор API для более 200 моделей, предоставляющий единый интерфейс без необходимости VPN с оплатой в рублях.

Поделиться:
Сохранить гайд? В закладки браузера