Androids Regel für nur ein VPN blockiert keinen SSH-Server auf dem Telefon

Die Überzeugung ist so verbreitet, dass sie als Tatsache gilt: Android erlaubt nur ein VPN, also kann ein SSH-Server auf dem Telefon nicht über diesen Tunnel arbeiten. Die erste Hälfte stimmt, die Schlussfolgerung folgt nicht. Die Plattformgrenze betrifft, wie viele Apps den Platz des VPN-Dienstes belegen dürfen, nicht wie viele Sockets existieren oder wer sich mit dem Telefon verbinden darf. Ein SSH-Daemon mit lauschendem Socket ist eine gewöhnliche App mit einem gewöhnlichen Port, und der Tunnel ist einer der Wege, die ihr Datenverkehr nehmen kann.

Was die Ein-VPN-Regel tatsächlich einschränkt

VpnService ist eine Ressource mit einem Platz. Richtet eine App einen Tunnel ein, wird sie zum VPN des Geräts, und eine zweite App, die es versucht, wird abgewiesen, bis die erste verschwindet. Das ist eine Regel über die Eigentümerschaft des Tunnels, und sie erklärt, warum zwei VPN-Clients nicht gleichzeitig laufen können.

Über lauschende Sockets sagt sie nichts. Der SSH-Server ruft VpnService nicht auf, fängt keine Pakete ab und konkurriert nicht um diesen Platz. Er bindet einen Port und nimmt Verbindungen an, genau wie ohne installiertes VPN. Der Mythos verwechselt also eine Grenze für Tunnelanbieter mit einer Grenze für Netzwerkverbindungen, und beides hat nichts miteinander zu tun.

Der Listener ist ein Ziel, kein Teil des Tunnels

Sobald der Tunnel existiert, hat das Telefon darin eine Adresse, und das Peergerät hat eine Route zu dieser Adresse. Ob etwas antwortet, entscheidet der Listener. Ein an Loopback gebundener Daemon ist nur vom Telefon selbst erreichbar; ein an die alte Tunneladresse gebundener Daemon kann seine Bindung nach einem erneuten Verbinden behalten, obwohl sich die Adresse geändert hat.

Bindungsregeln sind gewöhnliche SSH-Konfiguration: die Lauschadresse und der Port, und wer sich authentifizieren darf. Unter Android stehen diese Einstellungen in der Konfiguration der App selbst, und dem Eigentümer des App-Prozesses ist die Nutzung privilegierter Ports vielleicht nicht erlaubt, sodass die Desktop-Gewohnheit, Port 22 als root zu binden, nicht unverändert übertragbar ist.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Dann kommt die Erlaubnis auf dem Weg selbst. Ein Verbraucher-VPN, das ausgehenden Webverkehr gern befördert, muss eingehende Verbindungen zu seinen Kunden keineswegs zulassen; viele tun es nicht, weil es einen Kunden dem anderen aussetzen würde. Kann der Peer die Tunneladresse des Telefons von nirgendwo erreichen, liegt das Problem in der Richtlinie des Dienstes und nicht im Telefon.

Der Rückweg ist die Stelle, an der es meist bricht

Angenommen, der Peer erreicht die Tunneladresse des Telefons und das SYN kommt an. Nun muss die Antwort denselben Weg hinausnehmen, und das ist eine Routingentscheidung im Telefon. Geht die Antwort über WLAN hinaus, weil das das Standardnetz ist, sieht der Peer eine Verbindung, die nie zustande kommt, und das sieht genau wie eine Firewall aus.

Android macht das komplizierter als ein Desktop, weil das Standardnetz pro Prozess gewählt wird und von der Richtlinie der VPN-App geändert werden kann. Ein VPN-Client kann nur eine Liste erlaubter Apps routen, also nutzt eine Server-App außerhalb dieser Liste weiterhin das physische Netz für ihre Antworten, während der Peer sie durch den Tunnel erwartet.

Eine App kann ihre eigenen Sockets auch an ein bestimmtes Netz binden, was den Standard überschreibt. Wenn Sie einen Bericht lesen, ein Dienst sei von einer Adresse erreichbar und von einer anderen nicht, steckt meist genau dieser Mechanismus dahinter.

Ein VPN zu umgehen repariert keinen eingehenden Dienst

Der beliebte Ausweg, die SSH-App vom VPN auszunehmen, damit ihr Verkehr nicht mehr umgeleitet wird, ist eine Reparatur des umgekehrten Problems. Er hilft, wenn der Transport eines ausgehenden SSH-Clients wegen des Tunnels ständig bricht. Für einen gehosteten Server kann er die Antworten aus dem Tunnel herausbewegen, den der Peer nutzt, und macht damit aus einem Teilausfall einen Totalausfall.

Dasselbe gilt für das Öffnen eines öffentlichen Ports am Router. Wenn die Anforderung ist, dass ein autorisiertes Gerät das Telefon über das VPN erreicht, ist das Freilegen von SSH ins Internet ein anderes Bedrohungsmodell und keine Reparatur.

Entscheiden Sie zuerst die Dienstadresse: die LAN-Adresse des Telefons, seine Tunneladresse oder einen bewusst weitergeleiteten Endpunkt. Jede hat ihren eigenen Vertrag zu Erreichbarkeit und Exposition, und sie zu vermischen ist der Weg, auf dem aus einem kleinen Zugriffsproblem ein dauerhaftes Loch wird.

Diagnostizieren Sie eine Richtung nach der anderen

Notieren Sie vier Fakten, bevor Sie die Konfiguration ändern: die Adresse, mit der der Peer verbindet, den Listener-Zustand auf dem Telefon, den App- und Benutzerkontext, dem er gehört, und den in jeder Richtung beobachteten Weg. Ein Bericht, das VPN trenne SSH, enthält keinen davon und kann ein Transportproblem des Clients nicht von einem unerreichbaren Server unterscheiden.

adb shell ip -br addr
adb shell ip route get 10.90.0.9
nc -vz 10.90.0.4 2222

Führen Sie die Portprüfung vom Peer aus, nicht vom Telefon, und lesen Sie die ausführliche Ausgabe des SSH-Clients, um zu sehen, ob es vor oder nach dem TCP-Handshake scheitert. Ein Socket, der nie verbindet, und eine abgelehnte Anmeldung sind verschiedene Stufen mit verschiedenen Eigentümern.

Lassen Sie Hostschlüsselprüfung und Kontobeschränkungen beim Debuggen intakt. Gerade die Beschränkung des Listeners und der erlaubten Benutzer macht einen erreichbaren Server akzeptabel; sie zu lockern, damit eine Verbindung läuft, tauscht ein Problem gegen ein schlimmeres. Die OpenSSH-Serverreferenz deckt die Lausch- und Zugriffskontrollen ab, wenn Ihre Android-Umsetzung dieselben Konfigurationsnamen verwendet.