Zergatik zure Android VpnService tunelak uzten duen trafikoa bideratzen

Android VpnService-i buruzko lau ustek astebetearen zati handi bat kendu zidaten behin, eta horietako bat ere ez zen sare-protokoloari buruzkoa. Aplikazioak konektatuta zioen, giltzaren ikonoa egoera-barran zegoen, eta trafikoa bide arruntetik ateratzen zen oraindik. Tunela nirea zela suposatzen jarraitzen nuen gelditu arte, gehitu nituen bideak lortzen nituen bideak zirela, eta stopSelf deitzeak interfazea berarekin eramango zuela. Zerbitzua dokumentatuta dagoen bezala jokatzen ari zen. Nire buru-eredua zen zatia apurtuta zegoena.

Mitoa 1: tunelak zutik jarraitzen du zu gelditu arte

Androidek VPN interfaze bat edukitzen du aldiko. Bigarren bat ezarri eta plataformak ez du ilaran jartzen: zurea desaktibatzen du eta onRevoke() deitzen du zure zerbitzuan. Zure kodea botoi-sakatzean bakarrik botatzen bada behera, kudeaketak deskriptore bat eta irakurketa-hari bat uzten ditu atzean, eta hurrengo abiarazteak biak heredatzen ditu.

VpnService erreferentzia esplizituki dio prepare() null itzultzen duela aplikazioak baimena badu jada, eta Intent bat erabiltzaileak oraindik onartu behar duenean. Baimen hori soilik iristen da asmoa startActivityForResult() bidez ematen baduzu. Saltatu entrega eta establish() null itzuliko du, eta hori isilako hutsegite gisa irakurtzen da, ez baimen-arazo gisa.

Always-on VPNek kontrolatzen ez duzun jabe bat gehitzen du. Sistemak tunela itzul dezake abiaraztearen ondoren edo kraskadura baten ondoren, eta erabiltzaileak eskuz abiarazitako VPN aplikazio bat aurre hartzen du. Eraiki onRevoke() zure ohiko itzaltzeak ixten dituen baliabide berak itxi ditzan, eta tratatu itzaltze-bide nagusi gisa, ez kasu arraro gisa. Erabiltzaileek VPN aplikazioak aldatzen dituzte; zure kodeari horri eustea dagokio.

Mitoa 2: addRoute-k zerrendatu duzun zehazki harrapatzen du

Bideek erabakitzen dute zein paketek iristen diren zure deskriptorera, eta esparru-errore batek trafikoaren zati bat tunelatik doan eta beste bat ez den kasu amorratzailea sortzen du. addRoute("0.0.0.0", 0) deitzeak IPv4 osoa hartzen du, hau da, pakete guztiak zuri iristen dira orain eta birbideratu edo baztertu egin behar dira. Ostalari bakarrerako /32 batek ia ezer ez du hartzen, eta gainontzeko guztiak VPNa inoiz instalatu ez balitz bezala jokatzen du.

Familiak bereizita zenbatzen dira. IPv4 bakarrik duen bideak IPv6 azpiko sarean uzten du, beraz pila biko ostalari batek tunelatik kanpo ebatzi eta konekta dezake oraindik, barrutik erabat konektatuta ematen duen bitartean.

DNSek logika bera jarraitzen du. addDnsServer() bidez gehitutako zerbitzariek tunelaren ebazlea erabiltzen duten aplikazioetara jotzen dute, eta bere DNS amaiera-puntu zifratua edo Private DNS ostalari-izenera ezarrita dituen aplikazio batek erabat ignoratzen ditu. Izenak aplikazio batentzat huts egiten duenean eta beste batentzat funtzionatzen duenean, egiaztatu ebazlearen bidea bide bakarra ukitu aurretik.

Mitoa 3: aplikazioko arauak edozein aldetara biratu daitekeen etengailua dira

addDisallowedApplication() eta addAllowedApplication() bi modu dira, ez bi iragazki. Eraikitzaileak tunel bakoitzeko eredu bat onartzen du, beraz hiru pakete ez beste guztia nahi duen aplikazio batek debekatutako zerrenda erabiltzen du eta baimendutako zerrenda hutsik uzten du. Biak elkar baztertzen dute, eta jendeak exekuzio-denboran deskubritzen du ezarpenen pantailak jada bi etengailuak eskaini ondoren.

Paketeen ikusgaitasunak ere hozka egiten du. Android 11 eta geroagokoetan ikus ditzakezun paketeak soilik izenda ditzakezu, beraz zure aplikazioak exekutatzeko baimenik ez duen kontsulta batetik eraikitako bazterketa-zerrendak isilean galduko ditu sarrerak. Alderatu zerrenda pakete-kudeatzaileak benetan itzultzen duenarekin, hari fidatu aurretik.

Lan-profilek publikoa berriro zatitzen dute. Profilean barruan abiarazitako tunelak profil hori eta bere aplikazioak estaltzen ditu, eta alde pertsonalak bere konektibitatea mantentzen du. Behin hartutako esparru-erabakia da, eta interfazean dagokio, ez laguntza-txartel batean.

Mitoa 4: stopSelf-ek tunela amaitzen du

Ez du amaitzen. Interfazea establish() itzultzen duen deskriptorean bizi da, eta zerbitzu-objektua hil daiteke deskriptorea irekita jarraitzen duen bitartean. Itxi ParcelFileDescriptor lehenengo, askatu erreferentzia, bat egin irakurketa- eta idazketa-hariekin edo eten itzazu, eta gero deitu stopForeground(true) eta stopSelf() ordena horretan.

Ahaztutako deskriptore bat da zerbitzu batek bere itzaltze-eskaera bera gainditzen duela ematen duen arrazoi ohikoa, eta gehitu zuen aplikazioa baino gehiago bizi den bide zaharkitu bat azaltzen du.

Aurkako akatsa bezain ohikoa da: deskriptorea ixtea irakurketa-hari bat irakurtzen ari den bitartean, eta gero hari horri inork idatzi ez duen salbuespen bat kudeatzen uztea. Mantendu itzaltze-sekuentzia leku bakarrean eta utzi erabiltzailearen ekintza eta onRevoke() hara deitzen.

Zer egiaztatu tunela hilda ematen duenean

Babestu bizitza luzeko socketak protect() erabiliz tunela altxatu aurretik. Hori gabe, tunelaren garraioa berriro tunelera bideratzen da eta konexioa trabatzen da zerbitzari-kalte baten itxura zehatza hartzen duen moduan. Probatu urrutiko sarearen atzean soilik existitzen den helbide baten aurka, cachetik edo azpiko bidetik erantzuten duen gune publiko baten aurka baino.

Erregistratu establish() deialdiaren emaitza, bideak, baztertutako paketeak eta itzaltzeko arrazoia. Lau lerro horiek baimen-arazoa esparru-arazotik eta bizitza-ziklo arazotik bereizten ditu pakete-kapturarik gabe.