We detected you are likely not from a Russian-speaking region. Would you like to switch to the international version of the site?

  Назад к списку статей

Тонкая настройка и применение WireGuard + nftables для построения изолированных pentest‑песочниц на Android‑устройствах

Пентест‑работа на Android часто упирается не только в утилиты, но и в управляемость сетевого окружения. Без изоляции результаты тестов могут смешиваться с обычной активностью устройства, усложняется воспроизведение сценариев, а риски утечек (скрытых DNS‑запросов, непредусмотренных соединений, доступа к локальной сети) возрастают.

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

Архитектура решения (высокоуровнево)

Цель — добиться следующих свойств:

  • Сегментация: «песочница» отделена от основной сети устройства.
  • Контроль egress/ingress: nftables ограничивает, какие направления разрешены, и какие пакеты/порты допустимы.
  • Предсказуемый маршрут: трафик песочницы принудительно направляется через WireGuard.
  • Наблюдаемость: проще логировать и диагностировать, где именно происходят блокировки/разрешения.

Типовая схема:

  1. В Termux поднимается WireGuard‑интерфейс (туннель) для изолированного сегмента.
  2. nftables применяет правила к трафику в песочном сегменте: DNS, TCP/UDP, запрет латерального доступа.
  3. Маршруты (и при необходимости отдельные таблицы/цепочки) направляют выход песочницы в туннель.
  4. При старте/остановке песочницы правила nftables обновляются согласованно с состоянием WireGuard.

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

Реализация в Termux зависит от вашей конфигурации Android‑устройства, разрешений и возможностей системы сетевого стека. В реальных проектах мы обычно фиксируем:

  • Поддержку nftables (в зависимости от сборки/наличия бинарников в Termux или через пакеты).
  • Доступ к необходимым возможностям ядра (туннельные устройства, netfilter).
  • Постоянство настроек: на некоторых устройствах после перезапуска требуется повторная инициализация WireGuard и правил.

Рекомендуется сначала отладить отдельные компоненты (WireGuard поднимается, интерфейс появился; nftables правила применяются; DNS ходит туда, куда ожидаете), и только затем собирать их в единую песочницу.

Шаг 1. Проектирование адресации и ключей WireGuard

Начните с адресного плана. Даже если вы строите «локальную» сеть, лучше задать отдельную подсеть для песочницы, чтобы политики nftables были проще и проверяемее.

Пример логики адресации:

  • Подсеть песочницы: 10.44.0.0/24
  • Android‑клиент (Termux): 10.44.0.2/32
  • Точка выхода (может быть ваш сервер/маршрутизатор): 10.44.0.1/32

Ключи WireGuard генерируются один раз и затем используются в конфигурациях. На практике удобно хранить ключи в защищённом месте и ограничивать доступ к файлам в Termux.

Шаг 2. WireGuard‑конфигурация для локальной песочницы

Ниже показан шаблон конфигурации wg0.conf. Актуальные значения (IP сервера, публичный ключ, allowed IPs) вы подставляете из своей локальной схемы.

[Interface]
Address = 10.44.0.2/32
PrivateKey = <ANDROID_PRIVATE_KEY>
DNS = 10.44.0.1

# При необходимости можно включить настройки по поведению туннеля.
# Например: ListenPort = 51820

[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
AllowedIPs = 10.44.0.0/24
Endpoint = <SERVER_LAN_OR_VPN_ENDPOINT>:51820
PersistentKeepalive = 25

Примечание по AllowedIPs: задавайте только те подсети, которые реально должны быть доступны из песочницы. Это уменьшает «площадь» ошибочных маршрутов.

Шаг 3. Поднятие WireGuard в Termux

После подготовки файла конфигурации инициируйте интерфейс туннеля. В Termux конкретные команды зависят от того, как у вас установлен WireGuard, но общая логика следующая:

# Пример: положите конфиг в /data/data/.../wg0.conf
# и используйте wg-quick (если доступен) либо wg напрямую.

# Вариант через wg-quick (если установлен):
# (путь к конфигу может отличаться)
wg-quick up wg0

# Проверка состояния:
wg show

После успешного поднятия убедитесь, что интерфейс появился и адрес назначен.

ip a
ip route

Шаг 4. nftables: базовая политика для изоляции

nftables будет выполнять роль «сторожа». Идея: по умолчанию блокировать то, что не разрешено, и затем точечно открыть необходимые сервисы.

Практически мы делаем 2 уровня защиты:

  • Локальная политика песочницы: запреты/разрешения на уровне интерфейсов (wg0) и маршрутизации.
  • Контроль DNS и прикладного трафика: чтобы не было «утечек» DNS не в тот резолвер.

Шаг 4.1. Создание набора (сетевых идентификаторов песочницы)

Удобно маркировать песочницу по интерфейсу WireGuard (wg0) либо по исходным диапазонам IP. Интерфейсный подход обычно проще: если трафик должен быть только через туннель — всё, что пытается уйти «мимо», блокируем.

Ниже пример базовой схемы таблиц/цепочек.

Шаг 4.2. Пример nftables правил: строгий контроль

Ниже — пример, который вы адаптируете под свои интерфейсы и желаемые разрешения. Он демонстрирует ключевую идею: правила по умолчанию блокируют, затем разрешают ограниченный набор.

#!/usr/sbin/nft -f

flush ruleset

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

    # Разрешаем loopback
    iif lo accept

    # Разрешаем трафик на туннельный интерфейс (если нужно)
    iifname "wg0" accept

    # При необходимости: разрешить локальные служебные порты
    # tcp dport 22 accept
  }

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

    # В песочнице обычно разрешаем forward только через wg0
    iifname "wg0" accept
    oifname "wg0" accept
  }

  chain output {
    type filter hook output priority 0;
    policy drop;

    # Разрешаем DNS ТОЛЬКО через туннель (пример)
    # Подставьте IP DNS, который вы указали в WireGuard конфиге
    ip daddr 10.44.0.1 udp dport 53 accept
    ip daddr 10.44.0.1 tcp dport 53 accept

    # Разрешаем соединения песочницы через wg0
    # Вариант A: разрешить исходящий трафик на адреса подсети песочницы
    ip daddr 10.44.0.0/24 oifname "wg0" accept

    # Разрешить обратную сторону: пакеты ответа
    # (как минимум это часто обеспечивается состоянием conntrack, см. следующий пример)
  }
}

