Omvendt tethering for Android over USB: kommandoer, kontroller, tilbagerulning

Omvendt tethering flytter en telefons trafik til en computer og ud gennem computerens forbindelse. Et USB-kabel alene gør det ikke: telefonen har brug for en optagelsestjeneste, der overtager dens routing, og computeren har brug for et relæ, der bærer pakkerne videre. Stien har fire hop: applikation, optagelse på telefonen, USB-relæ og værtens udgang, og hvert hop har sin egen ejer. Denne kørebog bygger stien, sætter værtens VPN, hvor det hører til, og kontrollerer hvert hop, før du tror på resultatet.

Kortlæg hopene, før du kører noget

Hvert hop anvender sin egen politik, og derfor siger et fungerende resultat i den ene ende intet om den anden. Applikationen vælger en destination og en resolver, optagelsestjenesten afgør, hvilken trafik der kommer ind i relæet, relæet videresender til værtens sockets, og værtens routing og VPN afgør den adresse, destinationen til sidst ser.

Kun én klient til VPN-tjenesten kan holde telefonens optagelsesrolle ad gangen, så en anden almindelig VPN-app lægger sig ikke oven på relæet. Hvis VPN’en hører på computeren, er optagelsestjenesten adgangsleddet mod den computer, ikke et bevis på, at en fjern tunnel allerede beskytter resultatet.

Forbered relæet, før du rører telefonen

Gnirehtet er det dokumenterede eksempel på denne arkitektur: en klient til VPN-tjenesten uden root på telefonen plus et relæ, der bæres via ADB på værten, med støtte til TCP og UDP over IPv4. Dets repositorium angiver også, at projektet ikke længere vedligeholdes aktivt, så behandl det som referencedesignet og et fungerende værktøj til et laboratorium, ikke som et understøttet produkt at standardisere på tværs af en administreret flåde.

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

Kør adb devices først. En telefon, der ikke har accepteret værtens fejlretningsnøgle, rapporteres som uautoriseret, og relæet tilslutter sig ikke, før anmodningen på enheden accepteres. gnirehtet run installerer klienten, starter relæet og aktiverer optagelsen; på en version, der deler trinnene, skal du i stedet bruge de dokumenterede underkommandoer install, relay og start.

ADB-adgang er et enhedskontrolforhold, ikke en netværksindstilling. Autoriser kun en computer, du styrer, og planlæg at tilbagekalde autorisationen, når opgaven er færdig.

Sæt værtens VPN tilbage i stien

Relæet er en almindelig proces på værten, så dets videre forbindelser følger værtens rutetabel. En fuldtunnelprofil bærer dem; en opdelt tunnel måske ikke. Hvis værtens VPN bruger styring pr. app, skal du føje relæets binære fil til det tilladte sæt, ellers bruger relæet fortsat det fysiske interface, mens browseren ser beskyttet ud.

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

Kør de to første kommandoer før og efter tilslutning af værtens VPN. Hvis adressen ikke ændrer sig, er relæet ikke på tunnelen, uanset hvad klientvinduet siger. En tunnel kun til private netværk efterlader også offentlige destinationer på værtens normale udgang, hvilket ligner en lækage, men er den politik, du har konfigureret.

DNS opløses på værten for trafik gennem relæet, så værtens resolver afgør, hvilken server der ser navnene. En privat DNS-indstilling på telefonen følger ikke med gennem relæet, og en resolvertest på telefonen vil ikke beskrive værtens opslag.

Verificér hvert hop separat

Tre kontroller i denne rækkefølge: telefonen når relæet, relæet når destinationen under værtens politik, og appen opløser og bruger destinationen korrekt. Stop ved den første fejl i stedet for at genindlæse sider og gætte.

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

En VPN-netværkspost i forbindelsesdumpen viser, at optagelsestjenesten er aktiv; relæets egen log viser, om strømme ankommer. Fravær i en af dem deler problemet rent: ingen optagelse betyder telefonsiden, ingen strømme betyder værtssiden.

En browser, der virker på værten, beviser værtbrowserens sti, ikke relæprocessens. Sammenlign de adresser, hver af dem rapporterer, og test en privat ressource såvel som en offentlig side, fordi en tunnel kun til private netværk kan route den ene og ikke den anden.

Ryd op, og vælg fejladfærden

Tilbagerulning er en del af kørebogen. Stop og fjern relæet, afinstaller optagelsesklienten, og tilbagekald værtens fejlretningsautorisation i telefonens udviklerindstillinger, når opgaven er færdig.

gnirehtet stop
gnirehtet uninstall
adb kill-server

Beslut, hvad telefonen skal gøre, når relæet forsvinder. Uden et bevidst valg kan den falde tilbage til mobildata og lække den trafik, du forsøgte at route, så indstil blokeringsadfærden eller VPN-politikken med vilje, og test nedtagningen, før du stoler på den.

Notér den vært, der blev autoriseret, relæversionen, værtens tunnelpolitik og nedtagningstrinnene. Den registrering er det, der gør den næste opsætning af omvendt tethering gentagelig i stedet for endnu en eftermiddag med genopdagelse.