Ez, VpnService aplikazio batek ezin du telefonoaren VPN-a piztu

Uste okerra da VpnService aplikazio batek sistemaren etengailu bat iraul dadila eta handik aurrera telefonoa babestuta dagoela. Benetan gertatzen dena estuagoa da: aplikazioak adostasuna eskatzen du, interfaze bat eraikitzen du, fitxategi-deskriptore baten bidez paketeak irakurri eta idazten ditu, eta uzten duenean interfazea itzultzen du. Aldiko tunel bakarra egon daiteke bizirik, eta sistemak hura galdetu gabe ken dezake. Jendeak protokoloari leporatzen dion portaera nahasgarriaren zatirik handiena jabetza-eredu horretatik dator.

Hartu bizi-zikloko trantsizio bakoitza diseinuaren parte gisa, eta ez kasu berezi gisa.

Mitoa: aplikazioak telefonoaren VPN-a pizten du

Fluxua VpnService.prepare() deiarekin hasten da, erabiltzaileak onartu behar duen Intent bat itzultzen duena, eta establish() deiarekin jarraitzen du, geroago aplikazioak kontrolatzen ez dituen arrazoiengatik huts egin dezakeena. Bigarren tunel bat ezartzeak lehen interfazea desaktibatzen du eta sistemaren jakinarazpena ordezkatzen du. Segida horretan inon ez du aplikazioak gailu osorako etengailurik; eman zitzaion deskriptorea eta haren gainera iristen diren paketeak ditu. Jakinarazpen iraunkorra ere sistemarena da, ez aplikazioaren diseinuarena.

Interfazea ematen da, ez hartzen, beraz beste bezero batek edonoiz har dezake lekua. Aplikazioak horren berri itzulera-dei baten bidez jakiten du, ez itzulera-balio baten bidez.

Aplikazioa behartuta geldiaraztea jakinarazpen-panelean ikusten da arrazoi beragatik: sistemak eman zuena jakinarazten du, ez aplikazioak erakustea aukeratu zuena.

Mitoa: adostasuna behin ematen da

Sistemak tunela beste bezero bati ematen dionean, baliogabetze-transakzio bat bidaltzen du oinarrizko klaseak onBind() deitik itzultzen duen binder-era. Binder hori berearekin ordezkatzen duen aplikazioak berak birbidali behar du baliogabetze-transakzioa; bestela VpnService.onRevoke() ez da inoiz abiarazten eta zerbitzuak jada existitzen ez den deskriptore batean idazten jarraitzen du. Erabiltzaileak ere ken dezake onespena, eta sistemak zerbitzua geldi dezake berrabiaraztean edo beti piztuta dagoen berrikonexioan.

Hori kudeatzea lan zehatza da, ez log-lerro bat: utzi deskriptorea irakurtzeari, itxi, garbitu konektatuta dagoen bandera eta esan erabiltzaileari zein egoeratan dagoen. Ondoren erabaki aplikazioak berreraiki, berriro galdetu ala itxaron behar duen, beti piztuta dagoen konfigurazioan sistemak berak zerbitzua itzul baitezake.

Baliogabetzea egoera gisa eta ez salbuespen gisa hartzen duen aplikazioak konektatuta dagoela jakinaraziko du idazten duen pakete bakoitza baztertzen den bitartean, eta hori da pribatutasun-tresna baterako hutsegite-modu okerrena.

Mitoa: interfazeak trafikoa iragazten du zuretzat

Iristen dena IP gordina da. Harrapatzeak edo iragazteak IP, TCP, UDP eta IPv6 goiburuak aztertzea esan nahi du, fluxuak jarraitzea eta erantzunak deskriptorera itzultzea, eta horrek harrapaketa-aplikazioa sareko pila txiki bat bihurtzen du, ez sistemaren instalazio bat. protect() badago aplikazioaren beraren garraio-socketak bere tunela saihestu dezan, bere burua harrapatu beharrean, eta boolear bat itzultzen du, tunela martxan jarri ondoren sortzen den socket bakoitzean egiaztatzea merezi duena.

Eraikitzailearen baimendutako eta debekatutako aplikazio-zerrendek erabakitzen dute noren trafikoa sartzen den interfazera. Ez dute sarbiderik ematen interfazeak daramatzan IP paketeetatik harago, eta inongo APIk ez du beste bezero baten tunela agerian uzten edo sistemaren VPN profilak zerrendatzen ditu. Sare-gaitasunek esan dezakete sare bat VPN garraioa dela, baina ez nori dagokion tunela.

Horregatik beste aplikazioei buruzko egoera-galderak kontraesankorrak dira: informazioa ez zaio zure prozesuari agerian uzten.

Zer eskatzen duen bizi-zikloak benetan

Jarraitu kontrolatzen dituzun egoerei: prest, ezarrita, baliogabetuta, geldituta. Berrikonexioak desmuntatzea eta gero ezartzea izan beharko luke, deskriptorearen eta garraio-socketaren jabe bakarrarekin, ezartzeko lehian dabilen bi osagai leku bakarra lortzeko borrokatuko baitira. Atzeko planoko abioak mugatuta daude Android modernoan, beraz abioko difusio bat ez da bermea; erabili aurreko planoko zerbitzua bere jakinarazpenarekin API mailak uzten duen tokian.

Erregistratu trantsizioa eta ez soilik amaierako egoera, eta eduki egoera-makina nahikoa txiki bide guztiak probatzeko. Proba batean iristen ez zaren egoera bat logik gabe zelaian aurkituko duzun egoera da.

Probatu bizi-zikloa gailu batean

Emuladoreek konektibitatea faltsutu dezakete, baina ez adostasunaren eta baliogabetzearen bidea modu sinesgarrian, beraz exekutatu horiek benetako gailu batean, lekua lapurtzeko bigarren VPN bezero bat instalatuta.

adb shell dumpsys connectivity | grep -i -A3 vpn
adb shell dumpsys activity services | grep -i -A2 vpnservice
adb logcat -s VpnService:V AndroidRuntime:E
adb shell am force-stop com.example.vpnapp

Abiarazi tunela, berretsi jakinarazpena eta interfazea, gero konektatu beste bezeroa eta begiratu baliogabetze-deia exekutatzen den eta egoera garbitzen den. Geldiarazi aplikazioa behartuta eta egiaztatu ezerk oraindik deskriptore bizirik jakinarazten duen.

Errepikatu segida beti piztuta berrabiarazi ondoren, bide hori erabiltzaileak hasitako konexioaren desberdina baita. Bilatzen duzuna ez da ikono berde bat, aplikazioak jada zuen ez zuen deskriptore bat erabiltzeari utzi ziola frogatzea baizik.