Android VPN root gabe: nori dagozkio baimena, ibilbideak eta blokeoa
Baimena, TUN interfazea eta sistemaren blokeo-politika hiru baimen desberdin dira. Egiaztatu zein osagairi dagokion bakoitza Android VPN aplikazio bat berrikusi aurretik.
Root ez da Android VPN aplikazio batek trafikoa eraman, ihesak blokeatu edo berrabiarazteari eutsi ahal izateko duen gauza. Jendeak hori guztia «aplikazioak VPN baimena du» gisa laburbiltzen du, eta horrek hiru mekanismo desberdin ezkutatzen ditu: erabiltzaileak emandako baimena, sistemak ezarritako pakete-interfazea eta aplikazioak zehazteko ez den plataformaren blokeo-politika. Android VPN diseinu bat berrikustea hiruretako zeinetan oinarritzen den galdetzea da, bakoitzak jabe eta huts-eredu desberdinak dituelako.
Baimena sistemaren jarduera baten bidez iristen da
VpnService.prepare() ez du ezer ematen. Intent bat itzultzen dio sistemaren baimen-jarduerari baimena falta denean, eta aplikazioak elkarrizketa hori abiatzen du erabiltzaileak zerbitzua onar dezan. Aplikazioaren prozesu propioa abiarazteak, manifestuan baimen bat gehitzeak edo «VPN gaitu» pantaila pertsonalizatu bat erakusteak ez du baimena sortzen.
Baimenak esparrua ere badu. Erabiltzaile-profil bateko pakete bati dagokio, beraz kopia pertsonala eta lan-kopia erabaki bereiziak dira, eta gailuaren jabeak profil kudeatu bat pertsonal bat ez bezala prestatzen ahal du. Elkarrizketa inoiz agertzen ez bada eta prepare() null itzultzen badu, baimena jadanik existitzen da pakete horretarako profil horretan; hori ez da aplikazioa fidagarria den froga, baimena badagoela baizik.
Interfazea sistemak betetzen duen eskaera da
Baimenaren ondoren, aplikazioak zer nahi duen deskribatzen du VpnService.Builder erabiliz: helbideak, ibilbideak, DNS zerbitzariak, MTU eta, onartua dagoen lekuan, sartu edo baztertuko diren aplikazioak. establish() sistemari tunel-interfazea sortzeko eta bat datorren trafikoa hara bideratzeko eskatzen dio. Sistemari dagokio bideratze-erabakia; aplikazioak fitxategi-deskriptorea jasotzen du eta gero zerbait erabilgarria egin behar du paketeekin.
| What you observe | Who actually owns it |
|---|---|
| VPN consent dialog | The system, triggered by prepare() |
| Routes, DNS and app lists | The app requests them; the system applies them |
| One active VPN per profile | The platform; a new service replaces the old one |
| Always-on and block-without-VPN | Device policy enforced by the platform |
Taula hori arkitektura da leku bakarrean. Aplikazioak paketeen kudeaketan parte hartzen du; ez ditu interfazea, bideratze-taula edo exekuta daitezkeen zerbitzuen kopurua bere.
Tunelaren socketak bere tunel propiotik ihes egin behar du
Trafiko zifratua daraman konexioa bera socket bat da. Aplikazioak une horretan sortu duen interfazera bideratzen bada, tunela tunelaren mende geratzen da eta gelditu egiten da. VpnService.protect() socket hori azpiko sarera lotzen du harrapaketa saihesteko, eta horregatik bezero zuzen batek bere kanpoko socket-a babesten du lehen eskuko-ukituaren aurretik.
adb shell dumpsys connectivity | grep -i -A5 vpn
adb shell settings get global always_on_vpn_app
adb shell settings get global always_on_vpn_lockdownKomando hauek instalatutako VPN sarea, beti piztuta paketea eta blokeoa ezarrita dagoen erakusten dute. Irakurketa hutseko behaketak dira: balioek diseinuak dioenarekin bat ez badatoz, baieztapena aplikazioaren interfazeaz da, ez sistemaren egoeraz.
Blokeoa plataformarena izan daiteke
Androidek VPN-a erabiltzen ez duten konexioak blokeatzen dituen politika dokumentatzen du. Betebehar hori plataformaren kontratua da, ez aplikazioa konexioak begiztan errepikatzen dituena. Etengailua gailuaren VPN ezarpenetan dago VPN gabe konexioak blokeatu gisa, eta kudeatutako gailu batean jabeak profil osoarentzat piztu dezake. Bereizketa garrantzitsua da marketin-baieztapen bat ebaluatzean: bezeroak giltza-ikonoa erakutsi eta oldarkorki berriz konekta daiteke trafiko zuzena oraindik posible den bitartean, edo estalitako aplikazioak lineaz kanpo geratu daitezke sistemak blokeoa betearazten duelako.
Giltza-ikonoa aplikazioak marrazten du, beraz aplikazioak konektatuta dagoela uste duela baizik ez du frogatzen. Beste aplikazio batek sareko sarbidea galtzen duen plataformak erabakitzen du, beraz kontrol erabilgarria tunela aktibo dagoen bitartean aplikazio hori huts egiten ikustea da.
Aplikazio-dendako «beti piztuta» etiketak ere ez du kontratu hori ordezkatzen. Beti piztuta eta blokeoa gailuaren ezarpenak dira, sarritan gailuaren jabeak aplikatuak, eta baztertutako aplikazioetarako haien portaera plataformak zehazten du. Irakurri ezarpena, ez ikurra.
Lau galdera diseinu-berrikuspen baterako
Lehenik, nork eman zuen baimena: zein paketek, zein profilek, eta erabiltzailea ala kudeatutako gailuaren politika izan zen? Bigarrenik, zer eskatu zuen aplikazioak: zein ibilbide, zein helbide-familia, zein aplikazio sartu edo baztertu? Hirugarrenik, zer gertatzen da tunela eskuragarri ez dagoenean: sistemak blokeatzen du, ala trafikoak azpiko sarera egiten du atzera? Laugarrenik, zer egiten du aplikazioak jasotzen dituen paketeekin?
Laugarren galdera da baimen-ereduak erantzun ezin duena. Baimenak eta TUN interfazeak frogatzen dute aplikazioak trafikoa jaso dezakeela, ez duela zifratzen, parekidea autentifikatzen edo garbi berreskuratzen denik. Inplementazio-ezaugarriak dira, eta han ematen du denbora berrikuspen zintzo batek.
Beharrezkoa ez den root eskaera ez da legitimo bihurtzen emaitzari kill switch deitzean, eta baimen-elkarrizketa ez da segurtasun-auditoria bat. Eduki hiru baimenak bereizita eta baieztapen bakoitza egiaztagarri bihurtzen da.