Baligtad na tethering para sa Android sa pamamagitan ng USB: mga utos, pagsusuri, pagbabalik

Inililipat ng baligtad na tethering ang trapiko ng telepono sa isang kompyuter at inilalabas ito sa koneksyon ng kompyuter na iyon. Ang USB cable lamang ay hindi ito ginagawa: kailangan ng telepono ng serbisyo ng paghuli na tumatanggap ng ruta nito, at kailangan ng kompyuter ng relay na nagdadala ng mga packet na iyon pasulong. Ang landas ay may apat na pagtalon: aplikasyon, paghuli sa telepono, USB relay at labasan ng host, at bawat isa ay may ibang may-ari. Binubuo ng runbook na ito ang landas na iyon, inilalagay ang VPN ng host sa tamang lugar at sinusuri ang bawat pagtalon bago ka magtiwala sa resulta.

I-map ang mga pagtalon bago magpatakbo ng anuman

Bawat pagtalon ay naglalapat ng sarili nitong patakaran, kaya ang resultang gumagana sa isang dulo ay walang sinasabi tungkol sa kabilang dulo. Pinipili ng aplikasyon ang destinasyon at resolver, nagpapasya ang serbisyo ng paghuli kung aling trapiko ang papasok sa relay, ipinapasa ng relay sa mga socket ng host, at ang ruta at VPN ng host ang nagpapasya sa address na sa huli ay nakikita ng destinasyon.

Isang kliyente lamang ng serbisyo ng VPN ang maaaring humawak sa papel ng paghuli ng telepono sa isang pagkakataon, kaya ang pangalawang ordinaryong app ng VPN ay hindi nagsasalansan sa relay. Kung ang VPN ay pag-aari ng kompyuter, ang serbisyo ng paghuli ang kawing ng pag-access patungo sa kompyuter na iyon, hindi patunay na may proteksyon na ang malayong tunnel sa resulta.

Ihanda ang relay bago hawakan ang telepono

Gnirehtet ang dokumentadong halimbawa ng arkitekturang ito: isang kliyente ng serbisyo ng VPN na walang root sa telepono at isang relay na dinadala sa pamamagitan ng ADB sa host, sumusuporta sa TCP at UDP sa IPv4. Sinasabi rin ng repository nito na hindi na aktibong pinapanatili ang proyekto, kaya ituring ito bilang reference na disenyo at gumaganang kasangkapan para sa laboratoryo, hindi bilang produktong may suporta na ise-standardize sa isang pinamamahalaang fleet.

adb devices
adb shell getprop ro.build.version.release
gnirehtet run

Patakbuhin muna ang adb devices. Ang teleponong hindi pa tumanggap ng debugging key ng host ay naiuulat na hindi awtorisado, at hindi kokonekta ang relay hanggang matanggap ang prompt sa device. Ini-install ng gnirehtet run ang kliyente, sinisimulan ang relay at ginagawang aktibo ang paghuli; sa bersyong naghihiwalay ng mga hakbang, gamitin sa halip ang dokumentadong install, relay at start na mga subcommand.

Ang pag-access sa ADB ay ugnayan ng pagkontrol ng device, hindi setting ng network. Awtorisahin lamang ang kompyuter na kinokontrol mo, at planuhin ang pagbawi ng awtorisasyong iyon kapag tapos na ang gawain.

Ibalik ang VPN ng host sa landas

Ang relay ay ordinaryong proseso ng host, kaya sinusunod ng mga susunod nitong koneksyon ang routing table ng host. Dinadala ng full-tunnel profile ang mga ito; ang split tunnel ay maaaring hindi. Kung gumagamit ang VPN ng host ng mga kontrol kada app, idagdag ang binary ng relay sa pinapayagang set, kung hindi ay patuloy na gagamitin ng relay ang pisikal na interface habang mukhang protektado ang browser.

ip route get 1.1.1.1
curl -4 https://ifconfig.me
sudo ss -tnp | grep -i relay

Patakbuhin ang unang dalawang utos bago at pagkatapos ikonekta ang VPN ng host. Kung hindi magbago ang address, wala ang relay sa tunnel, anuman ang sabihin ng window ng kliyente. Ang pribado-lamang na tunnel ay nag-iiwan din ng mga pampublikong destinasyon sa normal na labasan ng host, na mukhang pagtagas ngunit iyon ang patakarang itinakda mo.

Nareresolba ang DNS sa host para sa trapikong dumadaan sa relay, kaya ang resolver ng host ang nagpapasya kung aling server ang nakakakita ng mga pangalan. Ang pribadong DNS setting sa telepono ay hindi tumatawid sa relay, at ang pagsubok ng resolver sa panig ng telepono ay hindi ilalarawan ang mga lookup ng host.

I-verify ang bawat pagtalon nang hiwalay

Tatlong pagsusuri, sa ganitong pagkakasunod-sunod: naaabot ng telepono ang relay, naaabot ng relay ang destinasyon sa ilalim ng patakaran ng host, at wastong nareresolba at nagagamit ng aplikasyon ang destinasyong iyon. Huminto sa unang pagpalya sa halip na i-reload ang mga pahina at manghula.

adb shell dumpsys connectivity | grep -i -A3 vpn
adb logcat -s GnirehtetRelay:V Gnirehtet:V

Isang entry ng VPN network sa dump ng konektibidad ay nagpapakitang aktibo ang serbisyo ng paghuli; ang log ng relay mismo ay nagpapakita kung dumarating ang mga flow. Ang kawalan sa isa sa kanila ay malinaw na naghahati sa problema: walang paghuli ay panig ng telepono, walang flow ay panig ng host.

Ang browser na gumagana sa host ay nagpapatunay ng landas ng browser ng host, hindi ng proseso ng relay. Ihambing ang mga address na iniuulat ng bawat isa, at subukan ang pribadong resource pati na ang pampublikong pahina, dahil ang pribado-lamang na tunnel ay maaaring mag-ruta ng isa at hindi ang isa.

Ibuwag at piliin ang gawi sa pagpalya

Ang pagbabalik ay bahagi ng runbook. Ihinto at alisin ang relay, i-uninstall ang kliyente ng paghuli, at bawiin ang awtorisasyon ng debugging ng host mula sa mga opsyon ng developer ng telepono kapag tapos na ang gawain.

gnirehtet stop
gnirehtet uninstall
adb kill-server

Magpasya kung ano ang dapat gawin ng telepono kapag nawala ang relay. Kung walang malinaw na pagpili, maaari itong bumalik sa mobile data at tumagas ang trapikong sinubukan mong i-ruta, kaya sadyang itakda ang gawi ng pagharang ng koneksyon o ang patakaran ng VPN at subukan ang pagbuwag bago ka umasa dito.

Itala ang host na awtorisado, ang bersyon ng relay, ang patakaran ng tunnel ng host at ang mga hakbang sa pagbuwag. Ang talaang iyon ang nagpapaging-ulit-ulitin ng susunod na setup ng baligtad na tethering sa halip na isa na namang hapon ng muling pagtuklas.