Android VPN-tenar: root gjer ikkje telefonen tilgjengeleg
Tre separate problem avgjer om ein telefon kan tene VPN-klientar: inngåande veg, privilegiemodell og videresending. Root rører berre den midtre.
Root endrar kva nettverksoperasjonar ein prosess får prøve. Det gir ikkje telefonen ei offentleg tilgjengeleg adresse, reserverer ikkje ei inngåande kartlegging hos operatøren og held ikkje ein daemon i live etter omstart. Viss du avgjer om ein Android-telefon kan fungere som VPN-tenar, skil tre spørsmål: kan den tiltenkte klienten i det heile nå lyttaren, kva privilegiemodell treng tenarimplementasjonen, og kva må videresendast når tunnelen er oppe.
Kven må nå telefonen, og kvarfrå
Ein klient på same tillatne LAN og ein klient på mobildata testar to ulike nettverk. Avgjer først det tiltenkte, fordi svara ikkje overførast. På Wi-Fi treng uoppfordra inngåande trafikk vanlegvis ei kartlegging på rutaren oppstraums og ein brukbar offentleg veg utanfor. På mobilnettet tyder carrier-grade NAT at inngåande IPv4 ofte er utilgjengeleg, kva telefonen enn tillèt.
Nettopp det siste punktet er det root ikkje kan røre. Den lokale brannmuren til telefonen og NAT-en til operatøren er ulike system, og å endre det første har inga verknad på det andre. Ei privat grensesnittadresse, eit mobildataikon eller ein lyttande socket er ikkje prov på tilgjenge. Viss vegen via operatøren likevel tilbyr globalt rutbar IPv6, treng du framleis ein medviten lyttar- og brannmurpolitikk for han; å ha ei adresse er ikkje det same som å ta imot tilkoplingar.
| 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 |
Tenesteyting og videresending er to ulike suksessar
Eit fullført VPN-handtrykk provar at tunnelen finst. Det provar ikkje at klienten når eit LAN bak telefonen, og ikkje at telefonen kan tene som internettutgang. Det er separate konfigurasjonar bygde på den indre adresseplanen, ruter, returatferd og ein snevert avgrensa videresendingspolitikk for oppgåva du faktisk vil ha.
Feilmodusen er føreseieleg: handtrykket lukkast, klienten viser tilkopla, og ingenting lastar. Før du feilsøkjer klienten, avgjer kva av dei to rollene du byggjer. Fjernåtkomst til ei eining på nettverket til telefonen og internettutgang via full tunnel krev ulike videresendingsreglar, og å gje begge når du ville ha éin aukar eksponeringa utan å leggje til funksjonen du bad om.
Privilegiemodellen er eit val, ikkje root eller ingenting
Ein konvensjonell OpenVPN-daemon som brukar ei kernel-TUN-eining, treng dei tilsvarande eigenskapane, tilgang til einingsnoden og samarbeid frå tryggingspolitikken til Android. Root er ikkje eit generelt unntak frå SELinux; ein privilegert prosess er framleis avgrensa av plattformpolitikken. Difor kan ein binær som køyrer fint på ein Linux-tenar feile på ein telefon utan ein tydeleg feil om løyve.
Ein gateway-implementasjon i brukarrommet kan ha ein heilt annan privilegiemodell, så den vanlege påstanden om at kvar VPN-tenar på Android treng root er for vid. Det root kjøper deg er evna til å prøve fleire operasjonar, ikkje ei garanti for at dei blir tillatne eller at resultatet er tilgjengeleg.
Androids eigen VPN-tenesteregistrering er nok ein separat mekanisme. Ho gir ein app eit styrt klientgrensesnitt med definert livssyklus; ho er ikkje ein generell tenarinstallatør, og å starte ein daemon frå ein terminal gir han ikkje alltid-på-styring, politikk per app eller eigen attopprettingsveg.
Vil du ha eit utgangspunkt, endre arkitekturen
Når målet berre er fjern internettutgang gjennom telefonen og ikkje kompatibilitet med ein eksisterande OpenVPN-profil, er ein støtta overlay-utgangsnode det betre tilpassa designet. Tailscale dokumenterer ei Android-utgangsnode-rolle med eigne steg for registrering, autorisasjon og klientval.
Bytet er reelt og verd å seie rett ut: du godtar ein annan protokoll, ein annan tillitsmodell og ei avhengnad av den kontoen og koordineringstenesta. Det får ikkje ein uendra OpenVPN-klient til å bli med i overlayet, og det gir deg ikkje ein OpenVPN-lyttar på ei offentleg adresse.
Kva utrullinga framleis treng
Kva veg du enn vel, avgjer det operative grunnlaget om det overlever ei veke. Hald tenarpåloggingsinformasjon privat, utferd ulike klientidentitetar og planlegg tilbakekalling før du treng det. Avgjer korleis oppdateringar kjem, kva som held tenesta i gang i bakgrunnen, og korleis ho kjem seg etter ein omstart eller ei nettverksendring.
Unngå snarvegane som ser bekveme ut: ein utdatert statisk binær, hardkoda grensesnittnamn og eit oppstartsskript som tømmer den eksisterande brannmurpolitikken. Godta deretter resultatet berre mot ein konkret test: ein autorisert fjernklient når den tiltenkte ressursen, forbodne destinasjonar blir verande utilgjengelege, og eininga kjem tilbake av seg sjølv etter den støtta livssyklushendinga. Root-tilgang er ein mogleg ingrediens i det resultatet, og sjeldan den avgjerande.