Android chroot VPN: waarom die tonnel werk en programme dit ignoreer

Jy kry ’n Linux-verspreiding wat onder ’n chroot op die selfoon loop, installeer ’n VPN-kliënt daarin, en die dop kondig ’n voltooide tonnel aan. Dan skakel jy na ’n blaaier en die verkeer gaan oor mobiele data uit asof niks gebeur het nie. Of die teenoorgestelde: elke program op die selfoon verloor konnektiwiteit omdat die kliënt ’n verstekroete in die naamruimte gesit het wat Android werklik gebruik. Daardie twee simptome kom uit dieselfde ontbrekende stuk, en nie een is ’n fout in die VPN-kliënt nie.

Die dop sê verbind, die programme stem nie saam nie

Die eerste uitkoms is die algemene een. ’n Gebruikerspasie-tonnel wat uit ’n chroot oopgemaak word, kan sy handdruk voltooi, sy statistieke druk en verkeer dra wat dieselfde dop genereer, terwyl Android se programme die selfoon se versteknetwerk bly gebruik. Niks onderskep hulle nie, want niks het vir Android gesê dat ’n VPN bestaan nie.

Die tweede uitkoms is die gevaarlike een. As die chroot Android se netwerknaamruimte deel, wat by verstek gebeur, kan ’n proses met genoeg voorregte roetes en ’n TUN-koppelvlak byvoeg wat die hele selfoon raak. Dan werk die tonnel vir elke program, ook dié wat jy nie wou roeteer nie, en die selfoon se konnektiwiteit hang nou af van ’n daemon sonder lewensiklusbestuur, sonder konneksie-aanwyser en sonder altyd-aan-beleid.

Watter van die twee jy gekry het, is met een opdrag te beantwoord. Vergelyk ip route binne die chroot met dieselfde opdrag uit ’n Android-dop daarbuite. Identiese uitset beteken die chroot is in die gasheer-naamruimte: enige netwerkverandering wat dit maak, geld vir die hele selfoon. Uitset wat verskil beteken die lanseerder het ’n naamruimte daarvoor geskep, en sy tonnel is per konstruksie onsigbaar vir Android.

Wat die chroot verander het en wat nie

Die chroot-stelseloproepteken doen een ding: dit verander die gids wat vir padopsoeking gebruik word. Die man-bladsy is duidelik dat dit nie ’n sekuriteitsgrens is nie, en dit sê niks oor koppelvlakke, roetes of VPN-toestand nie. Alles wat mense van ’n Linux-houer verwag — ’n privaat netwerkstapel, ’n gefiltreerde lêerstelsel, hulpbronbeperkings — kom uit ander meganismes wat ’n lanseerder wel of nie gebruik het nie.

Daarom beantwoord bewerings dat ’n chroot ’n VPN isoleer, gewoonlik die verkeerde vraag. Die relevante vraag is in watter naamruimte die proses loop en aan watter SELinux-domein dit gebind is, en albei is eienskappe van hoe dit begin is, nie van die woord chroot nie.

TUN het drie dinge nodig, en ’n toestelknoop is net een

’n Tradisionele gebruikerspasie-tonnel het ’n TUN-toestel nodig wat dit kan oopmaak, kernondersteuning vir daardie toestel, en toestemming om die koppelvlak en roetes te konfigureer. Dit is afsonderlike vereistes, en die skep van ’n padnaam onder /dev bevredig nie een daarvan op sigself nie:

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

Op Android het die kern gewoonlik TUN-ondersteuning ingebou, omdat die platform se eie VPN-diens dit gebruik, maar dit beteken nie jou proses mag dit gebruik nie. Koppelvlakkonfigurasie benodig die netwerkadministrasie-vermoë, en SELinux besluit of die proses die toestelknoop hoegenaamd mag bereik. ’n Weiering lyk soos ’n toestemmingsfout sonder duidelike oorsaak, en die ouditspoor is waar die antwoord lê:

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

