Обратный тетеринг для Android через USB: команды, проверки, откат
Обратный тетеринг передаёт трафик телефона через ретранслятор на хосте. Постройте путь от телефона к хосту, оставьте VPN хоста в петле и проверьте каждый шаг.
Обратный тетеринг переносит трафик телефона на компьютер и выводит его через соединение этого компьютера. Один USB-кабель этого не делает: телефону нужна служба перехвата, которая берёт на себя его маршрутизацию, а компьютеру — ретранслятор, который несёт эти пакеты дальше. В пути четыре шага: приложение, перехват на телефоне, USB-ретранслятор и выход хоста, и у каждого свой владелец. Это руководство строит такой путь, ставит VPN хоста на место и проверяет каждый шаг, прежде чем доверять результату.
Составьте карту шагов, прежде чем что-то запускать
Каждый шаг применяет свою политику, поэтому работающий результат на одном конце ничего не говорит о другом. Приложение выбирает адрес назначения и резолвер, служба перехвата решает, какой трафик войдёт в ретранслятор, ретранслятор передаёт его в сокеты хоста, а маршрутизация и VPN хоста определяют адрес, который назначение в итоге видит.
| Hop | Owner | What it decides |
|---|---|---|
| Application request | The app | Destination, resolver, address family |
| Capture service | Phone VpnService app | Which traffic enters the relay at all |
| ADB relay | Host process | Forwarding phone flows to host sockets |
| Host egress | Host routing and VPN | Exit address and host policy |
Одновременно роль перехвата телефона может держать только один клиент службы VPN, поэтому второе обычное VPN-приложение не наслаивается на ретранслятор. Если VPN принадлежит компьютеру, служба перехвата — это звено доступа к этому компьютеру, а не доказательство, что удалённый туннель уже защищает результат.
Подготовьте ретранслятор, прежде чем трогать телефон
Gnirehtet — документированный пример этой архитектуры: клиент службы VPN без root на телефоне плюс ретранслятор, переносимый через ADB на хосте, с поддержкой TCP и UDP поверх IPv4. Его репозиторий также указывает, что проект больше не поддерживается активно, поэтому относитесь к нему как к эталонному дизайну и рабочему инструменту для лаборатории, а не как к поддерживаемому продукту для стандартизации в управляемом парке.
adb devices
adb shell getprop ro.build.version.release
gnirehtet run
Сначала запустите adb devices. Телефон, не принявший ключ отладки хоста, отображается как неавторизованный, и ретранслятор не подключится, пока запрос на устройстве не будет принят. gnirehtet run устанавливает клиент, запускает ретранслятор и активирует перехват; в версии, разделяющей шаги, используйте вместо этого документированные подкоманды install, relay и start.
Доступ через ADB — это отношение управления устройством, а не сетевой параметр. Авторизуйте только компьютер, который вы контролируете, и планируйте отозвать это разрешение после завершения задачи.
Верните VPN хоста в путь
Ретранслятор — обычный процесс хоста, поэтому его дальнейшие соединения идут по таблице маршрутизации хоста. Профиль полного туннеля их пропускает; раздельный туннель может и нет. Если VPN хоста использует управление по приложениям, добавьте бинарник ретранслятора в разрешённый набор, иначе ретранслятор продолжит использовать физический интерфейс, пока браузер выглядит защищённым.
ip route get 1.1.1.1
curl -4 https://ifconfig.me
sudo ss -tnp | grep -i relay
Запустите первые две команды до и после подключения VPN хоста. Если адрес не меняется, ретранслятор не в туннеле, что бы ни говорило окно клиента. Туннель только для частных сетей также оставляет публичные назначения на обычном выходе хоста, что выглядит утечкой, но это заданная вами политика.
DNS для трафика через ретранслятор разрешается на хосте, поэтому его резолвер решает, какой сервер видит имена. Настройка приватного DNS на телефоне не переносится через ретранслятор, а тест резолвера на стороне телефона не опишет запросы хоста.
Проверяйте каждый шаг отдельно
Три проверки в таком порядке: телефон достигает ретранслятора, ретранслятор достигает назначения по политике хоста, а приложение правильно разрешает и использует это назначение. Остановитесь на первой ошибке вместо перезагрузки страниц и догадок.
adb shell dumpsys connectivity | grep -i -A3 vpn
adb logcat -s GnirehtetRelay:V Gnirehtet:V
Запись сети VPN в дампе подключений показывает, что служба перехвата активна; собственный журнал ретранслятора показывает, приходят ли потоки. Отсутствие в одном из них чисто разделяет проблему: нет перехвата — сторона телефона, нет потоков — сторона хоста.
Браузер, работающий на хосте, доказывает путь браузера хоста, а не путь процесса ретранслятора. Сравните адреса, которые сообщает каждый из них, и проверьте как частный ресурс, так и публичную страницу, потому что туннель только для частных сетей может маршрутизировать одно и не маршрутизировать другое.
Разберите установку и выберите поведение при отказе
Откат — часть руководства. Остановите и удалите ретранслятор, удалите клиент перехвата и отзовите разрешение на отладку хоста в параметрах разработчика телефона, когда задача завершена.
gnirehtet stop
gnirehtet uninstall
adb kill-server
Решите, что телефон должен делать, когда ретранслятор исчезает. Без явного выбора он может вернуться к мобильным данным и утечь трафик, который вы пытались направить, поэтому намеренно задайте поведение блокировки соединений или политику VPN и проверьте разборку, прежде чем полагаться на неё.
Запишите, какой хост был авторизован, версию ретранслятора, политику туннеля хоста и шаги разборки. Именно эта запись делает следующую настройку обратного тетеринга воспроизводимой, а не очередным днём повторного открытия.