Android VPN-bediener: worteltoegang maak nie die foon bereikbaar nie
Drie aparte probleme bepaal of 'n foon VPN-kliënte kan bedien: die inkomende pad, die voorregmodel en aanstuur. Worteltoegang raak net die middelste een.
Worteltoegang verander watter netwerkbewerkings 'n proses mag probeer. Dit gee nie aan 'n toestel 'n publiek bereikbare adres nie, reserveer nie 'n inkomende kaartering by die netwerkdraer nie, en hou nie 'n daemon aan die lewe ná 'n herbegin nie. As jy besluit of 'n Android-foon as VPN-bediener kan optree, skei drie vrae: kan die beoogde kliënt die luisteraar hoegenaamd bereik, watter voorregmodel het die bedienerimplementering nodig, en wat moet aangestuur word sodra die tonnel op is.
Wie moet die foon bereik, en van waar
'n Kliënt op dieselfde toegelate LAN en 'n kliënt op mobiele data toets twee verskillende netwerke. Beslis eers oor die beoogde een, want die antwoorde dra nie oor nie. Op Wi-Fi het onversoekte inkomende verkeer gewoonlik 'n kaartering by die opstroomroeteerder nodig en 'n bruikbare publieke pad daarvoor verby. Op sellulêr beteken carrier-grade NAT dat inkomende IPv4 dikwels onbeskikbaar is, maak nie saak wat die toestel toelaat nie.
Daardie laaste punt is die een waaraan worteltoegang nie kan raak nie. Die foon se plaaslike firewall en die draer se NAT is verskillende stelsels, en om die eerste te verander het geen effek op die tweede nie. 'n Privaat koppelvlakadres, 'n mobiele-data-ikoon of 'n luisterende sok is nie bewys van bereikbaarheid nie. As die draerpad wel wêreldwyd roteerbare IPv6 bied, het jy steeds doelbewuste luisteraar- en firewallbeleid daarvoor nodig; om 'n adres te hê is nie dieselfde as om verbindings te aanvaar nie.
| 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 |
Bediening en aanstuur is twee verskillende suksesse
'n Voltooide VPN-handdruk bewys die tonnel bestaan. Dit bewys nie dat die kliënt 'n LAN agter die foon kan bereik nie, en dit bewys nie dat die foon as 'n internet-uitgang kan optree nie. Dit is aparte konfigurasies wat gebou is op die innerlike adresplan, roetes, terugkeergedrag en 'n nou-omlynde aanstuurbeleid vir die taak wat jy werklik wil hê.
Die foutmodus is voorspelbaar: die handdruk slaag, die kliënt wys verbind, en niks laai nie. Voordat jy die kliënt ontfout, besluit watter van die twee rolle jy bou. Afgeleë toegang tot 'n toestel op die foon se netwerk en volledige-tonnel internet-uitgang het verskillende aanstuurreëls nodig, en om albei toe te staan wanneer jy een wou hê, verbreed die blootstelling sonder om die vermoë by te voeg wat jy gevra het.
Die voorregmodel is 'n keuse, nie wortel of niks nie
'n Konvensionele OpenVPN-daemon wat 'n kernel-TUN-toestel gebruik, het die ooreenstemmende vermoëns nodig, toegang tot die toestelknoop, en samewerking van Android se sekuriteitsbeleid. Worteltoegang is nie 'n algemene vrystelling van SELinux nie; 'n bevoorregte proses word steeds deur platformbeleid beperk. Dit is waarom 'n binary wat gelukkig op 'n Linux-bediener loop, op 'n foon kan misluk sonder 'n duidelike fout oor toestemmings.
'n Implementering van 'n poort in die gebruikersruimte kan 'n heeltemal ander voorregmodel hê, so die algemene bewering dat elke VPN-bediener op Android worteltoegang nodig het, is te breed. Wat worteltoegang vir jou koop, is die vermoë om meer bewerkings te probeer, nie 'n waarborg dat hulle toegelaat sal word of dat die resultaat bereikbaar is nie.
Android se eie VPN-diensregistrasie is weer 'n aparte meganisme. Dit gee 'n app 'n bestuurde kliëntkoppelvlak met 'n gedefinieerde lewensiklus; dit is nie 'n algemene bedienerinstalleerder nie, en om 'n daemon vanaf 'n terminaal te begin, gee dit nie altyd-aan-bestuur, per-app-beleid of 'n eie herstelpad nie.
As jy 'n uitgangspunt wil hê, verander die argitektuur
Wanneer die doel bloot afgeleë internet-uitgang deur die foon is, eerder as versoenbaarheid met 'n bestaande OpenVPN-profiel, is 'n ondersteunde oorleg-uitgangsknoop die beter gepaste ontwerp. Tailscale dokumenteer 'n Android-uitgangsknoppel met sy eie registrasie-, magtigings- en kliëntkeusestappe.
Die ruil is werklik en die moeite werd om duidelik te stel: jy aanvaar 'n ander protokol, 'n ander vertrouensmodel en 'n afhanklikheid van daardie rekening en koördineringsdiens. Dit maak nie dat 'n onveranderde OpenVPN-kliënt by die oorleg aansluit nie, en dit gee jou nie 'n OpenVPN-luisteraar op 'n publieke adres nie.
Wat die ontplooiing steeds nodig het
Watter roete jy ook al neem, die operasionele basiese dinge besluit of dit 'n week oorleef. Hou bedienerbewyse privaat, gee afsonderlike kliëntidentiteite uit, en beplan herroeping voordat jy dit nodig het. Besluit hoe opdaterings aankom, wat die diens in die agtergrond aan die gang hou, en hoe dit ná 'n herbegin of 'n netwerkverandering herstel.
Vermy die kortpaaie wat gerieflik lyk: 'n verouderde statiese binary, hardgekodeerde koppelvlakname, en 'n opstartskrip wat bestaande firewallbeleid uitvee. Aanvaar dan die resultaat net teen 'n konkrete toets: 'n gemagtigde afgeleë kliënt bereik die beoogde bron, verbode bestemmings bly onbeskikbaar, en die toestel kom vanself terug ná die ondersteunde lewensiklusgebeurtenis. Worteltoegang is een moontlike bestanddeel in daardie uitkoms, en selde die beslissende een.