Пентест‑работа на Android часто упирается не только в утилиты, но и в управляемость сетевого окружения. Без изоляции результаты тестов могут смешиваться с обычной активностью устройства, усложняется воспроизведение сценариев, а риски утечек (скрытых DNS‑запросов, непредусмотренных соединений, доступа к локальной сети) возрастают.
Практическое решение — построить локальную изолированную среду, где весь трафик «исследовательского» сегмента контролируется политиками nftables, а туннель для сегмента создаётся через WireGuard. Важно: ниже речь только про построение локальной защищённой сети для песочницы на вашем устройстве/в вашей локальной инфраструктуре, а не про обход блокировок.
Архитектура решения (высокоуровнево)
Цель — добиться следующих свойств:
- Сегментация: «песочница» отделена от основной сети устройства.
- Контроль egress/ingress: nftables ограничивает, какие направления разрешены, и какие пакеты/порты допустимы.
- Предсказуемый маршрут: трафик песочницы принудительно направляется через WireGuard.
- Наблюдаемость: проще логировать и диагностировать, где именно происходят блокировки/разрешения.
Типовая схема:
- В Termux поднимается WireGuard‑интерфейс (туннель) для изолированного сегмента.
- nftables применяет правила к трафику в песочном сегменте: DNS, TCP/UDP, запрет латерального доступа.
- Маршруты (и при необходимости отдельные таблицы/цепочки) направляют выход песочницы в туннель.
- При старте/остановке песочницы правила 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 превращают «случайные эксперименты» в профессиональный, воспроизводимый и более безопасный процесс тестирования.
Если вам нужен аудит вашей текущей схемы, подбор оптимальной топологии (клиент/сервер, подсети, политики), или подготовка готовых скриптов/шаблонов песочницы под ваши реальные условия — обращайтесь в РыбинскЛАБ. Мы помогаем внедрять практики безопасной сетевой изоляции для задач пентеста и исследований.