Android VPN-server: root gør ikke telefonen tilgængelig
Tre separate problemer afgør, om en telefon kan betjene VPN-klienter: indgående vej, privilegiemodel og videresendelse. Root rører kun det midterste.
Root ændrer, hvilke netværksoperationer en proces må forsøge. Det giver ikke telefonen en offentligt tilgængelig adresse, reserverer ikke en indgående mapping hos operatøren og holder ikke en daemon i live efter en genstart. Hvis du afgør, om en Android-telefon kan fungere som VPN-server, skal du skille tre spørgsmål ad: kan den tilsigtede klient overhovedet nå lytteren, hvilken privilegiemodel har serverimplementeringen brug for, og hvad skal videresendes, når tunnelen er oppe.
Hvem skal nå telefonen, og hvorfra
En klient på samme tilladte LAN og en klient på mobildata tester to forskellige netværk. Afgør først det tilsigtede, fordi svarene ikke overføres. På Wi-Fi kræver uopfordret indgående trafik normalt en mapping på den opstrøms router og en brugbar offentlig vej ud over den. På mobilnettet betyder carrier-grade NAT, at indgående IPv4 ofte er utilgængelig, uanset hvad telefonen tillader.
Netop det sidste punkt kan root ikke røre. Telefonens lokale firewall og operatørens NAT er forskellige systemer, og ændring af det første har ingen virkning på det andet. En privat interfaceadresse, et mobildataikon eller en lyttende socket er ikke bevis på tilgængelighed. Hvis operatørens vej alligevel tilbyder globalt rutbar IPv6, har du stadig brug for en bevidst lytter- og firewallpolitik for den; at have en adresse er ikke det samme som at acceptere forbindelser.
| 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 |
Betjening og videresendelse er to forskellige succeser
Et fuldført VPN-håndtryk beviser, at tunnelen findes. Det beviser ikke, at klienten kan nå et LAN bag telefonen, og det beviser ikke, at telefonen kan fungere som internetudgang. Det er separate konfigurationer bygget på den indre adresseplan, ruter, returadfærd og en snævert afgrænset videresendelsespolitik for den opgave, du faktisk vil have.
Fejlmåden er forudsigelig: håndtrykket lykkes, klienten viser forbundet, og intet indlæses. Før du fejlfinder klienten, skal du afgøre, hvilken af de to roller du bygger. Fjernadgang til en enhed på telefonens netværk og internetudgang via fuld tunnel kræver forskellige videresendelsesregler, og at give begge, når du ville have én, øger eksponeringen uden at tilføje den funktion, du bad om.
Privilegiemodellen er et valg, ikke root eller ingenting
En konventionel OpenVPN-daemon, der bruger en kernel-TUN-enhed, har brug for de tilsvarende capabilities, adgang til enhedsnoden og samarbejde fra Androids sikkerhedspolitik. Root er ikke en blanket undtagelse fra SELinux; en privilegeret proces er stadig begrænset af platforms politik. Derfor kan en binær, der kører fint på en Linux-server, fejle på en telefon uden en tydelig fejl om tilladelser.
En gateway-implementering i userspace kan have en helt anden privilegiemodel, så den udbredte påstand, at enhver VPN-server på Android kræver root, er for bred. Det, root køber dig, er evnen til at forsøge flere operationer, ikke en garanti for, at de tillades, eller at resultatet er tilgængeligt.
Androids egen VPN-tjenesteregistrering er endnu en separat mekanisme. Den giver en app et administreret klientinterface med en defineret livscyklus; den er ikke en generel serverinstallatør, og at starte en daemon fra en terminal giver den ikke altid-til-administration, politik pr. app eller en egen gendannelsesvej.
Hvis du vil have et udgangspunkt, skal du ændre arkitekturen
Når målet simpelthen er fjern internetudgang gennem telefonen frem for kompatibilitet med en eksisterende OpenVPN-profil, er en understøttet overlay-udgangsnode det bedre matchede design. Tailscale dokumenterer en Android-udgangsnoderolle med sine egne trin til registrering, autorisation og klientvalg.
Byttet er reelt og værd at sige klart: du accepterer en anden protokol, en anden tillidsmodel og en afhængighed af den konto og koordineringstjeneste. Det får ikke en uændret OpenVPN-klient til at slutte sig til overlayet, og det giver dig ikke en OpenVPN-lytter på en offentlig adresse.
Hvad udrulningen stadig har brug for
Uanset hvilken vej du vælger, afgør det operationelle grundlag, om det overlever en uge. Hold serverlegitimationsoplysninger private, udsted forskellige klientidentiteter, og planlæg tilbagekaldelse, før du får brug for det. Afgør, hvordan opdateringer ankommer, hvad der holder tjenesten kørende i baggrunden, og hvordan den kommer sig efter en genstart eller en netværksændring.
Undgå de genveje, der ser bekvemme ud: en forældet statisk binær, hårdkodede interfacenavne og et opstartsscript, der rydder den eksisterende firewallpolitik. Accepter derefter kun resultatet mod en konkret test: en autoriseret fjernklient når den tilsigtede ressource, forbudte destinationer forbliver utilgængelige, og enheden kommer tilbage af sig selv efter den understøttede livscyklushændelse. Root-adgang er en mulig ingrediens i det resultat og sjældent den afgørende.