Android VPN-server: root maakt de telefoon niet bereikbaar
Drie afzonderlijke problemen bepalen of een telefoon VPN-clients kan bedienen: het inkomende pad, het rechtenmodel en het doorsturen. Root raakt alleen de middelste.
Root verandert welke netwerkbewerkingen een proces mag proberen. Het geeft de telefoon geen publiek bereikbaar adres, reserveert geen inkomende mapping bij de provider en houdt geen daemon in leven na een herstart. Als je beslist of een Android-telefoon als VPN-server kan dienen, scheid dan drie vragen: kan de bedoelde client de listener überhaupt bereiken, welk rechtenmodel heeft de serverimplementatie nodig, en wat moet er worden doorgestuurd zodra de tunnel staat.
Wie moet de telefoon bereiken, en van waar
Een client op hetzelfde toegestane LAN en een client op mobiele data testen twee verschillende netwerken. Bepaal eerst het bedoelde, want de antwoorden zijn niet uitwisselbaar. Op Wi-Fi heeft ongevraagd inkomend verkeer meestal een mapping op de upstream-router nodig en een bruikbaar openbaar pad daar voorbij. Op mobiel betekent carrier-grade NAT dat inkomende IPv4 vaak niet beschikbaar is, wat de telefoon ook toestaat.
Dat laatste punt is precies wat root niet kan aanraken. De lokale firewall van de telefoon en de NAT van de provider zijn verschillende systemen, en het eerste wijzigen heeft geen effect op het tweede. Een privé-interfaceadres, een mobieledata-pictogram of een luisterende socket zijn geen bewijs van bereikbaarheid. Biedt het pad via de provider toch wereldwijd routeerbare IPv6, dan heb je daarvoor nog steeds een bewust listener- en firewallbeleid nodig; een adres hebben is niet hetzelfde als verbindingen accepteren.
| 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 en doorsturen zijn twee verschillende successen
Een voltooide VPN-handshake bewijst dat de tunnel bestaat. Het bewijst niet dat de client een LAN achter de telefoon bereikt, en niet dat de telefoon als internetuitgang kan dienen. Dat zijn afzonderlijke configuraties, gebouwd op het interne adresplan, de routes, het retourgedrag en een nauw afgebakend doorstuurbeleid voor de taak die je werkelijk wilt.
De faalmodus is voorspelbaar: de handshake slaagt, de client toont verbonden, en er laadt niets. Bepaal voordat je de client debugt welke van de twee rollen je bouwt. Externe toegang tot een apparaat op het netwerk van de telefoon en internetuitgang via volledige tunnel vragen verschillende doorstuurstregels, en beide toestaan wanneer je er één wilde vergroot de blootstelling zonder de gevraagde mogelijkheid toe te voegen.
Het rechtenmodel is een keuze, niet root of niets
Een conventionele OpenVPN-daemon met een kernel-TUN-apparaat heeft de bijbehorende capabilities, toegang tot het apparaatknooppunt en medewerking van het beveiligingsbeleid van Android nodig. Root is geen algemene vrijstelling van SELinux; een bevoorrecht proces blijft beperkt door het platformbeleid. Daarom kan een binary die op een Linux-server probleemloos draait, op een telefoon mislukken zonder duidelijke fout over rechten.
Een gateway-implementatie in userspace kan een heel ander rechtenmodel hebben, dus de gangbare bewering dat elke VPN-server op Android root nodig heeft, is te breed. Wat root je koopt is de mogelijkheid meer bewerkingen te proberen, niet de garantie dat ze worden toegestaan of dat het resultaat bereikbaar is.
Androids eigen VPN-dienstregistratie is weer een ander mechanisme. Het geeft een app een beheerd clientinterface met een gedefinieerde levenscyclus; het is geen algemene serverinstallatie, en een daemon vanaf een terminal starten geeft die geen permanente beheersing, beleid per app of een eigen herstelpad.
Wil je een uitgangspunt, verander de architectuur
Wanneer het doel simpelweg externe internetuitgang via de telefoon is en niet compatibiliteit met een bestaand OpenVPN-profiel, dan is een ondersteund overlay-uitgangsknooppunt het beter passende ontwerp. Tailscale documenteert een Android-uitgangsknooppuntrol met eigen stappen voor registratie, autorisatie en clientkeuze.
De ruil is echt en verdient het duidelijk te worden gezegd: je accepteert een ander protocol, een ander vertrouwensmodel en een afhankelijkheid van dat account en die coördinatiedienst. Het zorgt er niet voor dat een ongewijzigde OpenVPN-client zich bij de overlay aansluit, en het geeft je geen OpenVPN-listener op een openbaar adres.
Wat de uitrol nog nodig heeft
Welke route je ook kiest, de operationele basis bepaalt of het een week overleeft. Houd serverreferenties privé, geef afzonderlijke clientidentiteiten uit en plan intrekking voordat je die nodig hebt. Bepaal hoe updates binnenkomen, wat de dienst op de achtergrond draaiende houdt en hoe hij herstelt na een herstart of een netwerkwijziging.
Vermijd de sluipwegen die handig lijken: een verouderde statische binary, hardgecodeerde interfacenamen en een opstartscript dat het bestaande firewallbeleid leegmaakt. Accepteer het resultaat daarna alleen op basis van een concrete test: een geautoriseerde externe client bereikt de bedoelde resource, verboden bestemmingen blijven onbereikbaar, en het apparaat komt na de ondersteunde levenscyclusgebeurtenis vanzelf terug. Root-toegang is een mogelijk ingrediënt in dat resultaat, en zelden het beslissende.