VPN chrootissa Androidilla: miksi tunneli toimii ja sovellukset jättävät sen huomiotta

Asennat Linux-jakelun chrootin alle puhelimeen, laitat sinne VPN-asiakasohjelman ja kuori ilmoittaa tunnelin valmistuneen. Sitten siirryt selaimeen ja liikenne lähtee matkapuhelindatan kautta kuin mitään ei olisi tapahtunut. Tai päinvastoin: jokainen puhelimen sovellus menettää yhteyden, koska asiakasohjelma lisäsi oletusreitin nimiavaruuteen, jota Android todella käyttää. Molemmat oireet tulevat samasta puuttuvasta palasta, eikä kumpikaan ole VPN-asiakasohjelman vika.

Kuori sanoo yhdistetty, sovellukset ovat eri mieltä

Ensimmäinen tulos on tavallinen. chrootista avattu käyttäjätilan tunneli voi viimeistellä kättelynsä, tulostaa tilastonsa ja kuljettaa liikennettä, jonka sama kuori tuottaa, kun taas Androidin sovellukset käyttävät edelleen puhelimen oletusverkkoa. Mikään ei sieppaa niitä, koska mikään ei kertonut Androidille, että VPN on olemassa.

Toinen tulos on vaarallinen. Jos chroot jakaa Androidin verkon nimiavaruuden, kuten oletuksena tekee, riittävillä oikeuksilla varustettu prosessi voi lisätä reittejä ja TUN-rajapinnan, jotka vaikuttavat koko puhelimeen. Silloin tunneli toimii jokaiselle sovellukselle, myös niille, joita et aikonut reitittää, ja puhelimen yhteydet riippuvat nyt daemonista, jolla ei ole elinkaaren hallintaa, yhteysilmaisinta eikä aina päällä -käytäntöä.

Kumpi kahdesta tuloksesta tuli, selviää yhdellä komennolla. Vertaa ip route chrootin sisällä samaan komentoon Androidin kuoresta ulkopuolelta. Identtinen tuloste tarkoittaa, että chroot on isännän nimiavaruudessa: jokainen verkkomuutos koskee koko puhelinta. Erilainen tuloste tarkoittaa, että käynnistin loi sille nimiavaruuden ja sen tunneli on rakenteellisesti näkymätön Androidille.

Mitä chroot muutti ja mitä ei

Järjestelmäkutsu chroot tekee yhden asian: se vaihtaa hakemiston, jota käytetään polkujen tulkintaan. Man-sivu sanoo selvästi, ettei se ole turvaraja, eikä kerro mitään rajapinnoista, reiteistä tai VPN-tilasta. Kaikki, mitä ihmiset odottavat Linux-kontilta — yksityinen verkkopino, suodatettu tiedostojärjestelmä, resurssirajat — tulee muista mekanismeista, joita käynnistin on voinut käyttää tai olla käyttämättä.

Siksi väitteet, että chroot eristää VPN:n, vastaavat yleensä väärään kysymykseen. Olennainen kysymys on, missä nimiavaruudessa prosessi toimii ja mihin SELinux-verkkotunnukseen se on rajattu, ja molemmat ovat ominaisuuksia siitä, miten se käynnistettiin, ei sanasta chroot.

TUN tarvitsee kolme asiaa, ja laitesolmu on vain yksi

Perinteinen käyttäjätilan tunneli tarvitsee TUN-laitteen, jonka se voi avata, ytimen tuen sille laitteelle ja oikeuden määrittää rajapinnan ja reitit. Nämä ovat erillisiä vaatimuksia, eikä polun nimen luominen /dev-hakemistoon täytä itsessään yhtäkään niistä:

ls -l /dev/net/tun
ip tuntap add dev tun0 mode tun

Androidilla TUN-tuki on yleensä käännetty ytimeen, koska alustan oma VPN-palvelu käyttää sitä, mutta se ei tarkoita, että prosessisi saisi käyttää sitä. Rajapinnan määrittäminen vaatii verkonhallintakyvyn, ja SELinux päättää, pääseekö prosessi lainkaan laitesolmuun. Kielto näyttää oikeusvirheeltä ilman ilmeistä syytä, ja vastaus on auditointijäljessä:

dmesg | grep avc
logcat -d | grep "avc: denied"

