VPN-server på Android: root gjør ikke telefonen tilgjengelig
Tre atskilte problemer avgjør hvorvidt en telefon kan betjene VPN-klienter: innkommende rute, privilegiemodell og videresending. Root berører bare det midterste.
Root forandrer hvilke nettverksoperasjoner en prosess har lov til å forsøke. Det skaffer ikke telefonen en offentlig tilgjengelig adresse, reserverer ikke en innkommende mapping hos operatøren, og holder ikke en daemon levende etter en omstart. Dersom du vurderer om en Android-telefon kan opptre som VPN-server, må du holde tre spørsmål fra hverandre: kommer den tiltenkte klienten i det hele tatt frem til lytteren, hva slags privilegiemodell krever serverimplementasjonen, og hva må videresendes når tunnelen først er oppe.
Hvem som må nå telefonen, og fra hvilket nett
En klient på det samme tillatte LAN-et og en klient på mobildata befinner seg i to forskjellige nettverk. Bestem deg først for hvilket som er ment, fordi svarene ikke kan overføres. På Wi-Fi krever uanmodet innkommende trafikk som regel en mapping i ruteren ovenfor og en brukbar offentlig rute på utsiden. På mobilnettet innebærer carrier-grade NAT at innkommende IPv4 ofte ikke er tilgjengelig, uansett hva telefonen tillater.
Det er nettopp dette siste punktet root ikke kan påvirke. Telefonens lokale brannmur og operatørens NAT er forskjellige systemer, og en endring i det første har ingen betydning for det andre. En privat grensesnittadresse, et mobildata-ikon eller en socket som lytter er ikke bevis for tilgjengelighet. Selv om operatørens rute tilbyr globalt rutbar IPv6, trengs det fortsatt en bevisst lytter- og brannmurpolicy for den; å ha en adresse er ikke det samme som å motta 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 former for suksess
Et fullført VPN-håndtrykk beviser at tunnelen eksisterer. Det beviser ikke at klienten kommer frem til et LAN bak telefonen, og heller ikke at telefonen kan brukes som internettutgang. Dette er separate oppsett som bygger på den interne adresseplanen, rutene, oppførselen ved retur og en smalt avgrenset videresendingspolicy for den oppgaven du faktisk ønsker.
Feilmønsteret er forutsigbart: håndtrykket lykkes, klienten viser seg som tilkoblet, og ingenting lastes. Før du begynner å feilsøke klienten, må du bestemme hvilken av de to rollene du bygger. Fjernadgang til en enhet på telefonens nett og internettutgang gjennom full tunnel krever ulike videresendingsregler, og å tillate begge når du ønsket ett øker eksponeringen uten å gi den egenskapen du spurte etter.
Privilegiemodellen er et valg, ikke alt eller ingenting med root
En vanlig OpenVPN-daemon som benytter en kernel-TUN-enhet, krever de relevante egenskapene, tilgang til enhetsnoden og medvirkning fra Androids sikkerhetspolicy. Root er ikke noen generell dispensasjon fra SELinux; en privilegert prosess er fortsatt bundet av plattformens policy. Det er derfor en binær som går problemfritt på en Linux-server kan feile på en telefon, uten noen tydelig feilmelding om tillatelser.
En gateway-implementasjon som kjører i brukerrommet kan ha en helt annen privilegiemodell, så den utbredte påstanden om at alle VPN-servere på Android trenger root er for grov. Det root gir deg, er muligheten til å forsøke flere operasjoner, ikke en garanti for at de blir tillatt eller at resultatet blir tilgjengelig.
Androids egen registrering av VPN-tjenester er nok en annen mekanisme. Den gir en app et administrert klientgrensesnitt med en definert livssyklus; den er ikke noen generell serverinstallasjon, og å starte en daemon fra en terminal gir den verken styring hele tiden, policy per app eller egen gjenopprettingsvei.
Ønsker du et utgangspunkt, må arkitekturen endres
Når målet bare er fjern internettutgang gjennom telefonen, og ikke kompatibilitet med en eksisterende OpenVPN-profil, passer en støttet utgangsnode i et overlay-nettverk bedre. Tailscale har dokumentasjon på en utgangsnode-rolle for Android, med egne trinn for registrering, autorisasjon og valg av klient.
Avveiningen er reell og bør sies rett ut: du godtar en annen protokoll, en annen tillitsmodell og en avhengighet til den kontoen og koordineringstjenesten. Det gjør ikke at en uendret OpenVPN-klient blir med i overlayet, og det gir deg ikke en OpenVPN-lytter på en offentlig adresse.
Hva utrullingen fortsatt krever
Uansett hvilken vei du velger, er det den operasjonelle grunnmuren som avgjør om løsningen står i en uke. Hold påloggingsinformasjonen til serveren privat, utsted forskjellige klientidentiteter, og planlegg tilbakekalling før behovet oppstår. Bestem hvordan oppdateringer kommer inn, hva som holder tjenesten gående i bakgrunnen, og hvordan den gjenopprettes etter omstart eller nettverksbytte.
Unngå snarveiene som virker bekvemme: en foreldet statisk binær, hardkodede grensesnittnavn og et oppstartsskript som sletter gjeldende brannmurpolicy. Deretter bør resultatet bare godtas mot en konkret test: en autorisert fjernklient når den tiltenkte ressursen, forbudte mål forblir utilgjengelige, og enheten kommer tilbake av seg selv etter den støttede livssyklushendelsen. Root-tilgang er én mulig bestanddel i et slikt resultat, og sjelden den avgjørende.