Umgekehrtes Tethering für Android über USB: Befehle, Prüfungen, Rückbau

Umgekehrtes Tethering verlagert den Datenverkehr eines Telefons auf einen Computer und führt ihn über dessen Verbindung nach außen. Ein USB-Kabel allein leistet das nicht: Das Telefon braucht einen Erfassungsdienst, der sein Routing übernimmt, und der Computer ein Relay, das die Pakete weiterbefördert. Der Pfad hat vier Sprünge: Anwendung, Erfassung auf dem Telefon, USB-Relay und Host-Ausgang, und jeder hat einen anderen Verantwortlichen. Dieses Runbook baut diesen Pfad auf, setzt das Host-VPN an die richtige Stelle und prüft jeden Sprung, bevor Sie dem Ergebnis trauen.

Ordnen Sie die Sprünge zu, bevor Sie etwas ausführen

Jeder Sprung wendet seine eigene Richtlinie an, deshalb sagt ein funktionierendes Ergebnis an einem Ende nichts über das andere aus. Die Anwendung wählt Ziel und Resolver, der Erfassungsdienst entscheidet, welcher Verkehr ins Relay gelangt, das Relay leitet in Host-Sockets weiter, und Routing und VPN des Hosts bestimmen die Adresse, die das Ziel schließlich sieht.

Nur ein Client des VPN-Dienstes kann die Erfassungsrolle des Telefons zugleich halten, daher stapelt sich eine zweite gewöhnliche VPN-App nicht über dem Relay. Gehört das VPN auf den Computer, ist der Erfassungsdienst das Zugangsglied zu diesem Computer, kein Beweis, dass ein Remote-Tunnel das Ergebnis bereits schützt.

Bereiten Sie das Relay vor, bevor Sie das Telefon anfassen

Gnirehtet ist das dokumentierte Beispiel dieser Architektur: ein Client des VPN-Dienstes ohne Root auf dem Telefon plus ein über ADB getragenes Relay auf dem Host, mit Unterstützung für TCP und UDP über IPv4. Sein Repository führt außerdem an, dass das Projekt nicht mehr aktiv gepflegt wird, behandeln Sie es daher als Referenzdesign und funktionierendes Werkzeug für ein Labor, nicht als unterstütztes Produkt zur Standardisierung über einen verwalteten Gerätebestand.

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

Führen Sie zuerst adb devices aus. Ein Telefon, das den Debugging-Schlüssel des Hosts nicht akzeptiert hat, meldet sich als nicht autorisiert, und das Relay verbindet sich nicht, bis die Abfrage auf dem Gerät angenommen ist. gnirehtet run installiert den Client, startet das Relay und aktiviert die Erfassung; verwenden Sie bei einer Version, die die Schritte trennt, stattdessen die dokumentierten Unterbefehle install, relay und start.

ADB-Zugriff ist eine Gerätesteuerungsbeziehung, keine Netzwerkeinstellung. Autorisieren Sie nur einen Computer, den Sie kontrollieren, und planen Sie, diese Autorisierung nach Abschluss der Aufgabe zu widerrufen.

Setzen Sie das Host-VPN wieder in den Pfad

Das Relay ist ein gewöhnlicher Host-Prozess, seine weiteren Verbindungen folgen daher der Routing-Tabelle des Hosts. Ein Volltunnel-Profil trägt sie; ein geteilter Tunnel womöglich nicht. Nutzt das Host-VPN Steuerungen pro App, nehmen Sie das Relay-Binary in die zulässige Menge auf, sonst verwendet das Relay weiter die physische Schnittstelle, während der Browser geschützt aussieht.

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

Führen Sie die ersten beiden Befehle vor und nach dem Verbinden des Host-VPN aus. Ändert sich die Adresse nicht, ist das Relay nicht im Tunnel, was das Client-Fenster auch sagt. Ein reiner Privatnetz-Tunnel lässt öffentliche Ziele zudem auf dem normalen Host-Ausgang, was wie ein Leck aussieht, aber die von Ihnen konfigurierte Richtlinie ist.

DNS wird für den Verkehr über das Relay auf dem Host aufgelöst, daher entscheidet der Resolver des Hosts, welcher Server die Namen sieht. Eine private DNS-Einstellung auf dem Telefon wird nicht über das Relay übertragen, und ein Resolver-Test auf dem Telefon beschreibt die Abfragen des Hosts nicht.

Prüfen Sie jeden Sprung einzeln

Drei Prüfungen in dieser Reihenfolge: Das Telefon erreicht das Relay, das Relay erreicht das Ziel unter der Richtlinie des Hosts, und die App löst das Ziel korrekt auf und nutzt es. Halten Sie beim ersten Fehler an, statt Seiten neu zu laden und zu raten.

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

Ein VPN-Netzwerkeintrag im Konnektivitäts-Dump zeigt, dass der Erfassungsdienst aktiv ist; das eigene Protokoll des Relays zeigt, ob Ströme ankommen. Fehlt der Eintrag in einem der beiden, teilt das das Problem sauber: keine Erfassung bedeutet Telefonseite, keine Ströme bedeuten Hostseite.

Ein Browser, der auf dem Host funktioniert, beweist den Pfad des Host-Browsers, nicht den des Relay-Prozesses. Vergleichen Sie die Adressen, die jeder meldet, und testen Sie eine private Ressource ebenso wie eine öffentliche Seite, denn ein reiner Privatnetz-Tunnel kann das eine routen und das andere nicht.

Bauen Sie ab und wählen Sie das Fehlerverhalten

Der Rückbau gehört zum Runbook. Stoppen und entfernen Sie das Relay, deinstallieren Sie den Erfassungs-Client und widerrufen Sie die Debugging-Autorisierung des Hosts in den Entwickleroptionen des Telefons, wenn die Aufgabe erledigt ist.

gnirehtet stop
gnirehtet uninstall
adb kill-server

Entscheiden Sie, was das Telefon tun soll, wenn das Relay verschwindet. Ohne bewusste Wahl fällt es womöglich auf mobile Daten zurück und lässt den Verkehr austreten, den Sie routen wollten, legen Sie daher das Verbindungssperrverhalten oder die VPN-Richtlinie bewusst fest und testen Sie den Abbau, bevor Sie sich darauf verlassen.

Halten Sie den autorisierten Host, die Relay-Version, die Tunnelrichtlinie des Hosts und die Abbauschritte fest. Diese Aufzeichnung macht die nächste Einrichtung des umgekehrten Tetherings wiederholbar statt eines weiteren Nachmittags voller Wiederentdeckung.