Android VPN-server: root gjør ikke telefonen tilgjengelig
Tre separate problemer avgjør om en telefon kan betjene VPN-klienter: inngående vei, privilegiemodell og videresending. Root berører bare det midterste.
Root endrer hvilke nettverksoperasjoner en prosess får forsøke. Det gir ikke telefonen en offentlig tilgjengelig adresse, reserverer ikke en inngående mapping hos operatøren og holder ikke en daemon i live etter omstart. Hvis du avgjør om en Android-telefon kan fungere som VPN-server, skill tre spørsmål: kan den tiltenkte klienten i det hele tatt nå lytteren, hvilken privilegiemodell trenger serverimplementasjonen, og hva må videresendes når tunnelen er oppe.
Hvem må nå telefonen, og hvorfra
En klient på samme tillatte LAN og en klient på mobildata tester to forskjellige nettverk. Avgjør først det tiltenkte, fordi svarene ikke overføres. På Wi-Fi trenger uoppfordret inngående trafikk vanligvis en mapping på ruteren oppstrøms og en brukbar offentlig vei utenfor. På mobilnettet betyr carrier-grade NAT at inngående IPv4 ofte er utilgjengelig, uansett hva telefonen tillater.
Nettopp det siste punktet er det root ikke kan røre. Telefonens lokale brannmur og operatørens NAT er forskjellige systemer, og å endre det første har ingen virkning på det andre. En privat grensesnittadresse, et mobildataikon eller en lyttende socket er ikke bevis på tilgjengelighet. Hvis operatørens vei likevel tilbyr globalt rutbar IPv6, trenger du fortsatt en bevisst lytter- og brannmurpolitikk for den; å ha en adresse er ikke det samme som å ta imot tilkoblinger.
| 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 videresending er to forskjellige suksesser
En fullført VPN-håndtrykk beviser at tunnelen finnes. Det beviser ikke at klienten når et LAN bak telefonen, og ikke at telefonen kan tjene som internettutgang. Det er separate konfigurasjoner bygget på den indre adresseplanen, ruter, returatferd og en snevert avgrenset videresendingspolitikk for oppgaven du faktisk vil ha.
Feilmodusen er forutsigbar: håndtrykket lykkes, klienten viser tilkoblet, og ingenting lastes. Før du feilsøker klienten, avgjør hvilken av de to rollene du bygger. Fjernadgang til en enhet på telefonens nettverk og internettutgang via full tunnel krever forskjellige videresendingsregler, og å gi begge når du ville ha én øker eksponeringen uten å legge til funksjonen du ba om.
Privilegiemodellen er et valg, ikke root eller ingenting
En konvensjonell OpenVPN-daemon som bruker en kernel-TUN-enhet, trenger de tilsvarende egenskapene, tilgang til enhetsnoden og samarbeid fra Androids sikkerhetspolicy. Root er ikke en generell fritakelse fra SELinux; en privilegert prosess er fortsatt begrenset av plattformpolicyn. Derfor kan en binær som kjører fint på en Linux-server feile på en telefon uten en tydelig feil om tillatelser.
En gateway-implementasjon i brukerrommet kan ha en helt annen privilegiemodell, så den vanlige påstanden om at enhver VPN-server på Android trenger root er for vid. Det root kjøper deg er evnen til å forsøke flere operasjoner, ikke en garanti for at de tillates eller at resultatet er tilgjengelig.
Androids egen VPN-tjenesteregistrering er nok en separat mekanisme. Den gir en app et administrert klientgrensesnitt med definert livssyklus; den er ikke en generell serverinstallatør, og å starte en daemon fra en terminal gir den ikke alltid-på-administrasjon, policy per app eller en egen gjenopprettingsvei.
Vil du ha et utgangspunkt, endre arkitekturen
Når målet bare er fjern internettutgang gjennom telefonen og ikke kompatibilitet med en eksisterende OpenVPN-profil, er en støttet overlay-utgangsnode det bedre tilpassede designet. Tailscale dokumenterer en Android-utgangsnode-rolle med egne trinn for registrering, autorisasjon og klientvalg.
Byttet er reelt og verdt å si rett ut: du godtar en annen protokoll, en annen tillitsmodell og en avhengighet av den kontoen og koordineringstjenesten. Det får ikke en uendret OpenVPN-klient til å bli med i overlayet, og det gir deg ikke en OpenVPN-lytter på en offentlig adresse.
Hva utrullingen fortsatt trenger
Uansett hvilken vei du velger, avgjør det operasjonelle grunnlaget om det overlever en uke. Hold serverpåloggingsinformasjon privat, utsted forskjellige klientidentiteter og planlegg tilbakekalling før du trenger det. Avgjør hvordan oppdateringer kommer, hva som holder tjenesten i gang i bakgrunnen, og hvordan den kommer seg etter en omstart eller en nettverksendring.
Unngå snarveiene som ser bekvemme ut: en utdatert statisk binær, hardkodede grensesnittnavn og et oppstartsskript som tømmer den eksisterende brannmurpolitikken. Godta deretter resultatet bare mot en konkret test: en autorisert fjernklient når den tiltenkte ressursen, forbudte destinasjoner forblir utilgjengelige, og enheten kommer tilbake av seg selv etter den støttede livssyklushendelsen. Root-tilgang er en mulig ingrediens i det resultatet, og sjelden den avgjørende.