Root los dit nie op nie. SELinux beperk prosesse wat as uid 0 loop net soos ander, so ’n chroot wat uit ’n root-dop begin is, kan steeds ’n toestel geweier word wat dit kan sien. Om afdwinging te deaktiveer om ’n ou installeerder te laat werk, is ’n selfoonwye besluit met gevolge ver buite die tonnel, en dit is nie ’n oplossing vir ’n verouderde binêre lêer nie.

Waarom Android-programme jou tonnel ignoreer

Android se ondersteunde model is ’n VPN-program wat by die platform se VPN-diens registreer, die gebruiker een keer om toestemming vra en ’n lêerbeskrywer vir sy tonnel ontvang. Die platform stuur dan verkeer in daardie beskrywer in en handhaaf die programomvang wat die gebruiker of administrateur gekies het, daarom kan dieselfde meganisme per program, per profiel en saam met altyd-aan- en blokkeer-sonder-VPN-instellings werk. Die Android VPN-ontwikkelingsgids beskryf daardie handdruk, en die kernpunt is dat dit ’n registrasie is, nie ’n roeteringstruuk nie.

’n Daemon binne ’n chroot registreer nooit nie. Daar is geen toestemmingsdialoog, geen sleutelikoon in die statusbalk, geen insluit- of uitsluitlys per program en geen deelname aan die altyd-aan-beleid nie. Programme hou dus aan om die versteknetwerk te gebruik, en die tonnel dra net wat die dop self stuur.

Die ander rigting help ook nie. Om roetes in die gasheer-naamruimte in te stoot, vang alles in, ook verkeer wat die platform plaaslik wou hou, en dit doen so sonder beheer per program en sonder manier vir die gebruiker om dit te sien of te herroep. Daar is geen middelinstelling waar ’n chroot-daemon verkeer vir net een program roeteer nie.

Binêre versoenbaarheid is ’n aparte muur

Selfs wanneer die netwerkkant interessant is, het die uitvoerbare lêer sy eie vereistes: CPU-argitektuur, die dinamiese laaier, die C-biblioteek en die kernfasiliteite wat dit verwag. Android gebruik bionic eerder as glibc, en ’n ou binêre lêer wat teen ’n lessenaarverspreiding gebou is, kan biblioteke nodig hê wat nie meer op die toestel bestaan nie.

Om ’n biblioteeklêernaam aan ’n nuwer weergawe te koppel, skep nie ABI-versoenbaarheid nie, en ’n geargiveerde kriptografiese biblioteek uit ’n pakket van tien jaar oud is nie ’n onderhoude komponent nie. As die plan daarvan afhang, is die plan om ononderhoude kode met netwerkvoorregte op ’n selfoon te laat loop.

Bewys dit in die Android-konteks en ruim daarna op

Toets wat jy werklik saak maak, van die kant wat saak maak: maak die spesifieke program oop, bereik die spesifieke private bestemming, bevestig watter oplosser geantwoord het, ontkoppel dan die tonnel en bevestig die gedokumenteerde gedrag. ’n Resultaat uit ’n terminal binne die chroot is bewyse oor daardie terminal se uitvoeringskonteks en niks meer nie.

As jy gasheerroetes verander het tydens eksperimentering, draai dit terug en teken op wat jy verander het. Kyk dan of die selfoon ’n altyd-aan-VPN het, want ’n ou eksperiment wat ’n reël agtergelaat het, kan maande later soos ’n platformfout lyk.

Vir ’n werklike afstandtoegangsvereiste, gebruik die diens se ondersteunde kliënt of ’n goedgekeurde poortwegontwerp. Die vraag wat die moeite werd is om te vra, is nie of ’n geroote installeerder laat werk kan word nie, maar of ’n ondersteunde implementering die programme wat jy nodig het oor die grens dra wat jy bedoel het, sonder om onbeheerde bevoorregte veranderinge op die toestel te laat nie.