Android VPN: VpnService deskriptorea eta root tun gailua

Bi bidek IP interfaze bat jar dezakete Android aplikazio baten aurrean, eta biek deskriptore mota berberean amaitzen dute, jabe oso desberdinekin. Bata VpnService eta bere builderretik doa, bestea root shell eta /dev/net/tun-etik. Deskriptore horretako irakurketa bakoitza irteerako pakete bat da eta idazketa bakoitza sarrerakoa. Bideak bereizten dituena politika nork duen, OS eguneraketa nork gainditzen duen eta bideratze-taularen zenbat uki dezakezun da.

Hartu plataformaren bidea egiteari uko egiten dion gauza zehatza izendatzen ez baduzu. Ukapen hori TAP izan ohi da, zure aplikazio-multzoaz kanpoko kaptura, edo framework-ak inoiz erakusten ez duen bideratze-araua.

Plataformaren bidean asmoa deklaratzen duzu, komandoak ordez. Gutxienez helbide bat, nahi dituzun ibilbideak, DNS zerbitzariak eta aukerako aplikazio-zerrenda ematen dituzu; gero Androiden sistema-zerbitzuak konfigurazio pribilegiatua egiten du bere nortasunarekin. Ez duzu interfazearen izena aurrez ezagutzen, eta ez duzu inoiz sortzen duen ioctl-a igortzen, eta horixe da kontua.

IP interfaze bat lortzeko bi modu

Root bidea errezeta zaharragoa da. /dev/net/tun irekitzen duzu, TUNSETIFF deitzen duzu IFF_TUN-ekin, interfazea ip link-ekin igotzen duzu eta helbideak eta ibilbideak eskuz gehitzen dituzu. Urrats bakoitza zurea da ondo egiteko, framework-ak isilean egingo lituzkeenak barne. Ibilbide bat falta izateak zerbitzari hilak bezalako erabiltzaile-txostena sortzen du.

Arazketak konfigurazioak adina desberdintzen du. Root bidean interfazea existitzen da edo zure ioctl-ak zuzenean irakur dezakezun errore bat itzuli du. Plataformaren bidean interfazea establish() arrakastatsua izan ondoren bakarrik existitzen da, beraz hutsak salbuespen edo null deskriptore gisa iristen dira, miatu dezakezun gailu-nodo gisa beharrean.

Zer itzultzen duen establish()ek benetan

Builder.establish()ek hiru emaitza ditu eta hiru erantzun desberdin behar dituzte. Deskriptore batek interfazea konfiguratuta dagoela eta zurea dela esan nahi du, null-ek eskaera ez zela igaro, eta botatako salbuespen batek sistema-zerbitzuak baztertu zuela. null eta arrakasta booleano bakarrean batzea ohikoena da aplikazio batek inoiz paketerik eramaten ez duen tunel funtzional bat jakinarazteko. Builder erreferentziakoak helbide-baldintza adierazten du, eta merezi du irakurtzea zerbitzaria erruduntzatu aurretik.

Norabideak deskriptoreak finkatzen ditu, ez zure protokoloak. Irakurkuntzek VPNrako hautatuta dauden irteerako paketeak ematen dizkizute, eta idazketek sarrerako paketeak interfazera berriz injektatzen dituzte. Zure garraio propioak zifratzen, autentifikatzen eta markoztatzen ditu pakete horiek, plataformak paketearen mugan gelditzen delako.

Binder jauzi bat da, JNI beste ardata bat

Builder eskaera bat sistemara Binder bidez sartzen da, eta horren azpian nonbait plataformak kode natiboa deitzen du gailua konfiguratzeko. Bi mekanismo desberdin dira, dei bakarrean pilatuta. Binder zure aplikazioaren eta sistema-zerbitzuaren arteko prozesuen arteko komunikazioa da, JNI berriz prozesu baten barruko Java-tik-natiborako zubia. Android 9 AOSP zuhaitz bat irakurtzeak pila literal bihurtzen du, eta gogoratu behar da barne-klaseen izenak eta fitxategi-bideak bertsioen artean mugitzen direla.

Mugitzen ez dena fidagarritzat har dezakezun kontratua da: builderra, itzultzen duen deskriptorea eta haren inguruko zerbitzuaren bizi-zikloa. Aplikazio batek ez luke zerbitzu-transakzio interno bat deitu behar, ezta gailu-nodo bat berriz sortu ere interfaze bat lortzeko. Zure kodea AOSP klase-izen baten mende badago, probatu ez duzun bertsio batean apurtuko da.

TUNek IP eramaten du, TAPek Ethernet

TUN IP interfaze bat da. TAP Ethernet interfaze bat da, eta desberdintasun horrek erabakitzen du zubia posible den. TUN gailu batek ez du MAC helbiderik eta ez du Ethernet goibururik birbidaltzeko, beraz TUN bezero batek ezin du geruza 2ko zubi batera sartu, ibilbideak nola idatzita ere.

VpnServicek IP aldaera ematen dizu, aplikazio-mailako VPN batek behar duena eta Ethernet pila gordinik gabe onar dezakeena. Zure diseinuak zubia behar badu, plataformaren bideak ez zaitu hara eramango, eta root bideak bai, kernelak eta gailuaren baimenek elkarlanean aritzen badira soilik.

Non irabazten duen oraindik root bideak

Hiru lanek jendea plataformaren bidetik kanporatzen dute. Geruza 2ko zubiak TAP behar du. Zure VPN esparrutik kanpoko aplikazioen trafikoa harrapatzeko framework-ak ematen ez duen ikusgaitasuna behar da. Builderrak inoiz erakusten ez duen politika-bideratzeak, adibidez helmuga baterako taula bereizia, zeuk instalatzen dituzun arauak behar ditu.

Kostuak geroago etortzen dira: bootloader desblokeatua edo rootdun irudia, zure azpian mugitzen den SELinux politika eta OTA baten ondoren ondo jokatzen uzten duen gailua. Rootdun errezeta bat ezin da banaketa arrunteko aplikazio-banaketaren bidez kaleratu, beraz talde gehienek diagnostiko-bide interno gisa gordetzen dute, produktu gisa beharrean.

Haietan artean aukeratzea

Hasi behar duzun interfazetik, ez duzun kodetik. Erantzuna aplikazio-esparruko ibilbideak dituen TUN gailu bat bada, plataformaren bidea laburragoa da eta eguneratzeak gainditzen ditu. Erantzunak Ethernet markoak, beste aplikazioen kaptura edo builderrak baztertzen dituen bideratze-arauak baditu, root lurraldean zaude eta eragiketa-kostu gisa aurrekontuan hartu beharko zenuke.

Eztabaida gehienak ebazten dituen egiaztapena: eraiki lehenik plataformaren bidea, erregistratu establish()ren emaitza urruneko saioaren egoeratik bereizita, eta berretsi pakete bat norabide bakoitzean. Orduan soilik erabaki ea falta den gaitasunak bidea uztea justifikatzen duen.