Эмуляция полноценного сетевого стека с помощью Netfilter и nftables в Termux: построение кастомных firewall‑политик и NAT‑трансляций

Termux давно перестал быть «просто терминалом» и превратился в удобную лабораторную среду для сетевых экспериментов. Однако привычные сценарии администрирования Linux‑сетей (iptables/nftables, Netfilter, NAT) на мобильной платформе требуют аккуратного подхода: нужно учитывать ограничения окружения, права доступа, особенности ядра Android и корректную изоляцию тестового трафика.

В этой статье мы рассмотрим, как организовать в Termux лабораторную эмуляцию сетевого стека с акцентом на firewall‑политики и NAT‑трансляции через nftables и компоненты Netfilter. Материал ориентирован на легальные, учебные и безопасные сценарии: локальные сети, тестовые сервисы и контроль трафика в пределах собственной инфраструктуры.

Требования и предпосылки

Чтобы такие эксперименты были технически реализуемы, обычно нужны следующие условия:

Контроль окружения: Termux должен иметь возможность запускать нужные системные компоненты. В типичном случае потребуется root-права или специфические настройки устройства.
Поддержка nftables в ядре: проверьте наличие модулей ядра и доступность nft на стороне системы.
Доступ к Netfilter: для реального применения правил нужны права на управление таблицами правил и сетевыми хуками.
Четкая изоляция: любые NAT/фильтрация должны применяться в локальной тестовой схеме, чтобы избежать влияния на чужие сети.

Важно: реализация на Android зависит от версии, производителя и конфигурации ядра. Поэтому любые шаги ниже следует рассматривать как «каркас» под вашу лабораторную среду.

Концепция: что именно мы «эмулируем»

В классическом Linux‑администрировании сетевой стек и Netfilter реализуются ядром. В Termux мы не «переизобретаем» ядро, а организуем:

Зону управления: запуск утилит и конфигураций nftables из пользовательского пространства (Termux).
Политики фильтрации: правила для входящего/исходящего трафика по интерфейсам, подсетям, состояниям соединений.
NAT‑трансляции: маскарадинг и/или статический DNAT/SNAT для тестовых сервисов.
Локальную сегментацию: при необходимости — создание локальной сети (например, через VPN с функцией туннеля) строго для изоляции лаборатории.

Таким образом, «эмуляция полноценного сетевого стека» здесь означает воспроизведение практических задач сетевого администрирования (firewall, маршрутизация через NAT, контроль соединений) в рамках доступного сетевого интерфейса.

Подготовка Termux: установка утилит и базовая проверка

Начнем с минимального набора: nftables и сетевые инструменты. Обновите пакеты в Termux и установите нужные компоненты.

pkg update
pkg upgrade
pkg install nftables iproute2 netcat-openbsd procps

Проверим, что утилита nft доступна:

nft --version

Далее полезно убедиться, что есть сетевые интерфейсы и маршрутизация:

ip addr
ip route

Если вы планируете использовать NAT, нам потребуется понимание, какой интерфейс является «внешним» (к которому привязан исходящий трафик) и какой — «внутренним» (где находится тестовая подсеть/клиенты).

Структура nftables: таблицы, цепочки и правила

nftables строится из таблиц, внутри которых есть цепочки (chains). Цепочки связаны с типами обработки пакетов: фильтрация (filter), адресная трансляция (nat) и т.п.

Условная структура для нашей лаборатории:

Таблица filter для policy‑контроля трафика
Таблица nat для SNAT/DNAT/masquerade
Порядок цепочек: обычно сначала обработка маршрутизации/нат‑модификаций, затем фильтрация или наоборот — в зависимости от требуемой логики и типа хука

На практике начните с «разрешить только то, что нужно», а остальное — блокировать.

Пример: создание базовой таблицы фильтрации

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

Мы хотим разрешить только установленным соединениям проходить
Разрешить вход только к заранее заданному сервису (например, TCP порт 8080 на внутреннем интерфейсе)
Остальное блокировать

Создание таблицы и цепочек:

nft add table inet filter

nft add chain inet filter input { type filter hook input priority 0; policy drop ; }
nft add chain inet filter forward { type filter hook forward priority 0; policy drop ; }
nft add chain inet filter output { type filter hook output priority 0; policy accept ; }

Теперь добавим типовые правила:

# Разрешить петлю (loopback)
nft add rule inet filter input iif "lo" accept

# Разрешить уже установленные соединения
nft add rule inet filter input ct state established,related accept

# Разрешить вход на TCP 8080 (пример) через внутренний интерфейс
# Замените "wlan0" или нужный интерфейс на ваш внутренний
nft add rule inet filter input iif "wlan0" tcp dport 8080 accept

# Логирование можно включать точечно, чтобы не перегрузить систему
# nft add rule inet filter input log prefix "FW input: " level info

Если вы не знаете, какой интерфейс соответствует вашей лабораторной зоне, используйте ip addr и привязывайте правила к фактическим именам.

Пример: таблица nat и базовый masquerade

NAT в лаборатории обычно нужен для того, чтобы «спрятать» внутренние адреса за одним внешним адресом, или чтобы пробросить входящие соединения на внутренние сервисы.

Сначала создадим таблицу nat (inet), затем добавим цепочку postrouting:

