Omvänt tethering för Android via USB: kommandon, kontroller, återställning

Omvänt tethering flyttar en telefons trafik till en dator och leder ut den genom datorns anslutning. En USB-kabel ensam gör inte det: telefonen behöver en fångsttjänst som tar över dess routing, och datorn behöver ett relä som bär paketen vidare. Vägen har fyra hopp: applikation, fångst på telefonen, USB-relä och värdens utgång, och varje hopp har en egen ägare. Den här runboken bygger vägen, sätter värdens VPN där det hör hemma och kontrollerar varje hopp innan du litar på resultatet.

Kartlägg hoppen innan du kör något

Varje hopp tillämpar sin egen policy, därför säger ett fungerande resultat i ena änden ingenting om den andra. Applikationen väljer en destination och en resolver, fångsttjänsten avgör vilken trafik som kommer in i reläet, reläet vidarebefordrar till värdens sockets, och värdens routing och VPN avgör adressen som destinationen till slut ser.

Bara en klient till VPN-tjänsten kan hålla telefonens fångstroll åt gången, så en andra vanlig VPN-app staplas inte ovanpå reläet. Om VPN:en hör till datorn är fångsttjänsten anslutningslänken mot den datorn, inte ett bevis på att en fjärrtunnel redan skyddar resultatet.

Förbered reläet innan du rör telefonen

Gnirehtet är det dokumenterade exemplet på den här arkitekturen: en klient till VPN-tjänsten utan root på telefonen plus ett relä som bärs via ADB på värden, med stöd för TCP och UDP över IPv4. Dess arkiv anger också att projektet inte längre underhålls aktivt, så behandla det som referensdesignen och ett fungerande verktyg för ett labb, inte som en stödd produkt att standardisera över en hanterad flotta.

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

Kör adb devices först. En telefon som inte har accepterat värdens felsökningsnyckel rapporteras som obehörig, och reläet ansluter inte förrän uppmaningen på enheten accepteras. gnirehtet run installerar klienten, startar reläet och aktiverar fångsten; på en version som delar stegen, använd i stället de dokumenterade underkommandona install, relay och start.

ADB-åtkomst är en enhetskontrollrelation, inte en nätverksinställning. Auktorisera bara en dator som du kontrollerar, och planera att återkalla auktorisationen när uppgiften är klar.

Sätt tillbaka värdens VPN i vägen

Reläet är en vanlig värdprocess, så dess vidare anslutningar följer värdens routingtabell. En fulltunnelprofil bär dem; en delad tunnel kanske inte. Om värdens VPN använder styrning per app, lägg till reläets binär i den tillåtna mängden, annars fortsätter reläet att använda det fysiska gränssnittet medan webbläsaren ser skyddad ut.

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

Kör de två första kommandona före och efter att du ansluter värdens VPN. Om adressen inte ändras är reläet inte på tunneln, vad klientfönstret än säger. En enbart privat tunnel lämnar också offentliga destinationer på värdens vanliga utgång, vilket ser ut som en läcka men är policyn du ställde in.

DNS löses på värden för trafik genom reläet, så värdens resolver avgör vilken server som ser namnen. En privat DNS-inställning på telefonen följer inte med över reläet, och ett resolvertest på telefonsidan beskriver inte värdens uppslag.

Verifiera varje hopp separat

Tre kontroller, i den här ordningen: telefonen når reläet, reläet når destinationen under värdens policy, och appen löser och använder destinationen korrekt. Stanna vid det första felet i stället för att ladda om sidor och gissa.

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

En VPN-nätverkspost i anslutningsdumpen visar att fångsttjänsten är aktiv; reläets egen logg visar om flöden kommer in. Saknas det i en av dem delar det problemet rent: ingen fångst betyder telefonsidan, inga flöden betyder värdsidan.

En webbläsare som fungerar på värden bevisar värdwebbläsarens väg, inte reläprocessens. Jämför adresserna som var och en rapporterar, och testa en privat resurs såväl som en offentlig sida, eftersom en enbart privat tunnel kan routa den ena och inte den andra.

Riv ned och välj felbeteendet

Återställning är en del av runboken. Stoppa och ta bort reläet, avinstallera fångstklienten, och återkalla värdens felsökningsauktorisation i telefonens utvecklaralternativ när uppgiften är klar.

gnirehtet stop
gnirehtet uninstall
adb kill-server

Bestäm vad telefonen ska göra när reläet försvinner. Utan ett medvetet val kan den falla tillbaka på mobildata och läcka trafiken du försökte routa, så ställ in blockeringsbeteendet eller VPN-policyn med avsikt och testa nedrivningen innan du litar på den.

Notera vilken värd som auktoriserades, reläversionen, värdens tunnelpolicy och nedrivningsstegen. Det är den noteringen som gör nästa uppsättning av omvänt tethering repeterbar i stället för ännu en eftermiddag av återupptäckt.