Root ei ratkaise tätä. SELinux rajoittaa uid 0 -prosesseja täsmälleen kuten muitakin, joten root-kuoresta käynnistetty chroot voidaan silti evätä laitteelta, jonka se näkee. Pakotuksen poistaminen käytöstä vanhan asentajan toimimiseksi on koko puhelinta koskeva päätös, jonka seuraukset ulottuvat paljon tunnelia pidemmälle, eikä se ole vanhentuneen binäärin korjaus.

Miksi Androidin sovellukset jättävät tunnelisi huomiotta

Androidin tuettu malli on VPN-sovellus, joka rekisteröityy alustan VPN-palveluun, kysyy käyttäjältä suostumuksen kerran ja saa tunnelilleen tiedostokuvauksen. Sitten alusta ohjaa liikenteen siihen kuvaukseen ja toteuttaa sen sovelluslaajuuden, jonka käyttäjä tai ylläpitäjä valitsi, siksi sama mekanismi voi olla sovelluskohtainen, profiilikohtainen ja yhdistetty aina päällä- ja ilman VPN:ää estämisen asetuksiin. Androidin VPN-kehitysopas kuvaa sen kättelyn, ja keskeistä on, että se on rekisteröinti, ei reititystemppu.

chrootin sisällä oleva daemon ei koskaan rekisteröidy. Ei suostumusikkunaa, ei avainkuvaketta tilarivillä, ei sovelluskohtaista sisällytys- tai poissulkulus listaa eikä osallistumista aina päällä -käytäntöön. Siksi sovellukset käyttävät edelleen oletusverkkoa, ja tunneli kuljettaa vain sen, mitä kuori itse lähettää.

Toinenkaan suunta ei auta. Reittien työntäminen isännän nimiavaruuteen kaappaa kaiken, myös liikenteen, jonka alusta odotti pysyvän paikallisena, ja tekee sen ilman sovelluskohtaista hallintaa ja ilman, että käyttäjä voi nähdä tai peruuttaa sitä. Ei ole väliasetusta, jossa chrootin daemon reitittäisi liikennettä vain yhdelle sovellukselle.

Binääriyhteensopivuus on erillinen seinä

Vaikka verkkopuoli olisi kiinnostava, suoritettavalla tiedostolla on omat vaatimuksensa: suorittimen arkkitehtuuri, dynaaminen lataaja, C-kirjasto ja ne ytimen ominaisuudet, joita se odottaa. Android käyttää bionicia glibcin sijaan, ja työpöytäjakelulle käännetty vanha binääri voi tarvita kirjastoja, joita laitteessa ei enää ole.

Kirjaston tiedostonimen linkittäminen uudempaan versioon ei luo ABI-yhteensopivuutta, eikä kymmenen vuoden takaisesta paketista arkistoitu salauskirjasto ole ylläpidetty komponentti. Jos suunnitelma riippuu siitä, suunnitelma on ajaa ylläpitämätöntä koodia verkko-oikeuksin puhelimessa.

Todista se Androidin yhteydessä ja siivoa jäljet

Testaa sitä, millä on sinulle todella merkitystä, siltä puolelta joka ratkaisee: avaa kyseinen sovellus, saavuta kyseinen yksityinen kohde, varmista mikä ratkaisija vastasi, katkaise sitten tunneli ja varmista dokumentoitu käyttäytyminen. Tulos chrootin sisällä olevasta päätteestä on todiste kyseisen päätteen suoritusympäristöstä eikä muusta.

Jos muutit kokeen aikana isännän reittejä, palauta ne ja kirjaa mitä muutit. Tarkista sitten, onko puhelimeen määritetty aina päällä -VPN, koska säännön jättänyt vanha koe voi näyttää kuukausia myöhemmin alustan vialta.

Todelliseen etäkäyttötarpeeseen käytä palvelun tuettua asiakasohjelmaa tai hyväksyttyä yhdyskäytäväratkaisua. Kysymys, joka kannattaa esittää, ei ole se, saadaanko root-asentaja toimimaan, vaan se, kuljettaako tuettu toteutus tarvitsemasi sovellukset aiottujen rajojen yli jättämättä laitteeseen omistajattomia etuoikeutettuja muutoksia.