Pööratud tetherdamine Androidis USB kaudu: käsud, kontrollid, tagasipööramine
Pööratud tetherdamine suunab telefoni liikluse hosti relee kaudu. Ehitage tee telefonist hostini, hoidke hosti VPN ahelas ja kontrollige igat hüpet.
Pööratud tetherdamine viib telefoni liikluse arvutisse ja väljub sealt arvuti ühenduse kaudu. Ainult USB-kaabel seda ei tee: telefonil on vaja püüdmisteenust, mis võtab üle selle marsruutimise, ja arvutil releed, mis need paketid edasi kannab. Teel on neli hüpet: rakendus, püüdmine telefonis, USB-relee ja hosti väljund, ning igal neist on erinev omanik. See juhend ehitab selle tee, paneb hosti VPN-i õigesse kohta ja kontrollib iga hüpet enne, kui tulemust usaldad.
Kaardista hüpped enne, kui midagi käivitad
Iga hüpe rakendab oma poliitikat, seepärast ei ütle ühes otsas töötav tulemus teise otsa kohta midagi. Rakendus valib sihtkoha ja resolveri, püüdmisteenus otsustab, milline liiklus releesse siseneb, relee edastab hosti soketitesse ning hosti marsruutimine ja VPN määravad aadressi, mida sihtkoht lõpuks näeb.
| 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 |
Korraga saab telefoni püüdmisrolli hoida ainult üks VPN-teenuse klient, nii et teine tavaline VPN-rakendus ei kuhja end relee peale. Kui VPN kuulub arvutisse, on püüdmisteenus selle arvuti poole suunduv juurdepääsulüli, mitte tõestus, et kaugtunnel juba tulemust kaitseb.
Valmista relee ette enne, kui telefoni puutud
Gnirehtet on selle arhitektuuri dokumenteeritud näide: VPN-teenuse klient ilma root-õigusteta telefonis pluss ADB kaudu kantav relee hostis, toetades TCP-d ja UDP-d üle IPv4. Selle hoidla märgib ka, et projekti ei hooldata enam aktiivselt, seega käsitle seda võrdluslahenduse ja laboris töötava tööriistana, mitte toetatud tootena, mida hallatavas seadmepargis standardida.
adb devices
adb shell getprop ro.build.version.release
gnirehtet run
Käivita esmalt adb devices. Telefon, mis ei ole hosti silumisvõtit vastu võtnud, teatatakse volitamata olekus ja relee ei ühendu enne, kui seadme viip vastu võetakse. gnirehtet run paigaldab kliendi, käivitab relee ja aktiveerib püüdmise; versioonis, mis eraldab sammud, kasuta selle asemel dokumenteeritud alamkäske install, relay ja start.
ADB juurdepääs on seadme juhtimissuhe, mitte võrgusäte. Volita ainult arvuti, mida ise kontrollid, ja kavanda selle volituse tühistamist, kui töö on tehtud.
Pane hosti VPN teele tagasi
Relee on tavaline hosti protsess, seega järgivad selle edasised ühendused hosti marsruutimistabelit. Täistunneli profiil kannab neid; jagatud tunnel võib-olla mitte. Kui hosti VPN kasutab rakendusepõhiseid kontrolle, lisa relee binaarfail lubatud hulka, muidu kasutab relee edasi füüsilist liidest, samal ajal kui brauser näib kaitstud.
ip route get 1.1.1.1
curl -4 https://ifconfig.me
sudo ss -tnp | grep -i relay
Käivita kaks esimest käsku enne ja pärast hosti VPN-i ühendamist. Kui aadress ei muutu, ei ole relee tunnelis, mida iganes kliendi aken ütleb. Ainult privaatvõrkude tunnel jätab avalikud sihtkohad hosti tavalisse väljundisse, mis näeb välja nagu leke, kuid on sinu seatud poliitika.
DNS lahendatakse hostis relee kaudu liikuva liikluse jaoks, seega hosti resolver otsustab, milline server nimed näeb. Telefoni privaatse DNS-i säte ei kandu üle relee ja telefoni resolveri test ei kirjelda hosti päringuid.
Kontrolli iga hüpet eraldi
Kolm kontrolli selles järjekorras: telefon jõuab releeni, relee jõuab sihtkohta hosti poliitika alusel ning rakendus lahendab ja kasutab seda sihtkohta õigesti. Peatu esimese tõrke juures, selle asemel et lehti uuesti laadida ja oletada.
adb shell dumpsys connectivity | grep -i -A3 vpn
adb logcat -s GnirehtetRelay:V Gnirehtet:V
VPN-võrgu kirje ühenduvuse väljavõttes näitab, et püüdmisteenus on aktiivne; relee enda logi näitab, kas vood saabuvad. Nende ühes puudumine jaotab probleemi puhtalt: püüdmist pole tähendab telefoni poolt, vooge pole tähendab hosti poolt.
Hostis töötav brauser tõestab hosti brauseri teed, mitte relee protsessi teed. Võrdle aadresse, mida kumbki teatab, ja katseta nii privaatset ressurssi kui ka avalikku lehte, sest ainult privaatvõrkude tunnel võib marsruutida ühte ja mitte teist.
Võta maha ja vali tõrke käitumine
Tagasipööramine on juhendi osa. Peata ja eemalda relee, desinstalli püüdmiskliient ning tühista hosti silumisvolitus telefoni arendaja valikutes, kui töö on lõpetatud.
gnirehtet stop
gnirehtet uninstall
adb kill-server
Otsusta, mida telefon peaks tegema, kui relee kaob. Ilma selge valikuta võib see langeda tagasi mobiilse andmeside peale ja lekitada liiklust, mida püüdsid marsruutida, seega sea ühenduste blokeerimise käitumine või VPN-i poliitika teadlikult ja katseta mahavõtmist enne, kui sellele toetud.
Kirjuta üles volitatud host, relee versioon, hosti tunneli poliitika ja mahavõtmise sammud. Just see kirje teeb järgmise pööratud tetherdamise seadistuse korratavaks, selle asemel et kulutada veel üks pärastlõuna uuesti avastamisele.