Зворотний тетеринг для 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 і перевірте розбирання, перш ніж покладатися на неї.
Запишіть, який хост було авторизовано, версію ретранслятора, політику тунелю хоста та кроки розбирання. Саме цей запис робить наступне налаштування зворотного тетерингу повторюваним, а не ще одним днем повторного відкриття.