Обратно свързване на 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 и тествайте разглобяването, преди да разчитате на него.
Запишете хоста, който е бил оторизиран, версията на релея, политиката на тунела на хоста и стъпките за разглобяване. Този запис прави следващата настройка на обратно свързване възпроизводима, вместо поредния следобед за преоткриване.