Обратно тетерирање за Android преку USB: команди, проверки, враќање

Обраното тетерирање го преместува сообраќајот на телефонот на сметач и го изведува надвор преку врската на тој сметач. Само USB кабел тоа не го прави: телефонот бара услуга за фаќање што го презема неговото насочување, а сметачот бара реле што ги носи тие пакети понатаму. Патеката има четири скока: апликација, фаќање на телефонот, USB реле и излез на домаќинот, и секој има различен сопственик. Ова упатство ја гради таа патека, го става VPN-от на домаќинот на вистинското место и го проверува секој скок пред да му верувате на резултатот.

Мапирајте ги скоковите пред да стартувате нешто

Секој скок применува своја политика, затоа резултат што работи на едниот крај не кажува ништо за другиот. Апликацијата избира одредиште и резолвер, услугата за фаќање одлучува кој сообраќај влегува во релето, релето проследува во сокетите на домаќинот, а насочувањето и VPN-от на домаќинот ја одредуваат адресата што одредиштето на крајот ја гледа.

Само еден клиент на 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 и тестирајте го расклопувањето пред да се потпрете на него.

Запишете го домаќинот што бил овластен, верзијата на релето, политиката на тунелот на домаќинот и чекорите на расклопување. Токму тој запис ја прави следната поставка на обрано тетерирање повторлива, наместо уште едно попладне на повторно откривање.