Android chroot VPN: kvifor tunnelen verkar og appane ignorerer han

Du får ein Linux-distribusjon som køyrer under chroot på telefonen, installerer ein VPN-klient i han, og skalet melder at tunnelen er ferdig. Så byter du til ein nettlesar, og trafikken går ut over mobildata som om ingenting hadde hendt. Eller det motsette: kvar app på telefonen mistar sambandet fordi klienten la inn ei standardrute i namnerommet Android faktisk brukar. Begge symptoma kjem frå den same manglande biten, og ingen av dei er ein feil i VPN-klienten.

Skalet seier tilkopla, appane er usamde

Det første utfallet er det vanlege. Ein brukarrørsletunnel opna frå chroot kan fullføre handtrykket, skrive ut statistikken og frakte trafikk som det same skalet genererer, medan appane til Android held fram med å bruke standardnettverket til telefonen. Ingenting fangar dei opp, fordi ingenting fortalde Android at ein VPN finst.

Det andre utfallet er det farlege. Viss chroot deler nettverksnamnerommet til Android, noko han gjer som standard, kan ein prosess med nok privilegium leggje til ruter og eit TUN-grensesnitt som påverkar heile telefonen. Då verkar tunnelen for kvar app, også dei du ikkje hadde tenkt å rute, og sambandet til telefonen er no avhengig av ein tenesteprosess utan livssyklusstyring, utan tilkoplingsindikator og utan alltid-på-policy.

Kva av dei to du fekk, kan avgjerast med éin kommando. Samanlikn ip route inne i chroot med den same kommandoen frå eit Android-skal utanfor. Identisk utdata betyr at chroot er i namnerommet til verten: kvar nettverksendring han gjer, gjeld heile telefonen. Ulik utdata betyr at oppstartaren laga eit namnerom for han, og tunnelen er usynleg for Android av natur.

Kva chroot endra og kva han ikkje endra

Systemkallet chroot gjer éin ting: det endrar katalogen som blir brukt til å slå opp banenamn. Man-sida seier tydeleg at det ikkje er ei sikkerheitsgrense, og ho seier ingenting om grensesnitt, ruter eller VPN-tilstand. Alt folk ventar av ein Linux-container — ein privat nettverksstakk, eit filtrert filsystem, ressursgrenser — kjem frå andre mekanismar som oppstartaren kan ha brukt eller ikkje.

Derfor svarar påstandar om at chroot isolerer ein VPN vanlegvis på feil spørsmål. Det relevante spørsmålet er kva namnerom prosessen køyrer i og kva SELinux-domene han er avgrensa til, og begge er eigenskapar ved korleis han vart starta, ikkje ved ordet chroot.

TUN treng tre ting, og ein eining-node er berre éin

Ein tradisjonell brukarrørsletunnel treng ei TUN-eining han kan opne, kjernestøtte for den eininga og løyve til å konfigurere grensesnittet og rutene. Dette er separate krav, og å lage eit banenamn under /dev oppfyller ingen av dei i seg sjølv:

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

På Android har kjernen vanlegvis TUN-støtte kompilert inn, fordi VPN-tenesta til plattforma sjølv brukar ho, men det betyr ikkje at prosessen din får bruke ho. Grensesnittkonfigurasjon krev nettverksadministrasjonsrettar, og SELinux avgjer om prosessen i det heile får nå eining-noden. Ei avvising ser ut som ein tilgangsfeil utan openberr årsak, og svaret finst i revisjonsloggen:

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

Root løyser ikkje dette. SELinux avgrensar prosessar som køyrer som uid 0 på same måte som andre, så ein chroot starta frå eit root-skal kan framleis bli nekta ei eining han ser. Å slå av handhevinga for å få ein gammal installasjonspakke til å verke er eit vedtak for heile telefonen med følgjer langt utover tunnelen, og det er inga retting av ein utdatert binærfil.

Kvifor Android-appar ignorerer tunnelen din

Den støtta modellen i Android er ein VPN-app som registrerer seg gjennom VPN-tenesta til plattforma, ber brukaren om samtykke éin gong og får ein fildeskriptor for tunnelen sin. Plattforma ruter deretter trafikken inn i den deskriptoren og handhevar appomfanget brukaren eller administratoren valde, og difor kan den same mekanismen vere per app, per profil og kombinert med alltid-på og blokker-utan-VPN-innstillingar. Android si VPN-utviklarrettleiing skildrar det handtrykket, og poenget er at det er ei registrering, ikkje eit rutetriks.

Ein tenesteprosess inne i chroot registrerer seg aldri. Det finst ingen samtykkedialog, ingen nøkkelikon i statuslinja, inga liste for å ta med eller utelate appar, og ingen deltaking i alltid-på-policyen. Appane held derfor fram med å bruke standardnettverket, og tunnelen fraktar berre det skalet sjølv sender.

Den andre vegen hjelper heller ikkje. Å dytte ruter inn i namnerommet til verten fangar alt, også trafikk plattforma venta å halde lokalt, og det skjer utan kontroll per app og utan at brukaren kan sjå eller trekkje det tilbake. Det finst inga mellominnstilling der ein chroot-tenesteprosess ruter trafikk for berre éin app.

Binærkompatibilitet er ein eigen mur

Sjølv når nettverkssida er interessant, har den køyrbare fila sine eigne krav: CPU-arkitektur, den dynamiske lastaren, C-biblioteket og kjernefacilitetane ho ventar. Android brukar bionic i staden for glibc, og ein gammal binærfil bygd for ein skrivebordsdistribusjon kan trengje bibliotek som ikkje finst på eininga lenger.

Å lenkje eit bibliotekfilnamn symbolsk til ein nyare versjon gir ikkje ABI-kompatibilitet, og eit arkivert kryptobibliotek frå ein ti år gammal pakke er ikkje ein vedlikehalden komponent. Viss planen er avhengig av det, er planen å køyre uvedlikehalden kode med nettverksprivilegium på ein telefon.

Prov det i Android-konteksten og rydd opp etterpå

Test det du faktisk bryr deg om, frå den sida som betyr noko: opne den bestemte appen, nå den bestemte private destinasjonen, stadfest kva resolver som svara, kople deretter frå tunnelen og stadfest den dokumenterte åtferda. Eit resultat frå ein terminal inne i chroot er prov om køyretidskonteksten til den terminalen og ingenting meir.

Viss du endra vertsruter medan du eksperimenterte, set dei tilbake og skriv ned kva du endra. Sjekk deretter om telefonen har ein alltid-på-VPN konfigurert, fordi eit eldre eksperiment som la att ei regel kan sjå ut som ein plattformfeil månader seinare.

For eit reelt behov for fjernåtkomst, bruk den støtta klienten til tenesta eller ei godkjend gateway-utforming. Spørsmålet som er verdt å stille er ikkje om ein roota installasjonspakke kan fås til å køyre, men om ei støtta implementering fraktar appane du treng over grensa du meinte, utan å leggje att eierlause privilegerte endringar på eininga.