Inversa kunligado por Android per USB: komandoj, kontroloj, restarigo

Inversa kunligado movas la trafikon de telefono al komputilo kaj eliras tra la konekto de tiu komputilo. Nur USB-kablo tion ne faras: la telefono bezonas kaptan servon, kiu transprenas ĝian enkursigadon, kaj la komputilo bezonas relajson, kiu portas tiujn pakaĵojn pluen. La vojo havas kvar saltojn: aplikaĵo, kapto ĉe la telefono, USB-relajso kaj eliro de la gastiganto, kaj ĉiu havas alian posedanton. Ĉi tiu gvidlibro konstruas tiun vojon, metas la VPN de la gastiganto tien, kie ĝi apartenas, kaj kontrolas ĉiun salton antaŭ ol vi fidos la rezulton.

Mapu la saltojn antaŭ ol lanĉi ion ajn

Ĉiu salto aplikas sian propran politikon, tial funkcianta rezulto ĉe unu fino diras nenion pri la alia. La aplikaĵo elektas celon kaj solvilon, la kapta servo decidas, kiu trafiko eniras la relajson, la relajso plusendas al la soketoj de la gastiganto, kaj la enkursigado kaj VPN de la gastiganto decidas la adreson, kiun la celo fine vidas.

Nur unu kliento de la VPN-servo povas teni la kaptan rolon de la telefono samtempe, do dua ordinara VPN-aplikaĵo ne stakiĝas sur la relajso. Se la VPN apartenas al la komputilo, la kapta servo estas la alirila ligo al tiu komputilo, ne pruvo, ke fora tunelo jam protektas la rezulton.

Pretigu la relajson antaŭ ol tuŝi la telefonon

Gnirehtet estas la dokumentita ekzemplo de ĉi tiu arkitekturo: kliento de la VPN-servo sen root ĉe la telefono plus relajso portata per ADB ĉe la gastiganto, subtenante TCP kaj UDP super IPv4. Ĝia deponejo ankaŭ indikas, ke la projekto ne plu estas aktive prizorgata, do traktu ĝin kiel la referencan dezajnon kaj funkciantan ilon por laboratorio, ne kiel subtenatan produkton por normigi tra administrata aro da aparatoj.

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

Unue lanĉu adb devices. Telefono, kiu ne akceptis la sencimigan ŝlosilon de la gastiganto, raportiĝas kiel neaŭtorizita, kaj la relajso ne konektiĝos ĝis la invito sur la aparato estos akceptita. gnirehtet run instalas la klienton, startigas la relajson kaj aktivigas la kapton; ĉe versio, kiu apartigas la paŝojn, uzu anstataŭe la dokumentitajn subkomandojn install, relay kaj start.

ADB-aliro estas aparatkontrola rilato, ne reta agordo. Rajtigu nur komputilon, kiun vi kontrolas, kaj planu revoki tiun rajtigon, kiam la tasko finiĝos.

Remetu la VPN de la gastiganto en la vojon

La relajso estas ordinara gastiganta procezo, do ĝiaj pluaj konektoj sekvas la enkursigan tabelon de la gastiganto. Plentunela profilo portas ilin; dividita tunelo eble ne. Se la VPN de la gastiganto uzas kontrolojn laŭ aplikaĵo, aldonu la relajsan binaraĵon al la permesita aro, alie la relajso daŭre uzas la fizikan interfacon, dum la retumilo aspektas protektita.

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

Lanĉu la unuajn du komandojn antaŭ kaj post konekti la VPN de la gastiganto. Se la adreso ne ŝanĝiĝas, la relajso ne estas en la tunelo, kion ajn diras la klienta fenestro. Tunelo nur por privataj retoj ankaŭ lasas publikajn celojn sur la normala eliro de la gastiganto, kio aspektas kiel liko sed estas la politiko, kiun vi agordis.

DNS solviĝas ĉe la gastiganto por trafiko tra la relajso, do la solvilo de la gastiganto decidas, kiun servilon vidas la nomoj. Privata DNS-agordo ĉe la telefono ne transiras la relajson, kaj solvila testo ĉe la telefono ne priskribos la serĉojn de la gastiganto.

Kontrolu ĉiun salton aparte

Tri kontroloj, en ĉi tiu ordo: la telefono atingas la relajson, la relajso atingas la celon laŭ la politiko de la gastiganto, kaj la aplikaĵo solvas kaj uzas tiun celon ĝuste. Haltu ĉe la unua malsukceso anstataŭ reŝargi paĝojn kaj diveni.

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

VPN-reta ero en la konekteca eligo montras, ke la kapta servo estas aktiva; la propra protokolo de la relajso montras, ĉu fluoj alvenas. Manko en unu el ili klare disigas la problemon: sen kapto temas pri la telefona flanko, sen fluoj pri la gastiganta flanko.

Retumilo, kiu funkcias ĉe la gastiganto, pruvas la vojon de la gastiganta retumilo, ne tiun de la relajsa procezo. Komparu la adresojn, kiujn ĉiu raportas, kaj testu privatan rimedon same kiel publikan paĝon, ĉar tunelo nur por privataj retoj povas enkursigi unu kaj ne la alian.

Malkonstruu kaj elektu la fiaskan konduton

Restarigo estas parto de la gvidlibro. Haltigu kaj forigu la relajson, malinstalu la kaptan klienton, kaj revoku la sencimigan rajtigon de la gastiganto el la ellaborantaj opcioj de la telefono, kiam la tasko finiĝos.

gnirehtet stop
gnirehtet uninstall
adb kill-server

Decidu, kion la telefono faru, kiam la relajso malaperas. Sen eksplicita elekto ĝi povas refali al moveblaj datumoj kaj liki la trafikon, kiun vi provis enkursigi, do agordu konscie la konduton de blokado de konektoj aŭ la VPN-politikon kaj testu la malkonstruon antaŭ ol fidi ĝin.

Notu la rajtigitan gastiganton, la relajsan version, la tunelan politikon de la gastiganto kaj la malkonstruajn paŝojn. Ĝuste tiu noto igas la sekvan agordon de inversa kunligado ripetebla anstataŭ alia posttagmezo de remalkovro.