Обратното свързване премества трафика на телефона към компютър и го извежда през връзката на компютъра. Само USB кабел не го прави: телефонът се нуждае от услуга за прихващане, която поема маршрутизацията му, а компютърът — от релей, който пренася тези пакети нататък. Пътят има четири стъпки: приложение, прихващане на телефона, USB релей и изход на хоста, и всяка има различен собственик. Това ръководство изгражда този път, поставя VPN на хоста където му е мястото и проверява всяка стъпка, преди да се доверите на резултата.

Начертайте стъпките, преди да стартирате нещо

Всяка стъпка прилага собствена политика, затова работещ резултат в единия край не казва нищо за другия. Приложението избира дестинация и резолвер, услугата за прихващане решава кой трафик влиза в релея, релеят препраща към сокетите на хоста, а маршрутизацията и VPN на хоста определят адреса, който дестинацията накрая вижда.

HopOwnerWhat it decides
Application requestThe appDestination, resolver, address family
Capture servicePhone VpnService appWhich traffic enters the relay at all
ADB relayHost processForwarding phone flows to host sockets
Host egressHost routing and VPNExit 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 и тествайте разглобяването, преди да разчитате на него.

Запишете хоста, който е бил оторизиран, версията на релея, политиката на тунела на хоста и стъпките за разглобяване. Този запис прави следващата настройка на обратно свързване възпроизводима, вместо поредния следобед за преоткриване.

Подобни статии