Tethering invers per a Android per USB: ordres, comprovacions i reversió
El tethering invers envia el trànsit del telèfon a través d’un relé al host. Construeix el camí del telèfon al host, mantén la VPN del host al bucle i verifica cada salt.
El tethering invers mou el trànsit d’un telèfon a un ordinador i el fa sortir per la connexió de l’ordinador. Un cable USB sol no ho fa: el telèfon necessita un servei de captura que assumeixi l’encaminament, i l’ordinador necessita un relé que porti aquests paquets més enllà. El camí té quatre salts: aplicació, captura al telèfon, relé USB i sortida del host, i cadascun té un propietari diferent. Aquest manual construeix aquest camí, posa la VPN del host on li pertoca i comprova cada salt abans que et refiïs del resultat.
Mapeja els salts abans d’executar res
Cada salt aplica la seva pròpia política, per això un resultat que funciona en un extrem no diu res de l’altre. L’aplicació tria una destinació i un resolutor, el servei de captura decideix quin trànsit entra al relé, el relé reenvia cap als sockets del host, i l’encaminament i la VPN del host decideixen l’adreça que la destinació acaba veient.
| 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 |
Només un client del servei VPN pot ocupar alhora el paper de captura del telèfon, així que una segona aplicació VPN corrent no es superposa al relé. Si la VPN pertany a l’ordinador, el servei de captura és l’enllaç d’accés cap a aquest ordinador, no la prova que un túnel remot ja protegeixi el resultat.
Prepara el relé abans de tocar el telèfon
Gnirehtet és l’exemple documentat d’aquesta arquitectura: un client del servei VPN sense root al telèfon més un relé portat per ADB al host, amb suport de TCP i UDP sobre IPv4. El seu repositori també indica que el projecte ja no es manté activament, així que tracta’l com el disseny de referència i una eina funcional per a un laboratori, no com un producte amb suport per estandarditzar en una flota gestionada.
adb devices
adb shell getprop ro.build.version.release
gnirehtet runExecuta primer adb devices. Un telèfon que no ha acceptat la clau de depuració del host es declara com a no autoritzat, i el relé no s’hi connectarà fins que s’accepti el missatge al dispositiu. gnirehtet run instal·la el client, inicia el relé i activa la captura; en una versió que separa els passos, fes servir en canvi les subordres documentades install, relay i start.
L’accés ADB és una relació de control del dispositiu, no un paràmetre de xarxa. Autoritza només un ordinador que controlis, i preveu revocar aquesta autorització quan acabi la tasca.
Torna a posar la VPN del host al camí
El relé és un procés corrent del host, així que les seves connexions posteriors segueixen la taula d’encaminament del host. Un perfil de túnel complet les transporta; un túnel dividit potser no. Si la VPN del host fa servir controls per aplicació, afegeix el binari del relé al conjunt permès, si no el relé continua fent servir la interfície física mentre el navegador sembla protegit.
ip route get 1.1.1.1
curl -4 https://ifconfig.me
sudo ss -tnp | grep -i relayExecuta les dues primeres ordres abans i després de connectar la VPN del host. Si l’adreça no canvia, el relé no és al túnel, digui el que digui la finestra del client. Un túnel només per a xarxes privades també deixa les destinacions públiques a la sortida normal del host, cosa que sembla una fuita però és la política que has configurat.
El DNS es resol al host per al trànsit que passa pel relé, així que el resolutor del host decideix quin servidor veu els noms. Un paràmetre de DNS privat al telèfon no travessa el relé, i una prova de resolutor al telèfon no descriurà les consultes del host.
Verifica cada salt per separat
Tres comprovacions, en aquest ordre: el telèfon arriba al relé, el relé arriba a la destinació sota la política del host, i l’aplicació resol i fa servir correctament aquesta destinació. Atura’t al primer error en lloc de recarregar pàgines i endevinar.
adb shell dumpsys connectivity | grep -i -A3 vpn
adb logcat -s GnirehtetRelay:V Gnirehtet:VUna entrada de xarxa VPN a l’abocament de connectivitat mostra que el servei de captura és actiu; el registre propi del relé mostra si arriben fluxos. L’absència en un dels dos divideix el problema netament: sense captura és el costat del telèfon, sense fluxos és el costat del host.
Un navegador que funciona al host demostra el camí del navegador del host, no el del procés del relé. Compara les adreces que reporta cadascun, i prova un recurs privat i també una pàgina pública, perquè un túnel només per a xarxes privades pot encaminar l’un i no l’altre.
Desfés la instal·lació i tria el comportament en cas de fallada
La reversió forma part del manual. Atura i elimina el relé, desinstal·la el client de captura i revoca l’autorització de depuració del host des de les opcions de desenvolupador del telèfon quan la tasca estigui acabada.
gnirehtet stop
gnirehtet uninstall
adb kill-serverDecideix què ha de fer el telèfon quan el relé desaparegui. Sense una tria explícita pot tornar a les dades mòbils i filtrar el trànsit que intentaves encaminar, així que estableix deliberadament el comportament de bloqueig de connexions o la política VPN i prova el desmuntatge abans de refiar-t’hi.
Anota el host que es va autoritzar, la versió del relé, la política de túnel del host i els passos de desmuntatge. Aquest registre és el que fa que la propera configuració de tethering invers sigui repetible en lloc d’una altra tarda de redescobriment.