Tethering invers pentru Android prin USB: comenzi, verificări, revenire
Tetheringul invers trimite traficul telefonului printr-un releu de pe gazdă. Construiește calea de la telefon la gazdă, ține VPN-ul gazdei în buclă și verifică fiecare salt.
Tetheringul invers mută traficul unui telefon pe un calculator și îl scoate prin conexiunea acelui calculator. Un cablu USB singur nu face asta: telefonul are nevoie de un serviciu de captură care preia rutarea, iar calculatorul de un releu care duce mai departe pachetele. Calea are patru salturi: aplicația, captura pe telefon, releul USB și ieșirea gazdei, iar fiecare are alt proprietar. Acest ghid construiește acea cale, pune VPN-ul gazdei la locul lui și verifică fiecare salt înainte să ai încredere în rezultat.
Cartografiază salturile înainte să rulezi ceva
Fiecare salt aplică propria politică, de aceea un rezultat care funcționează la un capăt nu spune nimic despre celălalt. Aplicația alege o destinație și un resolver, serviciul de captură decide ce trafic intră în releu, releul transmite către socketurile gazdei, iar rutarea și VPN-ul gazdei decid adresa pe care destinația o vede în final.
| 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 |
Doar un client al serviciului VPN poate ține rolul de captură al telefonului o dată, așa că o a doua aplicație VPN obișnuită nu se suprapune peste releu. Dacă VPN-ul aparține calculatorului, serviciul de captură este veriga de acces către acel calculator, nu dovada că un tunel la distanță protejează deja rezultatul.
Pregătește releul înainte să atingi telefonul
Gnirehtet este exemplul documentat al acestei arhitecturi: un client al serviciului VPN fără root pe telefon plus un releu purtat prin ADB pe gazdă, cu suport pentru TCP și UDP peste IPv4. Repozitoriul său arată și că proiectul nu mai este întreținut activ, așa că tratează-l ca proiect de referință și unealtă funcțională pentru laborator, nu ca produs cu suport de standardizat pe un parc administrat.
adb devices
adb shell getprop ro.build.version.release
gnirehtet run
Rulează mai întâi adb devices. Un telefon care nu a acceptat cheia de depanare a gazdei este raportat ca neautorizat, iar releul nu se conectează până când promptul de pe dispozitiv nu este acceptat. gnirehtet run instalează clientul, pornește releul și activează captura; într-o versiune care separă pașii, folosește în schimb subcomenzile documentate install, relay și start.
Accesul ADB este o relație de control al dispozitivului, nu o setare de rețea. Autorizează doar un calculator pe care îl controlezi și plănuiește revocarea acelei autorizări când sarcina se termină.
Pune VPN-ul gazdei înapoi pe cale
Releul este un proces obișnuit al gazdei, așa că legăturile lui ulterioare urmează tabelul de rutare al gazdei. Un profil de tunel complet le transportă; un tunel divizat poate că nu. Dacă VPN-ul gazdei folosește controale pe aplicație, adaugă binarul releului în setul permis, altfel releul continuă să folosească interfața fizică în timp ce browserul pare protejat.
ip route get 1.1.1.1
curl -4 https://ifconfig.me
sudo ss -tnp | grep -i relay
Rulează primele două comenzi înainte și după conectarea VPN-ului gazdei. Dacă adresa nu se schimbă, releul nu este în tunel, orice ar spune fereastra clientului. Un tunel doar privat lasă și destinațiile publice pe ieșirea normală a gazdei, ceea ce arată ca o scurgere dar este politica pe care ai setat-o.
DNS-ul este rezolvat pe gazdă pentru traficul prin releu, așa că resolverul gazdei decide ce server vede numele. O setare DNS privată pe telefon nu trece prin releu, iar un test al resolverului pe partea telefonului nu va descrie interogările gazdei.
Verifică fiecare salt separat
Trei verificări, în această ordine: telefonul ajunge la releu, releul ajunge la destinație sub politica gazdei, iar aplicația rezolvă și folosește corect acea destinație. Oprește-te la prima eroare în loc să reîncarci pagini și să ghicești.
adb shell dumpsys connectivity | grep -i -A3 vpn
adb logcat -s GnirehtetRelay:V Gnirehtet:V
O intrare de rețea VPN în dump-ul de conectivitate arată că serviciul de captură este activ; jurnalul releului arată dacă sosesc fluxuri. Absența într-unul dintre ele separă curat problema: fără captură este partea telefonului, fără fluxuri partea gazdei.
Un browser care funcționează pe gazdă dovedește calea browserului gazdei, nu pe cea a procesului releului. Compară adresele pe care fiecare le raportează și testează o resursă privată precum și o pagină publică, fiindcă un tunel doar privat poate ruta una și nu pe cealaltă.
Demontază și alege comportamentul la eroare
Revenirea face parte din ghid. Oprește și elimină releul, dezinstalează clientul de captură și revocă autorizarea de depanare a gazdei din opțiunile de dezvoltator ale telefonului când sarcina s-a terminat.
gnirehtet stop
gnirehtet uninstall
adb kill-server
Decide ce trebuie să facă telefonul când releul dispare. Fără o alegere explicită poate reveni la datele mobile și poate scurge traficul pe care încercai să îl rutezi, așa că setează deliberat comportamentul de blocare a conexiunilor sau politica VPN și testează demontarea înainte să te bazezi pe ea.
Notează gazda care a fost autorizată, versiunea releului, politica de tunel a gazdei și pașii de demontare. Acea înregistrare face următoarea configurare de tethering invers repetabilă în loc de încă o după-amiază de redescoperire.