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

Omvendt tethering flytter en telefons trafikk til en datamaskin og fører den ut gjennom datamaskinens tilkobling. En USB-kabel alene gjør ikke dette: telefonen trenger en fangsttjeneste som tar over rutingen, og datamaskinen trenger et relé som bærer pakkene videre. Stien har fire hopp: applikasjon, fangst på telefonen, USB-relé og vertens utgang, og hvert har en annen eier. Denne kjøreboken bygger stien, setter vertens VPN der det hører hjemme, og kontrollerer hvert hopp før du tror på resultatet.

Kartlegg hoppene før du kjører noe

Hvert hopp bruker sin egen policy, derfor sier et fungerende resultat i den ene enden ingenting om den andre. Applikasjonen velger en destinasjon og en resolver, fangsttjenesten avgjør hvilken trafikk som kommer inn i reléet, reléet videresender til vertens sockets, og vertens ruting og VPN avgjør adressen destinasjonen til slutt ser.

Bare én klient av VPN-tjenesten kan holde telefonens fangstrolle om gangen, så en annen vanlig VPN-app legger seg ikke oppå reléet. Hvis VPN-en hører til datamaskinen, er fangsttjenesten tilkoblingsleddet mot den datamaskinen, ikke et bevis på at en ekstern tunnel allerede beskytter resultatet.

Klargjør reléet før du tar på telefonen

Gnirehtet er det dokumenterte eksempelet på denne arkitekturen: en klient av VPN-tjenesten uten root på telefonen pluss et relé som bæres via ADB på verten, med støtte for TCP og UDP over IPv4. Repositoriet angir også at prosjektet ikke lenger vedlikeholdes aktivt, så behandle det som referansedesignet og et fungerende verktøy for et laboratorium, ikke som et støttet produkt å standardisere på tvers av en administrert flåte.

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

Kjør adb devices først. En telefon som ikke har godtatt vertens feilsøkingsnøkkel rapporteres som uautorisert, og reléet kobler seg ikke til før forespørselen på enheten godtas. gnirehtet run installerer klienten, starter reléet og aktiverer fangsten; på en versjon som deler trinnene, bruk i stedet de dokumenterte underkommandoene install, relay og start.

ADB-tilgang er et enhetskontrollforhold, ikke en nettverksinnstilling. Autoriser bare en datamaskin du kontrollerer, og planlegg å tilbakekalle autorisasjonen når oppgaven er ferdig.

Sett vertens VPN tilbake i stien

Reléet er en vanlig vertsprosess, så de videre tilkoblingene følger vertens rutetabell. En fulltunnelprofil bærer dem; en delt tunnel kanskje ikke. Hvis vertens VPN bruker styring per app, legg relébinæren til i det tillatte settet, ellers bruker reléet fortsatt det fysiske grensesnittet mens nettleseren ser beskyttet ut.

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

Kjør de to første kommandoene før og etter at du kobler til vertens VPN. Hvis adressen ikke endres, er reléet ikke på tunnelen, uansett hva klientvinduet sier. En bare-privat tunnel lar også offentlige destinasjoner ligge på vertens vanlige utgang, noe som ser ut som en lekkasje, men er policyen du satte.

DNS løses på verten for trafikk gjennom reléet, så vertens resolver avgjør hvilken server som ser navnene. En privat DNS-innstilling på telefonen følger ikke over reléet, og en resolvertest på telefonsiden vil ikke beskrive vertens oppslag.

Verifiser hvert hopp separat

Tre kontroller, i denne rekkefølgen: telefonen når reléet, reléet når destinasjonen under vertens policy, og appen løser og bruker destinasjonen riktig. Stopp ved den første feilen i stedet for å laste sider på nytt og gjette.

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

En VPN-nettverksoppføring i tilkoblingsdumpen viser at fangsttjenesten er aktiv; reléets egen logg viser om strømmer ankommer. Fravær i én av dem deler problemet rent: ingen fangst betyr telefonsiden, ingen strømmer betyr vertssiden.

En nettleser som virker på verten beviser vertsnettleserens sti, ikke reléprosessens. Sammenlign adressene hver av dem rapporterer, og test en privat ressurs så vel som en offentlig side, fordi en bare-privat tunnel kan rute den ene og ikke den andre.

Rydd ned og velg feilatferden

Tilbakerulling er en del av kjøreboken. Stopp og fjern reléet, avinstaller fangstklienten, og tilbakekall vertens feilsøkingsautorisasjon i telefonens utviklerinnstillinger når oppgaven er ferdig.

gnirehtet stop
gnirehtet uninstall
adb kill-server

Bestem hva telefonen skal gjøre når reléet forsvinner. Uten et bevisst valg kan den falle tilbake til mobildata og lekke trafikken du prøvde å rute, så sett blokkeringsatferden eller VPN-policyen med vilje og test nedrivingen før du stole på den.

Noter verten som ble autorisert, reléversjonen, vertens tunnelpolicy og nedrivingstrinnene. Det er den noteringen som gjør neste oppsett av omvendt tethering repeterbart i stedet for nok en ettermiddag med gjenoppdagelse.