Android VPN-server: root gör inte telefonen nåbar
Tre separata problem avgör om en telefon kan betjäna VPN-klienter: den ingående vägen, privilegiemodellen och vidarebefordran. Root berör bara det mellersta.
Root ändrar vilka nätverksoperationer en process får försöka. Det ger inte telefonen en offentligt nåbar adress, reserverar ingen ingående mappning hos operatören och håller ingen daemon vid liv efter en omstart. Om du avgör om en Android-telefon kan fungera som VPN-server, skilj på tre frågor: kan den avsedda klienten överhuvudtaget nå lyssnaren, vilken privilegiemodell behöver serverimplementeringen, och vad måste vidarebefordras när tunneln är uppe.
Vem måste nå telefonen, och varifrån
En klient på samma tillåtna LAN och en klient på mobildata testar två olika nätverk. Avgör först det avsedda, eftersom svaren inte överförs. På Wi-Fi behöver obeställd ingående trafik vanligtvis en mappning i uppströmsroutern och en användbar offentlig väg bortom den. På mobilnätet innebär carrier-grade NAT att ingående IPv4 ofta inte är tillgängligt, oavsett vad telefonen tillåter.
Just den sista punkten är det root inte kan röra. Telefonens lokala brandvägg och operatörens NAT är olika system, och att ändra det första har ingen effekt på det andra. En privat gränssnittsadress, en mobildataikon eller en lyssnande socket är inget bevis på nåbarhet. Om operatörens väg ändå erbjuder globalt routbar IPv6 behöver du fortfarande en medveten lyssnar- och brandväggspolicy för den; att ha en adress är inte samma sak som att ta emot anslutningar.
| 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 |
Betjäning och vidarebefordran är två olika framgångar
Ett slutfört VPN-handskakning bevisar att tunneln finns. Det bevisar inte att klienten når ett LAN bakom telefonen, och inte att telefonen kan tjäna som internetutgång. Det är separata konfigurationer byggda på den inre adressplanen, rutterna, returbeteendet och en snävt avgränsad vidarebefordringspolicy för den uppgift du faktiskt vill ha.
Felläget är förutsägbart: handskakningen lyckas, klienten visar ansluten, och ingenting laddas. Innan du felsöker klienten, avgör vilken av de två rollerna du bygger. Fjärråtkomst till en enhet på telefonens nätverk och internetutgång via full tunnel kräver olika vidarebefordringsregler, och att ge båda när du ville ha en ökar exponeringen utan att lägga till den funktion du bad om.
Privilegiemodellen är ett val, inte root eller ingenting
En konventionell OpenVPN-daemon som använder en kernel-TUN-enhet behöver motsvarande kapabiliteter, åtkomst till enhetsnoden och samverkan från Androids säkerhetspolicy. Root är inte ett generellt undantag från SELinux; en privilegierad process är fortfarande begränsad av plattformspolicyn. Därför kan en binär som körs fint på en Linux-server misslyckas på en telefon utan ett tydligt fel om behörigheter.
En gateway-implementering i användarutrymmet kan ha en helt annan privilegiemodell, så det vanliga påståendet att varje VPN-server på Android behöver root är för brett. Det root köper dig är förmågan att försöka fler operationer, inte en garanti för att de tillåts eller att resultatet är nåbart.
Androids egen registrering av VPN-tjänster är ännu en separat mekanism. Den ger en app ett hanterat klientgränssnitt med en definierad livscykel; den är ingen allmän serverinstallatör, och att starta en daemon från en terminal ger den ingen ständig hantering, policy per app eller egen återställningsväg.
Vill du ha en utgångspunkt, ändra arkitekturen
När målet bara är fjärrutgång till internet via telefonen och inte kompatibilitet med en befintlig OpenVPN-profil, är en stödd overlay-utgångsnod den bättre passande designen. Tailscale dokumenterar en Android-utgångsnodsroll med egna steg för registrering, auktorisering och klientval.
Byttet är verkligt och värt att säga rakt ut: du accepterar ett annat protokoll, en annan förtroendemodell och ett beroende av det kontot och den koordineringstjänsten. Det får inte en oförändrad OpenVPN-klient att ansluta till overlayet, och det ger dig ingen OpenVPN-lyssnare på en offentlig adress.
Vad driftsättningen fortfarande behöver
Vilken väg du än väljer avgör det operativa grundarbetet om det håller en vecka. Håll serverns inloggningsuppgifter privata, utfärda olika klientidentiteter och planera återkallelse innan du behöver den. Bestäm hur uppdateringar kommer in, vad som håller tjänsten igång i bakgrunden och hur den återhämtar sig efter en omstart eller nätverksändring.
Undvik genvägarna som verkar bekväma: en föråldrad statisk binär, hårdkodade gränssnittsnamn och ett startskript som tömmer den befintliga brandväggspolicyn. Acceptera sedan resultatet bara mot ett konkret test: en auktoriserad fjärrklient når den avsedda resursen, förbjudna destinationer förblir otillgängliga och enheten kommer tillbaka av sig själv efter den stödda livscykelhändelsen. Root-åtkomst är en möjlig ingrediens i det resultatet, och sällan den avgörande.