Android-SSH-SOCKS-Proxy: Warum nur die Hälfte der Apps verbindet

Du meldest dich per SSH an, ergänzt -D 1080, und der Befehl läuft durch. Jetzt existiert ein SOCKS-Listener auf dem Telefon, und die Hälfte der Apps geht weiter über mobile Daten. Das ist das normale Ergebnis, kein kaputter Tunnel: ssh -D erzeugt einen Proxy-Endpunkt, und Android-Apps nutzen einen Proxy nur, wenn etwas sie dazu bringt. Der Weg durch die Kette zeigt Schritt für Schritt, wo jeder Teil der Aufgabe tatsächlich sitzt.

Dort anfangen, wo der Datenverkehr beginnt

Wähle eine App, die den Tunnel nutzen soll, und prüfe, ob sie eine eigene Proxy-Einstellung hat. Ein Browser mit SOCKS-Feld ist der einfache Fall: dort 127.0.0.1:1080 eintragen, remote DNS aktivieren, falls die Einstellung existiert, und die Anfrage geht durch. Ein Chat-Client, eine Karten-App oder ein Spiel ohne solches Feld kann den Listener nicht nutzen, und nichts im SSH-Befehl ändert daran etwas.

Bevor du etwas anderes einbeziehst, beweise, dass der Listener aus der Shell des Telefons mit einem SOCKS-fähigen Client funktioniert:

ssh -N -D 1080 [email protected]
curl --socks5-hostname 127.0.0.1:1080 https://ifconfig.me

Die zurückkommende Adresse sollte die des SSH-Servers sein, nicht die des Telefons. Ist das der Fall, ist die Proxy-Hälfte erledigt, und der Rest dreht sich um Abdeckung. Wenn nicht, repariere zuerst die SSH-Seite: Schlüssel-Authentifizierung, die Erreichbarkeit des Ziels vom Server aus und den eigenen Ausgang des SSH-Servers.

Das fehlende Stück für Android ergänzen

Apps ohne Proxy-Einstellung brauchen etwas, das ihre Pakete abgreift und in Proxy-Verbindungen umwandelt. Auf einem Gerät ohne Root ist das ein VPN-Dienst-Adapter: eine App, die das virtuelle Interface übernimmt und ausgewählten Verkehr in den lokalen SOCKS-Listener leitet. Die Kette lautet dann App, Adapter, SOCKS-Listener, SSH-Verbindung, Ziel.

Installiere den Adapter, erteile ihm die VPN-Berechtigung und wähle die Apps oder Routen, die er erfassen soll. Das Schlüsselsymbol in der Statusleiste steht dann für den Adapter, nicht für ein separates kommerzielles VPN. Android erlaubt pro Nutzerprofil nur eine aktive VPN-Dienst-Verbindung, ein zweites VPN hinzuzuschalten legt also keine Ebene darüber, sondern konkurriert um dieselbe Rolle.

In diesem Schritt kann ein erfolgreicher Test dich täuschen. Erfasst der Adapter nur den Browser, den du ohnehin auf den Proxy zeigst, funktioniert alles, und nichts anderes ist abgedeckt. Lies die Erfassungsliste, bevor du das Gerät als getunnelt betrachtest.

Den SSH-Transport aus der Erfassung heraushalten

Die SSH-Verbindung selbst darf nicht wieder in den SOCKS-Tunnel gelangen, den sie aufrechterhält. Erfasst der Adapter den Verkehr der SSH-App, hängt der Tunnel an einer Verbindung, die auf den Tunnel wartet, und das Ergebnis ist eine Schleife, die stockt oder scheitert, sobald der Adapter startet.

Integrierte Umsetzungen schützen ihren eigenen Transport-Socket. Mit getrennten Apps brauchst du eine unterstützte Ausnahme: die SSH-App außerhalb der Erfassung lassen oder den SSH-Endpunkt per Adresse ausnehmen. Beides hat Kosten. Eine ganze Terminal-App auszunehmen entfernt auch ihre übrige Netzaktivität aus dem Tunnel, und eine Adressausnahme bricht, wenn sich die Serveradresse ändert oder der Name bei der nächsten Verbindung anders aufgelöst wird.

Prüfe die Ausnahme von außen: verbinde den Adapter neu und bestätige, dass die SSH-Sitzung überlebt und die Proxy-Anfrage weiterhin die Serveradresse meldet. Eine Sitzung, die bis zum Start des Adapters läuft und dann einfriert, ist die Schleife.

DNS und UDP bis zum Ende der Kette verfolgen

Der dynamische Forward von OpenSSH trägt TCP-Verbindungen. Er ist kein UDP-Associate und kein ICMP-Transport, und ein Adapter kann keine UDP-Weiterleitung erfinden, indem er UDP-Pakete annimmt. Alles, was auf UDP besteht, etwa QUIC und WebRTC-Medien, scheitert oder fällt je nach App auf TCP zurück.

DNS braucht eine eigene Entscheidung. Eine App, die einen Namen lokal auflöst, schickt die Abfrage über den normalen Resolver, bevor sie sich verbindet, der Tunnel trägt also die Verbindung, aber nicht die Auflösung. Ein proxybewusster Client mit Remote-DNS-Option vermeidet das, eine erfasste App ohne eine solche Option nicht. Prüfe, welcher Resolver geantwortet hat, statt anzunehmen, der Adapter habe daran etwas geändert.

Halte den SOCKS-Listener an Loopback gebunden, prüfe den Hostkey des SSH-Servers bei der ersten Nutzung und lass die normale HTTPS-Prüfung für die endgültige Seite bestehen. SSH schützt die Strecke vom Telefon zum Server, es verschlüsselt nicht, was der Server danach tut.

Beide Lebensdauern prüfen und entscheiden

Adapter und SSH-Sitzung haben getrennte Lebensdauern. Bricht SSH ab, während der Adapter weiter erfasst, können Apps ohne klaren Fehler hängen, weil ihre Pakete weiter in ein virtuelles Interface laufen, das keinen funktionierenden Ausgang mehr hat. Stoppt der Adapter, gehen Apps je nach VPN-Richtlinie des Geräts direkt raus oder werden blockiert.

Teste beide Richtungen bewusst: beende die SSH-Sitzung bei laufendem Adapter, dann stoppe den Adapter bei bestehender SSH-Verbindung. Was das Telefon jeweils tut, ist die Richtlinie, die du wirklich ausrollst, egal was die Anleitung behauptet.

Braucht der Arbeitsablauf eine Abdeckung für das ganze Gerät mit vorhersehbarem Fehlerverhalten, ist ein echtes IP-VPN oder ein gepflegter Adapter für diese Kette die ehrliche Antwort. Eine Shell-Sitzung neben einer unabhängigen Erfassungs-App ist kein gepflegter Geräte-Tunnel, sondern zwei Komponenten ohne Absprache darüber, was passiert, wenn eine endet.