Для корректной работы с состояниями обычно добавляют conntrack. Если вы видите проблемы с ответными пакетами, расширьте правила по состояниям (часто это критично для forward/output).

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

    ct state established,related accept

    iif lo accept

    # Разрешение DNS через туннель
    ip daddr 10.44.0.1 udp dport 53 accept
    ip daddr 10.44.0.1 tcp dport 53 accept

    # Разрешаем нужные назначения из песочницы
    ip daddr 10.44.0.0/24 oifname "wg0" accept
  }
}

Шаг 5. Приведение маршрутизации к туннелю (без сюрпризов)

Даже с nftables важно, чтобы маршруты не создавали «обходы». Иначе вы получите ситуацию: правила блокируют, трафик «ломается», а причина неочевидна.

Проверьте таблицу маршрутов после поднятия WireGuard. Убедитесь, что подсеть песочницы указывает в сторону wg0.

ip route show
ip rule show

Если у вас есть несколько интерфейсов/маршрутов, иногда используют отдельные таблицы маршрутизации и правила ip rule, чтобы песочница стабильно ходила только через туннель. Это уже точечная настройка под вашу топологию.

Шаг 6. Сценарий «старт/стоп песочницы»

Хорошая практика — сделать команды управления песочницей идемпотентными: один сценарий поднимает WireGuard и применяет nftables, другой — снимает правила и останавливает туннель.

Пример логики (псевдоскрипт):

# start-sandpit.sh
wg-quick up wg0
nft -f /path/to/sandpit.nft
# проверить:
wg show
nft list ruleset

# stop-sandpit.sh
nft flush ruleset
wg-quick down wg0

В реальных проектах мы добавляем проверку ошибок и вывод причин (например, если wg0 не появился — не применять правила, либо применять с аккуратной обработкой).

Шаг 7. Проверка: как убедиться, что изоляция работает

Минимальный чек‑лист:

  • Интерфейс песочницы: ip a показывает wg0.
  • Маршруты: трафик в подсеть песочницы идет через wg0.
  • DNS: запросы уходят на ваш DNS‑адрес в туннеле (а не в «наружу»).
  • Блокировки: попытка открыть нежелательный ресурс должна быть заблокирована nftables.
  • Журналирование (по необходимости): временно включайте логирование в nftables для диагностики.

Пример диагностического правила (используйте аккуратно и недолго, чтобы не засорять логи):

# Добавьте отдельную цепочку логирования (примерная схема)
# log-политика включается временно на период отладки
# limit rate для снижения шума

limit rate 5/second burst 10
log prefix "sandpit-drop: " flags all drop

Ограничения и меры безопасности

  • Не полагайтесь только на «изоляцию»»: всегда проверяйте фактический поток пакетов (маршрут + интерфейс + политика фильтрации).
  • Держите список разрешений минимальным: AllowedIPs в WireGuard и разрешения в nftables должны совпадать по смыслу.
  • Учитывайте DNS: утечки обычно происходят через неправильные резолверы или неверно заданный DNS в WireGuard.
  • Обновления: nftables/ядро/приложения — разные сборки могут вести себя по‑разному; тестируйте на целевом устройстве.

Типовые применения в pentest‑проектах

Такая песочница полезна для:

  • Проверки доступности сервисов в заданной подсети без риска смешать трафик с обычной активностью устройства.
  • Повторяемых тестов: одинаковые правила nftables и один и тот же туннель — легче воспроизводить сценарии.
  • Контроля направлений: ограничение только нужных портов/хостов и запрет случайных соединений.

Заключение

Тонкая настройка WireGuard совместно с nftables позволяет построить на Android (в Termux) изолированную pentest‑песочницу, где сетевой поток предсказуем и управляем. Правильная адресация, минимальные AllowedIPs, строгая default‑deny логика nftables и верификация маршрутов/DNS превращают «случайные эксперименты» в профессиональный, воспроизводимый и более безопасный процесс тестирования.

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

* Текст статьи подготовлен и структурирован с использованием технологий искусственного интеллекта. Проверен и доработан перед публикацией.

Нужна помощь с настройкой Termux, Linux и серверов?

Я оказываю ИТ-услуги: настройка серверов, автоматизация, безопасность, помощь с Linux и инфраструктурой. Материалы сайта — только в ознакомительных и образовательных целях.

Связаться со мной
Поддержать проект