Apgrieztais tethering pārvieto tālruņa datu plūsmu uz datoru un izvada to caur šī datora savienojumu. Viens USB kabelis to nedara: tālrunim vajag uztveršanas servisu, kas pārņem tā maršrutēšanu, bet datoram – releju, kas šīs paketes nes tālāk. Ceļā ir četri lēcieni: lietotne, uztveršana tālrunī, USB relejs un resursdatora izeja, un katram ir cits īpašnieks. Šī rokasgrāmata izveido šo ceļu, liek resursdatora VPN pareizajā vietā un pārbauda katru lēcienu, pirms uzticēties rezultātam.

Izklāstiet lēcienus, pirms kaut ko palaižat

Katrs lēciens piemēro savu politiku, tāpēc strādājošs rezultāts vienā galā neko nepasaka par otru. Lietotne izvēlas galamērķi un atrisinātāju, uztveršanas serviss izlemj, kura plūsma nonāk relejā, relejs pārsūta uz resursdatora ligzdām, un resursdatora maršrutēšana un VPN nosaka adresi, ko galamērķis beigās redz.

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

Vienlaikus tālruņa uztveršanas lomu var ieņemt tikai viens VPN servisa klients, tāpēc otra parasta VPN lietotne neuzslāņojas uz releja. Ja VPN pieder datoram, uztveršanas serviss ir piekļuves posms uz šo datoru, nevis pierādījums, ka attālināts tunelis jau aizsargā rezultātu.

Sagatavojiet releju, pirms pieskaraties tālrunim

Gnirehtet ir šīs arhitektūras dokumentēts piemērs: VPN servisa klients bez root tālrunī un ar ADB pārnests relejs resursdatorā, atbalstot TCP un UDP pār IPv4. Tā krātuve arī norāda, ka projekts vairs netiek aktīvi uzturēts, tāpēc uzskatiet to par atsauces dizainu un strādājošu laboratorijas rīku, nevis atbalstītu produktu, ko standartizēt pārvaldītā parkā.

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

Vispirms palaidiet adb devices. Tālrunis, kas nav pieņēmis resursdatora atkļūdošanas atslēgu, tiek ziņots kā neautorizēts, un relejs nepievienosies, kamēr ierīcē netiks pieņemts pieprasījums. gnirehtet run instalē klientu, palaiž releju un aktivizē uztveršanu; versijā, kas atdala soļus, izmantojiet dokumentētās apakškomandas install, relay un start.

ADB piekļuve ir ierīces vadības attiecības, nevis tīkla iestatījums. Autorizējiet tikai jūsu kontrolētu datoru un plānojiet šo autorizāciju atsaukt, kad uzdevums būs pabeigts.

Atgrieziet resursdatora VPN ceļā

Relejs ir parasts resursdatora process, tāpēc tā tālākie savienojumi seko resursdatora maršrutēšanas tabulai. Pilna tuneļa profils tos pārnēsā; sadalīts tunelis var arī nepārnēsāt. Ja resursdatora VPN izmanto vadību pa lietotnēm, pievienojiet releja bināro failu atļautajai kopai, citādi relejs turpinās izmantot fizisko saskarni, kamēr pārlūks izskatās aizsargāts.

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

Palaidiet pirmās divas komandas pirms resursdatora VPN pievienošanas un pēc tam. Ja adrese nemainās, relejs nav tunelī, lai ko teiktu klienta logs. Tikai privāts tunelis arī atstāj publiskos galamērķus parastajā resursdatora izejā, kas izskatās kā noplūde, taču tā ir jūsu iestatītā politika.

DNS tiek atrisināts resursdatorā plūsmai caur releju, tāpēc resursdatora atrisinātājs nosaka, kurš serveris redz nosaukumus. Privāts DNS iestatījums tālrunī netiek pārnests pāri relejam, un atrisinātāja tests tālruņa pusē neaprakstīs resursdatora vaicājumus.

Pārbaudiet katru lēcienu atsevišķi

Trīs pārbaudes šādā secībā: tālrunis sasniedz releju, relejs sasniedz galamērķi resursdatora politikas ietvaros, un lietotne pareizi atrisina un izmanto šo galamērķi. Apstājieties pie pirmās kļūdas, nevis pārlādējiet lapas un miniet.

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

VPN tīkla ieraksts savienojumu izgūtajā datos parāda, ka uztveršanas serviss ir aktīvs; paša releja žurnāls parāda, vai plūsmas pienāk. Ja kāda no tām trūkst, problēma sadalās tīri: nav uztveršanas – tālruņa puse, nav plūsmu – resursdatora puse.

Pārlūks, kas darbojas resursdatorā, pierāda resursdatora pārlūka ceļu, nevis releja procesa ceļu. Salīdziniet adreses, ko katra ziņo, un pārbaudiet gan privātu resursu, gan publisku lapu, jo tikai privāts tunelis var maršrutēt vienu un ne otru.

Izjauciet un izvēlieties kļūdas uzvedību

Atritināšana ir rokasgrāmatas daļa. Apturiet un noņemiet releju, atinstalējiet uztveršanas klientu un atsauciet resursdatora atkļūdošanas autorizāciju tālruņa izstrādātāja opcijās, kad uzdevums būs pabeigts.

gnirehtet stop
gnirehtet uninstall
adb kill-server

Izlemiet, kas tālrunim jādara, kad relejs pazūd. Bez skaidras izvēles tas var atgriezties pie mobilajiem datiem un noplūdināt plūsmu, ko mēģinājāt maršrutēt, tāpēc apzināti iestatiet savienojumu bloķēšanas uzvedību vai VPN politiku un pārbaudiet izjaukšanu, pirms paļaujaties uz to.

Pierakstiet, kurš resursdators tika autorizēts, releja versiju, resursdatora tuneļa politiku un izjaukšanas soļus. Tieši šis pieraksts padara nākamo apgrieztā tethering iestatīšanu atkārtojamu, nevis vēl vienu pēcpusdienu, kas pavadīta atklājot no jauna.

Saistītie raksti