Tethering inverso per Android via USB: comandi, controlli, ripristino

Il tethering inverso sposta il traffico di un telefono su un computer e lo fa uscire attraverso la connessione del computer. Un cavo USB da solo non basta: il telefono ha bisogno di un servizio di cattura che si assuma il suo instradamento, e il computer di un relè che porti quei pacchetti oltre. Il percorso ha quattro salti: applicazione, cattura sul telefono, relè USB e uscita dell’host, e ciascuno ha un proprietario diverso. Questo manuale costruisce quel percorso, mette la VPN dell’host al posto giusto e controlla ogni salto prima di fidarti del risultato.

Mappa i salti prima di eseguire qualsiasi cosa

Ogni salto applica la propria politica, per questo un risultato che funziona a un estremo non dice nulla sull’altro. L’applicazione sceglie una destinazione e un resolver, il servizio di cattura decide quale traffico entra nel relè, il relè inoltra verso i socket dell’host, e l’instradamento e la VPN dell’host decidono l’indirizzo che la destinazione finisce per vedere.

Solo un client del servizio VPN può tenere il ruolo di cattura del telefono alla volta, quindi una seconda normale applicazione VPN non si sovrappone al relè. Se la VPN appartiene al computer, il servizio di cattura è il collegamento di accesso verso quel computer, non la prova che un tunnel remoto protegga già il risultato.

Prepara il relè prima di toccare il telefono

Gnirehtet è l’esempio documentato di questa architettura: un client del servizio VPN senza root sul telefono più un relè trasportato via ADB sull’host, con supporto di TCP e UDP su IPv4. Il suo repository indica anche che il progetto non è più mantenuto attivamente, quindi trattalo come il progetto di riferimento e uno strumento funzionante per un laboratorio, non come un prodotto supportato da standardizzare su una flotta gestita.

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

Esegui prima adb devices. Un telefono che non ha accettato la chiave di debug dell’host viene segnalato come non autorizzato, e il relè non si collegherà finché il messaggio sul dispositivo non viene accettato. gnirehtet run installa il client, avvia il relè e attiva la cattura; su una versione che separa i passaggi, usa invece i sottocomandi documentati install, relay e start.

L’accesso ADB è una relazione di controllo del dispositivo, non un’impostazione di rete. Autorizza solo un computer che controlli, e prevedi di revocare quell’autorizzazione quando il compito è finito.

Rimetti la VPN dell’host nel percorso

Il relè è un normale processo dell’host, quindi le sue connessioni successive seguono la tabella di instradamento dell’host. Un profilo a tunnel completo le trasporta; un tunnel diviso forse no. Se la VPN dell’host usa controlli per applicazione, aggiungi il binario del relè all’insieme consentito, altrimenti il relè continua a usare l’interfaccia fisica mentre il browser sembra protetto.

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

Esegui i primi due comandi prima e dopo aver connesso la VPN dell’host. Se l’indirizzo non cambia, il relè non è sul tunnel, qualunque cosa dica la finestra del client. Un tunnel solo per reti private lascia anche le destinazioni pubbliche sull’uscita normale dell’host, cosa che sembra una fuga ma è la politica che hai configurato.

Il DNS viene risolto sull’host per il traffico che passa dal relè, quindi il resolver dell’host decide quale server vede i nomi. Un’impostazione DNS privata sul telefono non attraversa il relè, e un test del resolver lato telefono non descriverà le richieste dell’host.

Verifica ogni salto separatamente

Tre controlli, in questo ordine: il telefono raggiunge il relè, il relè raggiunge la destinazione secondo la politica dell’host, e l’applicazione risolve e usa correttamente quella destinazione. Fermati al primo errore invece di ricaricare pagine e tirare a indovinare.

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

Una voce di rete VPN nel dump della connettività mostra che il servizio di cattura è attivo; il registro del relè mostra se arrivano flussi. L’assenza in uno dei due separa nettamente il problema: nessuna cattura significa lato telefono, nessun flusso significa lato host.

Un browser che funziona sull’host dimostra il percorso del browser dell’host, non quello del processo relè. Confronta gli indirizzi che ciascuno riporta, e prova una risorsa privata oltre a una pagina pubblica, perché un tunnel solo per reti private può instradare una e non l’altra.

Smonta e scegli il comportamento in caso di guasto

Il ripristino fa parte del manuale. Ferma e rimuovi il relè, disinstalla il client di cattura e revoca l’autorizzazione di debug dell’host dalle opzioni sviluppatore del telefono quando il compito è concluso.

gnirehtet stop
gnirehtet uninstall
adb kill-server

Decidi cosa deve fare il telefono quando il relè sparisce. Senza una scelta esplicita può ricadere sui dati mobili e far trapelare il traffico che stavi cercando di instradare, quindi imposta deliberatamente il comportamento di blocco delle connessioni o la politica VPN e prova lo smontaggio prima di fidartene.

Annota l’host autorizzato, la versione del relè, la politica di tunnel dell’host e i passaggi di smontaggio. È quella registrazione che rende ripetibile la prossima configurazione di tethering inverso invece di un altro pomeriggio di riscoperta.