Android VPN: VpnServicen kuvaaja vastaan root-tun-laite

Kaksi polkua voi asettaa IP-rajapinnan Android-sovelluksen eteen, ja molemmat päättyvät samantyyppiseen tiedostokuvaajaan, joiden omistajat ovat hyvin erilaisia. Toinen kulkee VpnServicen ja sen builderin kautta, toinen root-kuoren ja /dev/net/tunin kautta. Jokainen luku tuosta kuvaajasta on lähtevä paketti ja jokainen kirjoitus saapuva. Polut erottaa se, kellä on käytäntö, mikä selviää käyttöjärjestelmän päivityksestä ja kuinka paljon reititystaulua saat koskea.

Valitse alustan polku, ellet pysty nimeämään sitä konkreettista asiaa, josta se kieltäytyy. Se kieltäytyminen on yleensä TAP, kaappaus oman sovellusjoukkosi ulkopuolelta tai reitityssääntö, jota kehys ei koskaan paljasta.

Alustan polulla ilmoitat aikomuksen komentojen sijaan. Annat vähintään yhden osoitteen, haluamasi reitit, DNS-palvelimet ja valinnaisen sovellusluettelon, minkä jälkeen Androidin järjestelmäpalvelu tekee etuoikeutetut asetukset oman identiteettinsä alla. Et koskaan opi rajapinnan nimeä etukäteen etkä koskaan anna ioctlia, joka sen luo, ja juuri se on pointti.

Kaksi tapaa saada IP-rajapinta

Root-polku on vanhempi resepti. Avaat /dev/net/tunin, kutsut TUNSETIFFiä IFF_TUNilla, nostat rajapinnan ip linkillä ja lisäät osoitteet ja reitit käsin. Jokainen vaihe on sinun saatava oikein, myös ne, jotka kehys olisi hoitanut hiljaa. Yksi puuttuva reitti tuottaa saman käyttäjäraportin kuin kuollut palvelin.

Vianetsintä eroaa yhtä paljon kuin asetukset. Root-polulla rajapinta joko on olemassa tai ioctl palautti virheen, jonka voit lukea suoraan. Alustan polulla rajapinta on olemassa vasta, kun establish() onnistuu, joten epäonnistuminen saapuu poikkeuksena tai null-kuvaajana eikä laitesolmuna, jota voisit tongita.

Mitä establish() todella palauttaa

Builder.establish()llä on kolme lopputulosta ja ne vaativat kolme eri vastausta. Kuvaaja tarkoittaa, että rajapinta on määritetty ja sinun käytettävissäsi, null tarkoittaa, ettei pyyntö mennyt läpi, ja heitetty poikkeus tarkoittaa, että järjestelmäpalvelu hylkäsi sen. nullin ja onnistumisen latominen yhteen booleaniin on yleisin tapa, jolla sovellus raportoi toimivasta tunnelista, joka ei koskaan kanna pakettia. Builder-viite kertoo osoitevaatimuksen, ja se kannattaa lukea ennen kuin syytät palvelinta.

Suunnat määrää kuvaaja, ei protokollasi. Lukemiset antavat sinulle lähteviä paketteja, jotka on jo valittu VPN:lle, ja kirjoitukset ruiskuttavat saapuvia paketteja takaisin rajapintaan. Oma siirtokerroksesi salaa, todentaa ja kehystää ne paketit, koska alusta pysähtyy paketin rajalle.

Binder on yksi hyppy, JNI on toinen akseli

Builder-pyyntö ylittää järjestelmään Binderin kautta, ja jossain sen alla alusta kutsuu natiivikoodia laitteen määrittämiseksi. Ne ovat kaksi eri mekanismia pinottuna yhteen kutsuun. Binder on prosessien välinen viestintä sovelluksesi ja järjestelmäpalvelun välillä, kun taas JNI on Java-natiivisilta prosessin sisällä. Android 9 AOSP-puun lukeminen saa pinon näyttämään kirjaimelliselta, ja kannattaa muistaa, että sisäiset luokkanimet ja tiedostopolut liikkuvat julkaisujen välillä.

Se, mikä ei liiku, on sopimus, johon voit luottaa: builder, sen palauttama kuvaaja ja sen ympärillä oleva palvelun elinkaari. Minkään sovelluksen ei pitäisi kutsua sisäistä palvelutapahtumaa tai luoda laitesolmua uudelleen saadakseen rajapinnan. Jos koodisi riippuu AOSP-luokkanimestä, se hajoaa julkaisussa, jota et testannut.

TUN kuljettaa IP:tä, TAP Ethernetiä

TUN on IP-rajapinta. TAP on Ethernet-rajapinta, ja tämä ero ratkaisee, onko siltaaminen ylipäätään mahdollista. TUN-laitteella ei ole MAC-osoitetta eikä välitettävää Ethernet-otsikkoa, joten TUN-asiakas ei voi liittyä kerroksen 2 siltaan, miten reitit tahansa kirjoitetaan.

VpnService antaa sinulle IP-muunnoksen, jonka sovellustason VPN tarvitsee ja jonka se voi tukea ilman raakaa Ethernet-pinoa. Jos suunnitelmasi vaatii siltaamista, alustan polku ei vie sinua sinne, ja root-polku vain jos ydin ja laitteen käyttöoikeudet tekevät yhteistyötä.

Missä root-polku yhä voittaa

Kolme työtä työntää ihmisiä pois alustan polulta. Kerroksen 2 siltaaminen tarvitsee TAPin. Liikenteen kaappaaminen oman VPN-alueesi ulkopuolisista sovelluksista tarvitsee näkyvyyttä, jota kehys ei anna. Käytäntöpohjainen reititys, jota builder ei koskaan paljasta, kuten erillinen taulu yhdelle kohteelle, tarvitsee sääntöjä, jotka asennat itse.

Kustannukset tulevat myöhemmin: avattu bootloader tai rootattu levykuva, SELinux-käytäntö, joka liikkuu allasi, ja laite, joka lakkaa käyttäytymästä oikein OTA:n jälkeen. Rootattua reseptiä ei myöskään voi jakaa tavallisen sovellusjakelun kautta, joten useimmat tiimit pitävät sitä sisäisenä diagnostiikkapolkuna eikä tuotteena.

Valinta niiden välillä

Aloita rajapinnasta, jonka tarvitset, älä koodista, joka sinulla on. Jos vastaus on TUN-laite, jossa on sovelluskohtaiset reitit, alustan polku on lyhyempi ja kestää päivitykset. Jos vastaus sisältää Ethernet-kehyksiä, muiden sovellusten kaappausta tai reitityssääntöjä, jotka builder hylkää, olet root-alueella ja sinun pitäisi budjetoida se käyttökustannukseksi.

Tarkistus, joka ratkaisee useimmat väittelyt: rakenna ensin alustan polku, kirjaa establish()n tulos erikseen etäistunnon tilasta ja vahvista yksi paketti kumpaankin suuntaan. Vasta sitten päätä, oikeuttaako puuttuva ominaisuus tuetulta polulta poistumisen.