nft add table ip nat

nft add chain ip nat postrouting { type nat hook postrouting priority 100; policy accept ; }

Masquerade для исходящего трафика от внутренней подсети через внешний интерфейс:

# Пример: внутренняя подсеть 192.168.56.0/24
# Внешний интерфейс: замените "rmnet_data0" или другой на ваш
nft add rule ip nat postrouting ip saddr 192.168.56.0/24 oif "rmnet_data0" masquerade

Важно: корректность правила зависит от реальной подсети и интерфейсов. В учебной среде обычно проще фиксировать их статически.

Проброс сервисов: DNAT для локального теста

Если вы хотите обращаться к сервису, запущенному в «внутренней» зоне, используя адрес «внешней» стороны, подойдет DNAT. Типовой сценарий:

Порт 8080 на внешнем адресе перенаправляем на внутренний хост 192.168.56.10:8080

Создадим цепочку prerouting:

nft add chain ip nat prerouting { type nat hook prerouting priority -100; policy accept ; }

Добавим DNAT:

# Перенаправление TCP 8080 на внутренний сервер
nft add rule ip nat prerouting iif "rmnet_data0" tcp dport 8080 dnat to 192.168.56.10:8080

После DNAT обязательно проверьте, что в firewall‑цепочке разрешены пакеты на соответствующий внутренний хост/интерфейс и порт.

Связка filter и nat: безопасная логика

Обычно эффективная схема выглядит так:

nat выполняет адресные трансформации (DNAT/SNAT/masquerade)
filter решает, какие пакеты разрешать дальше

Поэтому после изменения адреса (DNAT) убедитесь, что правила фильтрации опираются на корректные параметры:

интерфейс (iif/oif)
целевой порт
подходящее состояние соединений (ct state established,related)
при необходимости — подсети источников (ip saddr)

Для логирования полезно применять точечные правила и использовать log prefix ограниченно.

Управление конфигурацией: правила, проверки и откат

Чтобы работать безопасно, полезно уметь:

просматривать текущие правила
сбрасывать таблицы/цепочки
проверять счетчики (packet/byte counters)

Команды просмотра:

nft list ruleset

Проверка конкретной таблицы:

nft list table ip nat
nft list table inet filter

Для сброса тестовой конфигурации проще удалить таблицы целиком:

nft flush table ip nat
nft delete table ip nat

nft flush table inet filter
nft delete table inet filter

Так вы избегаете «призраков» старых правил и ускоряете отладку.

Создание локальной изолированной сети для лаборатории

Если требуется изоляция трафика (например, вы хотите безопасно тестировать правила, не смешивая реальные сети устройства), можно задействовать VPN‑средство для создания локальной сети в рамках вашей лаборатории. Ключевой принцип: использовать VPN только для сегментации/туннелирования в своей схеме, а не для обхода блокировок.

Далее подключаете интерфейс туннеля как «внутренний», задаете подсеть (например, 192.168.56.0/24), и ваши nftables правила начинают работать именно в пределах этого сегмента.

В конфигурациях выше заменяйте iif/oif на реальное имя интерфейса туннеля (его можно определить через ip addr после установки VPN).

Тестирование сценариев: как понять, что правила работают

После применения правил выполните проверку на трех уровнях:

Внутренний сервис: доступность по IP/порту внутри тестовой зоны
Фильтрация: разрешенные соединения должны работать, запрещенные — блокироваться
NAT: адресация должна соответствовать ожидаемой трансляции

Пример теста TCP‑доступности:

# Проверка доступности сервиса на внутреннем хосте
nc -vz 192.168.56.10 8080

Если вы сделали DNAT на внешний интерфейс, проверьте доступность через «внешний» адрес (в лабораторной схеме — адрес вашей стороны или интерфейса):

# Проверка доступности через DNAT (пример)
nc -vz <ВНЕШНИЙ_АДРЕС_ИЗ_ЛАБОРАТОРИИ> 8080

Для диагностики также смотрите счетчики правил:

nft list ruleset counters

Если счетчики не растут, значит трафик не попадает в ожидаемую цепочку/условие.

Практические рекомендации по производительности и надежности

Минимизируйте количество правил: лучше несколько точных выражений, чем длинные «лесенки» условий без индексов.
Используйте состояния conntrack: правило ct state established,related существенно упрощает фильтрацию.
Ограничивайте логирование: логирование на каждый пакет быстро перегружает вывод и диски.
Сначала разрешайте минимум: policy drop в input/forward помогает избежать случайных открытий.
Держите конфигурацию версионной: сохраняйте nft‑скрипты в файлы, чтобы быстро откатываться.

Заключение

Эмуляция практического «сетевого администрирования» в Termux через Netfilter и nftables позволяет строить контролируемые лабораторные сценарии: от строгих firewall‑политик до NAT‑трансляций (masquerade и DNAT) с последующим безопасным тестированием. Ключ к успеху — корректная привязка правил к интерфейсам и подсетям, использование conntrack и дисциплина в изоляции экспериментов.

Если вам нужно настроить nftables под вашу схему (интерфейсы Android, туннели для локальной сети, конкретные правила и таблицы) или провести аудит корректности политики — обратитесь за услугами в РыбинскЛАБ.