Omgekeerd tethering voor Android via USB: opdrachten, controles, terugdraaien

Omgekeerd tethering verplaatst het verkeer van een telefoon naar een computer en voert het uit via de verbinding van die computer. Een USB-kabel alleen doet dat niet: de telefoon heeft een onderscheppingsdienst nodig die het routeren overneemt, en de computer een relay die de pakketten verder draagt. Het pad heeft vier sprongen: toepassing, onderschepping op de telefoon, USB-relay en de uitgang van de host, en elk heeft een andere eigenaar. Dit draaiboek bouwt dat pad, zet de VPN van de host op de juiste plek en controleert elke sprong voordat je het resultaat vertrouwt.

Breng de sprongen in kaart voordat je iets uitvoert

Elke sprong past zijn eigen beleid toe, daarom zegt een werkend resultaat aan de ene kant niets over de andere. De toepassing kiest een bestemming en een resolver, de onderscheppingsdienst bepaalt welk verkeer de relay in gaat, de relay stuurt door naar de sockets van de host, en het routeren en de VPN van de host bepalen het adres dat de bestemming uiteindelijk ziet.

Slechts één client van de VPN-dienst kan tegelijk de onderscheppingsrol van de telefoon hebben, dus een tweede gewone VPN-app stapelt niet op de relay. Hoort de VPN op de computer, dan is de onderscheppingsdienst de toegangsschakel naar die computer, geen bewijs dat een externe tunnel het resultaat al beschermt.

Bereid de relay voor voordat je de telefoon aanraakt

Gnirehtet is het gedocumenteerde voorbeeld van deze architectuur: een client van de VPN-dienst zonder root op de telefoon plus een relay die via ADB op de host wordt gedragen, met ondersteuning voor TCP en UDP over IPv4. De repository vermeldt ook dat het project niet meer actief wordt onderhouden, behandel het dus als het referentieontwerp en een werkend hulpmiddel voor een lab, niet als een ondersteund product om over een beheerde vloot te standaardiseren.

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

Voer eerst adb devices uit. Een telefoon die de foutopsporingssleutel van de host niet heeft geaccepteerd, wordt als niet-geautoriseerd gemeld, en de relay maakt geen verbinding tot de melding op het apparaat wordt geaccepteerd. gnirehtet run installeert de client, start de relay en activeert de onderschepping; gebruik op een versie die de stappen scheidt in plaats daarvan de gedocumenteerde subopdrachten install, relay en start.

ADB-toegang is een apparaatbeheerrelatie, geen netwerkinstelling. Autoriseer alleen een computer die je beheert, en plan om die autorisatie in te trekken als de taak klaar is.

Zet de VPN van de host terug in het pad

De relay is een gewoon hostproces, dus zijn verdere verbindingen volgen de routetabel van de host. Een volledig-tunnelprofiel draagt ze; een gesplitste tunnel misschien niet. Als de VPN van de host besturing per app gebruikt, voeg het relay-binary toe aan de toegestane set, anders blijft de relay de fysieke interface gebruiken terwijl de browser beschermd lijkt.

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

Voer de eerste twee opdrachten uit voor en na het verbinden van de VPN van de host. Verandert het adres niet, dan zit de relay niet op de tunnel, wat het clientvenster ook zegt. Een alleen-privé tunnel laat openbare bestemmingen ook op de normale uitgang van de host, wat op een lek lijkt maar het beleid is dat je hebt ingesteld.

DNS wordt op de host opgelost voor verkeer via de relay, dus de resolver van de host bepaalt welke server de namen ziet. Een privé-DNS-instelling op de telefoon gaat niet mee over de relay, en een resolvertest aan de telefoonkant beschrijft de opzoekingen van de host niet.

Controleer elke sprong apart

Drie controles, in deze volgorde: de telefoon bereikt de relay, de relay bereikt de bestemming onder het beleid van de host, en de app lost die bestemming correct op en gebruikt hem. Stop bij de eerste fout in plaats van pagina’s te herladen en te gissen.

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

Een VPN-netwerkregel in de connectiviteitsdump toont dat de onderscheppingsdienst actief is; het log van de relay zelf toont of stromen aankomen. Ontbreekt het in een van beide, dan splitst dat het probleem netjes: geen onderschepping betekent de telefoonkant, geen stromen de hostkant.

Een browser die op de host werkt, bewijst het pad van de hostbrowser, niet dat van het relayproces. Vergelijk de adressen die elk melden, en test zowel een privébron als een openbare pagina, want een alleen-privé tunnel kan het ene routeren en het andere niet.

Breek af en kies het foutgedrag

Terugdraaien hoort bij het draaiboek. Stop en verwijder de relay, verwijder de onderscheppingsclient, en trek de foutopsporingsautorisatie van de host in bij de ontwikkelaarsopties van de telefoon als de taak klaar is.

gnirehtet stop
gnirehtet uninstall
adb kill-server

Bepaal wat de telefoon moet doen als de relay verdwijnt. Zonder bewuste keuze kan hij terugvallen op mobiele data en het verkeer lekken dat je wilde routeren, dus stel het blokkeergedrag of het VPN-beleid bewust in en test het afbreken voordat je erop vertrouwt.

Noteer welke host is geautoriseerd, de relayversie, het tunnelbeleid van de host en de afbreekstappen. Die registratie maakt de volgende opzet van omgekeerd tethering herhaalbaar in plaats van weer een middag herontdekken.