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.

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

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.

Articole similare