Android-VPN-Server: Root macht das Telefon nicht erreichbar
Drei getrennte Probleme entscheiden, ob ein Telefon VPN-Clients bedienen kann: der eingehende Pfad, das Privilegienmodell und das Weiterleiten. Root berührt nur das mittlere.
Root ändert, welche Netzwerkoperationen ein Prozess versuchen darf. Es verschafft einem Handy keine öffentlich erreichbare Adresse, reserviert kein eingehendes Carrier-Mapping und hält keinen Daemon nach einem Neustart am Leben. Wenn Sie entscheiden, ob ein Android-Telefon als VPN-Server dienen kann, trennen Sie drei Fragen: Kann der vorgesehene Client den Listener überhaupt erreichen, welches Privilegienmodell braucht die Serverimplementierung, und was muss weitergeleitet werden, sobald der Tunnel steht.
Wer das Telefon erreichen muss, und von wo
Ein Client im selben erlaubten LAN und ein Client über Mobilfunk testen zwei verschiedene Netze. Klären Sie zuerst das vorgesehene, denn die Antworten übertragen sich nicht. Im WLAN braucht unaufgeforderter eingehender Verkehr meist ein Mapping am Upstream-Router und einen nutzbaren öffentlichen Pfad dahinter. Im Mobilfunk bedeutet Carrier-Grade-NAT, dass eingehendes IPv4 häufig nicht verfügbar ist, egal was das Handy erlaubt.
Genau diesen letzten Punkt kann Root nicht berühren. Die lokale Firewall des Telefons und das NAT des Netzbetreibers sind verschiedene Systeme, und das erste zu ändern hat keine Wirkung auf das zweite. Eine private Interface-Adresse, ein Mobilfunk-Symbol oder ein lauschender Socket sind kein Beleg für Erreichbarkeit. Bietet der Weg über den Betreiber dennoch global routbares IPv6, brauchen Sie dafür trotzdem eine bewusste Listener- und Firewall-Policy; eine Adresse zu haben ist nicht dasselbe wie Verbindungen anzunehmen.
| Client path | What actually decides reachability |
|---|---|
| Same LAN | The phone's listener and its local firewall |
| Wi-Fi, from the internet | A mapping on the upstream router plus a usable public path beyond it |
| Cellular IPv4 | The carrier's NAT, which the handset does not control |
| Cellular IPv6 | Address, listener and firewall policy together |
Bedienen und Weiterleiten sind zwei verschiedene Erfolge
Ein abgeschlossener VPN-Handshake beweist, dass der Tunnel existiert. Er beweist nicht, dass der Client ein LAN hinter dem Telefon erreicht, und nicht, dass das Telefon als Internet-Ausgang dienen kann. Das sind getrennte Konfigurationen, die auf dem inneren Adressplan, Routen, Rückkehrverhalten und einer eng gefassten Weiterleitungsrichtlinie für die Aufgabe aufbauen, die Sie tatsächlich wollen.
Das Fehlerbild ist vorhersehbar: der Handshake gelingt, der Client zeigt verbunden, und nichts lädt. Bevor Sie den Client debuggen, entscheiden Sie, welche der beiden Rollen Sie bauen. Fernzugriff auf ein Gerät im Netz des Telefons und Internet-Ausgang über den vollen Tunnel brauchen unterschiedliche Weiterleitungsregeln, und beide zu gewähren, wenn Sie eines wollten, vergrößert die Angriffsfläche, ohne die gewünschte Fähigkeit hinzuzufügen.
Das Privilegienmodell ist eine Wahl, nicht Root oder nichts
Ein herkömmlicher OpenVPN-Daemon mit einem Kernel-TUN-Gerät braucht die entsprechenden Capabilities, Zugriff auf den Geräteknoten und Kooperation der Android-Sicherheitsrichtlinie. Root ist keine pauschale Ausnahme von SELinux; ein privilegierter Prozess bleibt durch die Plattformrichtlinie beschränkt. Deshalb kann ein Binary, das auf einem Linux-Server problemlos läuft, auf einem Telefon ohne offensichtlichen Berechtigungsfehler scheitern.
Eine Gateway-Implementierung im Userspace kann ein ganz anderes Privilegienmodell haben, daher ist die verbreitete Behauptung, jeder VPN-Server auf Android brauche Root, zu weit gefasst. Root verschafft Ihnen die Möglichkeit, mehr Operationen zu versuchen, keine Garantie, dass sie erlaubt werden oder das Ergebnis erreichbar ist.
Androids eigene VPN-Dienstregistrierung ist wieder ein anderer Mechanismus. Sie gibt einer App eine verwaltete Client-Schnittstelle mit definiertem Lebenszyklus; sie ist kein allgemeiner Server-Installer, und einen Daemon aus einem Terminal zu starten verleiht ihm keine Dauerüberwachung, keine App-Policy und keinen eigenen Wiederherstellungspfad.
Wenn Sie einen Ausgangspunkt wollen, ändern Sie die Architektur
Wenn das Ziel einfach ein entfernter Internet-Ausgang über das Telefon ist und nicht Kompatibilität mit einem vorhandenen OpenVPN-Profil, ist ein unterstützter Overlay-Ausgangsknoten das passendere Design. Tailscale dokumentiert eine Android-Ausgangsknoten-Rolle mit eigenen Schritten für Registrierung, Autorisierung und Client-Auswahl.
Der Tausch ist real und sollte klar benannt werden: Sie akzeptieren ein anderes Protokoll, ein anderes Vertrauensmodell und eine Abhängigkeit von jenem Konto und Koordinationsdienst. Er bringt keinen unveränderten OpenVPN-Client dazu, dem Overlay beizutreten, und er gibt Ihnen keinen OpenVPN-Listener auf einer öffentlichen Adresse.
Was die Bereitstellung noch braucht
Welchen Weg Sie auch wählen, die betrieblichen Grundlagen entscheiden, ob es eine Woche übersteht. Halten Sie Server-Anmeldedaten privat, vergeben Sie unterschiedliche Client-Identitäten und planen Sie den Widerruf, bevor Sie ihn brauchen. Legen Sie fest, wie Updates ankommen, was den Dienst im Hintergrund am Laufen hält und wie er sich nach einem Neustart oder Netzwechsel erholt.
Vermeiden Sie die Abkürzungen, die bequem wirken: ein veraltetes statisches Binary, fest kodierte Interface-Namen und ein Startskript, das die bestehende Firewall-Policy leert. Nehmen Sie das Ergebnis dann nur gegen einen konkreten Test an: Ein autorisierter entfernter Client erreicht die vorgesehene Ressource, gesperrte Ziele bleiben unerreichbar, und das Gerät kommt nach dem unterstützten Lebenszyklus-Ereignis von selbst zurück. Root-Zugriff ist ein möglicher Bestandteil dieses Ergebnisses und selten der entscheidende.