Android VPN zerbitzaria: root-ek ez du telefonoa irisgarri egiten
Hiru arazo berezik erabakitzen dute telefono batek VPN bezeroak zerbitza ditzakeen: sarrerako bidea, pribilegioen eredua eta birbidalketa. Root-ek erdikoa baino ez du ukitzen.
Root-ek aldatzen du prozesu batek zein sare-eragiketa saia ditzakeen. Ez dio telefonoari helbide publikoki irisgarririk ematen, ez du operadorearengan sarrerako mapatzerik erreserbatzen, eta ez du demoniorik bizirik mantentzen berrabiarazi ondoren. Android telefono bat VPN zerbitzari gisa aritu daitekeen erabakitzen ari bazara, bereizi hiru galdera: helburuzko bezeroa entzulearengana irits daiteke, zer pribilegio-eredu behar du zerbitzariaren inplementazioak, eta zer birbidali behar da tunela altxatuta dagoenean.
Nork eta nondik iritsi behar du telefonora
Baimendutako LAN berean dagoen bezero batek eta datu mugikorretako bezero batek bi sare desberdin probatzen dituzte. Erabaki lehenengo helburuzkoa, erantzunak ez direlako lekualdatzen. Wi-Fi-n, eskatu gabeko sarrerako trafikoak normalean goiko routerrean mapatze bat eta hortik haragoko bide publiko erabilgarri bat behar ditu. Zelularrean, operadore mailako NAT-ak esan nahi du sarrerako IPv4 sarritan ez dagoela erabilgarri, telefonoak zer baimentzen duen gorabehera.
Azken puntu hori da root-ek ukitu ezin dezakeena. Telefonoaren tokiko suebakia eta operadorearen NAT sistema desberdinak dira, eta lehenengoa aldatzeak ez du bigarrenean eraginik. Interfaze helbide pribatu bat, datu mugikorren ikono bat edo entzuten ari den socket bat ez da irisgarritasunaren froga. Operadorearen bideak IPv6 globalki bideragarria eskaintzen badu, hala ere entzule eta suebakiko politika deliberatua behar duzu; helbidea izatea ez da konexioak onartzearen berdina.
| 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 |
Zerbitzatzea eta birbidaltzea bi arrakasta desberdin dira
Osatutako VPN eskuko uzkurdura batek tunela badagoela frogatzen du. Ez du frogatzen bezeroa telefonoaren atzeko LAN batera irits daitekeenik, ezta telefonoa internet irteera gisa aritu daitekeenik ere. Konfigurazio bereiziak dira, barneko helbide-planean, ibilbideetan, itzultze-portaeran eta benetan nahi duzun zereginerako birbidalketa-politika estu batean oinarrituak.
Hutsegite modua aurreikusgarria da: eskuko uzkurdura lortzen da, bezeroak konektatuta erakusten du, eta ezer ez da kargatzen. Bezeroa araztu aurretik, erabaki bi roletatik zein ari zaren eraikitzen. Telefonoaren sareko gailu baterako urruneko sarbideak eta tunel osoko internet irteerak birbidalketa arau desberdinak behar dituzte, eta bat nahi zenuenean biak emateak esposizioa zabaltzen du eskatu zenuen gaitasuna gehitu gabe.
Pribilegioen eredua aukera bat da, ez root edo ezer ez
OpenVPN demonio arrunt batek, kernel TUN gailua erabiliz, gaitasun egokiak, gailuaren nodorako sarbidea eta Androiden segurtasun politikaren lankidetza behar ditu. Root ez da SELinuxen salbuespen orokorra; pribilegiatutako prozesu bat plataformaren politikak mugatzen du oraindik. Horregatik Linux zerbitzari batean lasai dabilen bitar batek telefonoan huts egin dezake baimenei buruzko errore argirik gabe.
Erabiltzaile espazioko ate baten inplementazioak pribilegio-eredu erabat desberdina izan dezake, beraz Android-en VPN zerbitzari guztiek root behar dutela dioen baieztapen arrunta oso zabala da. Root-ek eragiketa gehiago saiatzeko gaitasuna ematen dizu, ez direla baimenduko edo emaitza irisgarria izango den bermea.
Androiden beraren VPN zerbitzuaren erregistroa beste mekanismo bat da. Aplikazioari bizitza-ziklo zehaztua duen bezero interfaze kudeatua ematen dio; ez da zerbitzari instalatzaile orokorra, eta terminaletik demonio bat abiarazteak ez dio etengabeko kudeaketarik, aplikazioko politikarik edo berreskuratze-bide propiorik ematen.
Irteera puntu bat nahi baduzu, aldatu arkitektura
Helburua telefonoaren bidezko urruneko internet irteera soila denean, eta ez lehendik dagoen OpenVPN profil batekin bateragarritasuna, gainjarritako sare bateko irteera nodo onartuak diseinu egokiagoa da. Tailscale-k Android irteera nodoaren rola dokumentatzen du, bere erregistro, baimen eta bezero hautaketarako urratsekin.
Trukea erreala da eta argi esatea merezi du: beste protokolo bat, beste konfiantza eredu bat eta kontu eta koordinazio zerbitzu horren mendekotasuna onartzen dituzu. Ez du OpenVPN bezero aldatu gabea gainjarritako sarea elkartzera eramaten, eta ez dizu OpenVPN entzulerik ematen helbide publiko batean.
Zer behar du oraindik inplementazioak
Aukeratzen duzun bidea aukeratu, oinarri operatiboek erabakitzen dute aste bat iraungo duen. Mantendu zerbitzariaren kredentzialak pribatu, eman bezero identitate desberdinak eta planifikatu baliogabetzea behar baino lehen. Erabaki nola iristen diren eguneratzeak, zerk mantentzen duen zerbitzua atzealdean martxan eta nola berreskuratzen den berrabiarazi edo sare aldaketa baten ondoren.
Saihestu eroso diruditen lasterbideak: bitar estatiko zaharkitua, gogorrean kodetutako interfaze izenak eta lehendik dagoen suebaki politika husten duen abiarazte scripta. Gero onartu emaitza proba zehatz baten aurrean soilik: baimendutako urruneko bezero bat helburuzko baliabidera iristen da, debekatutako helmugak eskuragarri gabe jarraitzen dute, eta gailua bere kabuz itzultzen da onartutako bizitza-ziklo gertaeraren ondoren. Root sarbidea emaitza horren osagai posible bat da, eta gutxitan erabakigarria.