Portweiterleitung am Android-Hotspot: die drei Einstiegspunkte

Sie haben den Hotspot eingeschaltet, das VPN verbunden, einen Port in der App geöffnet, und das andere Gerät kann sich trotzdem nicht verbinden. Das fehlende Stück ist fast nie der Port selbst, sondern die Frage, welche Maschine den lauschenden Socket besitzt und welche Adresse das andere Gerät erreichen soll. Ich gehe vom Telefon nach außen, weil der Bildschirm vor Ihnen zeigt, welchen der drei Einstiegspunkte Sie tatsächlich testen.

Beginnen Sie dort, wo der Dienst wirklich läuft

Öffnen Sie die App, die die Verbindung annehmen soll, und lesen Sie ihre Statusseite. Steht dort, dass sie lauscht, notieren Sie die Adresse, an die sie gebunden ist, denn dieses eine Detail entscheidet die meisten Fälle unten. Eine App, die an 127.0.0.1 gebunden ist, ist nur vom Telefon aus erreichbar, und weder ein Hotspot-Client noch eine Betreiberzuordnung noch ein VPN-Ausgang ändern das.

Bestätigen Sie dann, welches Gerät den Dienst betreibt. Ist es das Telefon, gehört der Socket zu dieser App; ist es ein Laptop hinter dem Hotspot, gehören Listener und Firewall dem Laptop, und das Telefon leitet nur Pakete weiter. Das sind verschiedene Entwürfe, und ihre Vermischung ist der Grund, warum ein an einer Stelle geöffneter Port an der anderen nichts bewirkt.

In einem debuggaren Build listet adb shell Sockets über /proc/net/tcp, aber für die meisten Menschen ist der eigene Status der App die ehrliche Quelle.

Einstiegspunkt eins: ein anderes Gerät im Hotspot

Das ist der lokale Fall und der einfachste. Das andere Gerät erreicht das Telefon unter der Adresse, die es als sein Gateway sieht, auf dem Port, auf dem die App lauscht, und nichts außerhalb des Hotspots ist beteiligt. Eine Betreiberzuordnung ist nicht nötig, weil der Verkehr das lokale Segment nie verlässt.

Zwei Dinge brechen das: Die App ist an Loopback gebunden, oder die Client-Richtlinie auf dem Telefon erlaubt die lokale Verbindung nicht. Testen Sie mit dem eigenen Protokoll der Anwendung statt mit einem nackten TCP-Verbindungsaufbau, denn ein Listener, der annimmt und dann ablehnt, sieht aus der Ferne wie ein geschlossener Port aus.

Läuft der Dienst auf einem verbundenen Laptop, ist die Hotspot-Adresse des Telefons gar nicht das Ziel; Sie brauchen die Adresse des Laptops auf der Hotspot-Schnittstelle und dort einen Listener.

Einstiegspunkt zwei: der Weg über den Betreiber

Das Telefon aus dem Mobilfunknetz zu erreichen ist ein anderes Problem, und für IPv4 funktioniert es meistens schlicht nicht. Betreiber stellen Geräte hinter gemeinsame Übersetzung, und deshalb hält RFC 6598 genau dafür einen gemeinsam genutzten Adressbereich bereit. Eine unaufgeforderte eingehende Verbindung hat keine Zuordnung, durch die sie ankommen könnte, und keine lokale Konfiguration erzeugt eine, weil der Übersetzer nicht Ihr Gerät ist.

Root-Zugriff ändert das ebenfalls nicht; er gibt Kontrolle über den Stack des Telefons, nicht über den Übersetzer des Betreibers. Bietet der Betreiber ein öffentliches IPv6-Präfix, kann ein eingehender Weg existieren, aber Listener und Firewall brauchen weiterhin eine bewusste Freigabe.

Einstiegspunkt drei: der VPN-Ausgang

Die Adresse, die eine Website bei aktivem Tunnel meldet, ist die Ausgangsadresse für abgedeckten ausgehenden Verkehr. Sie ist keine Adresse, die eingehende Verbindungen in Ihrem Namen annimmt. Für die Nutzung nach innen braucht es eine Funktion, die der Anbieter wirklich anbietet, etwa einen weitergeleiteten Port, dazu einen brauchbaren Weg vom Ausgang zum Client.

Eine lokale Erlaubnisregel kann diese Zuordnung nicht erzeugen. Sie ändert, welchen Weg die Antworten der App nehmen, was zählt, wenn die App vom Tunnel ausgenommen ist: Anfrage und Antwort können in verschiedenen Netzwerkkontexten landen, und die Verbindung scheitert wie ein Firewall-Problem.

Testen Sie einen Weg von Ende zu Ende, dann benennen Sie den Besitzer

Schreiben Sie das Tupel vor dem Test auf: beabsichtigte Quelle, Zieladresse, Transport, Port und die Maschine, die den lauschenden Socket besitzt. Ist ein Element eine Vermutung, sagt Ihnen der Test nichts Nützliches.

Testen Sie dann diesen einen erlaubten Weg mit intakter Authentifizierung der App. Veröffentlichen Sie keinen breiten Listener und schalten Sie keine fremden Kontrollen ab, nur damit eine mehrdeutige Adressprüfung antwortet, denn beide Änderungen überleben den Test.

Androids Tethering-Subsystem leitet abwärts gerichteten Verkehr auf seinem eigenen Weg weiter, getrennt von der üblichen VPN-Erfassung, deshalb sagt ein funktionierender Browser auf einem verbundenen Laptop nichts über eingehenden Zugriff auf einen Dienst am Telefon. Bevor Sie sagen, dass es funktioniert:

• Der Listener liegt auf einer Adresse, die die Gegenseite erreichen kann, nicht auf Loopback.
• Die Gegenseite nutzt die Adresse genau dieses Einstiegspunkts, nicht die Ausgangsadresse einer Statusseite.
• Jede Zuordnung beim Betreiber oder Anbieter ist eine unterstützte Funktion, keine lokal ergänzte Regel.
• Anfrage und Antwort laufen durch denselben Netzkontext, und die Authentifizierung besteht weiterhin.