Android VPN serveris: root nepadaro telefono pasiekiamo
Trys atskiros problemos lemia, ar telefonas gali aptarnauti VPN klientus: įeinantis kelias, privilegijų modelis ir persiuntimas. Root paliečia tik vidurinę.
Root keičia, kokias tinklo operacijas procesas gali bandyti. Jis nesuteikia telefonui viešai pasiekiamo adreso, nerezervuoja įeinančio susiejimo pas operatorių ir nepalaiko demono gyvo po perkrovimo. Jei sprendžiate, ar Android telefonas gali veikti kaip VPN serveris, atskirkite tris klausimus: ar numatytas klientas apskritai pasiekia klausytoją, kokio privilegijų modelio reikia serverio įgyvendinimui ir ką reikia persiųsti, kai tunelis jau pakeltas.
Kas ir iš kur turi pasiekti telefoną
Klientas tame pačiame leistame LAN ir klientas mobiliaisiais duomenimis tikrina du skirtingus tinklus. Pirmiausia nuspręskite dėl numatytojo, nes atsakymai nepersikelia. Wi-Fi atveju neprašomas įeinantis srautas paprastai reikalauja susiejimo aukštesniame maršrutizatoriuje ir už jo esančio naudotino viešo kelio. Mobiliajame tinkle operatoriaus lygio NAT reiškia, kad įeinantis IPv4 dažnai nepasiekiamas, kad ir ką leistų telefonas.
Būtent šio paskutinio punkto root negali paliesti. Telefono vietinė ugniasienė ir operatoriaus NAT yra skirtingos sistemos, o pirmosios pakeitimas neturi įtakos antrajai. Privatus sąsajos adresas, mobiliųjų duomenų piktograma ar klausantis lizdas nėra pasiekiamumo įrodymas. Jei operatoriaus kelias vis dėlto siūlo globaliai maršrutuojamą IPv6, jam vis tiek reikia sąmoningos klausytojo ir ugniasienės politikos; turėti adresą nėra tas pats, kas priimti ryšius.
| 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 |
Aptarnavimas ir persiuntimas yra dvi skirtingos sėkmės
Užbaigtas VPN rankos paspaudimas įrodo, kad tunelis egzistuoja. Jis neįrodo, kad klientas pasieks LAN už telefono, ir neįrodo, kad telefonas gali būti interneto išėjimas. Tai atskiros konfigūracijos, pastatytos ant vidinio adresų plano, maršrutų, grįžimo elgsenos ir siauros persiuntimo politikos tai užduočiai, kurios iš tikrųjų norite.
Gedimo būdas nuspėjamas: rankos paspaudimas pavyksta, klientas rodo prisijungusį, ir nieko neįkeliama. Prieš derindami klientą nuspręskite, kurį iš dviejų vaidmenų statote. Nuotolinė prieiga prie įrenginio telefono tinkle ir interneto išėjimas visu tuneliu reikalauja skirtingų persiuntimo taisyklių, o abiejų suteikimas, kai norėjote vieno, padidina paveikumą nepridėdamas prašytos galimybės.
Privilegijų modelis yra pasirinkimas, o ne root arba nieko
Įprastas OpenVPN demonas, naudojantis branduolio TUN įrenginį, reikalauja atitinkamų galimybių, prieigos prie įrenginio mazgo ir Android saugumo politikos bendradarbiavimo. Root nėra visuotinė SELinux išimtis; privilegijuotas procesas vis tiek ribojamas platformos politikos. Štai kodėl binariai failas, kuris sklandžiai veikia Linux serveryje, telefone gali nepavykti be aiškios klaidos apie leidimus.
Naudotojo erdvėje veikiančio tarpinės serverio įgyvendinimas gali turėti visiškai kitokį privilegijų modelį, todėl paplitęs teiginys, kad kiekvienam Android VPN serveriui reikia root, yra per platus. Root nusiperka galimybę bandyti daugiau operacijų, o ne garantiją, kad jos bus leistos arba kad rezultatas bus pasiekiamas.
Paties Android VPN paslaugos registracija yra dar kitas mechanizmas. Ji suteikia programai valdomą kliento sąsają su apibrėžtu gyvavimo ciklu; tai nėra universalus serverio diegėjas, o demono paleidimas iš terminalo nesuteikia jam nuolatinio valdymo, politikos pagal programą ar savo atkūrimo kelio.
Jei norite išėjimo taško, pakeiskite architektūrą
Kai tikslas yra tiesiog nuotolinis interneto išėjimas per telefoną, o ne suderinamumas su esamu OpenVPN profiliu, geriau tinka palaikomas išėjimo mazgas perdangos tinkle. Tailscale dokumentuoja Android išėjimo mazgo vaidmenį su savo registracijos, autorizacijos ir kliento pasirinkimo žingsniais.
Mainai yra realūs ir verta tai pasakyti tiesiai: jūs priimate kitą protokolą, kitą pasitikėjimo modelį ir priklausomybę nuo tos paskyros bei koordinavimo paslaugos. Tai nepriverčia nepakeisto OpenVPN kliento prisijungti prie perdangos tinklo ir neduoda jums OpenVPN klausytojo viešame adrese.
Ko diegimui dar reikia
Kad ir kokį kelią pasirinktumėte, operaciniai pagrindai lemia, ar tai atlaikys savaitę. Laikykite serverio prisijungimo duomenis privačius, išduokite skirtingus klientų tapatumus ir planuokite atšaukimą prieš jam prireikus. Nuspręskite, kaip ateina atnaujinimai, kas palaiko paslaugą fone ir kaip ji atsistato po perkrovimo ar tinklo pasikeitimo.
Venkite patogiai atrodančių trumpinių: pasenusio statinio binario failo, kietai užkoduotų sąsajų pavadinimų ir paleidimo scenarijaus, kuris išvalo esamą ugniasienės politiką. Tada priimkite rezultatą tik pagal konkretų testą: įgaliotas nuotolinis klientas pasiekia numatytą išteklių, uždrausti tikslai lieka neprieinami, o įrenginys pats grįžta po palaikomo gyvavimo ciklo įvykio. Root prieiga yra vienas galimas to rezultato ingredientas ir retai lemiantis.