Android chroot VPN: zašto tunel radi, a aplikacije ga ignorišu

Pokrenete Linux distribuciju pod chroot-om na telefonu, instalirate VPN klijent u njoj, i shell objavi da je tunel spreman. Zatim pređete na pregledač i saobraćaj izlazi preko mobilnih podataka kao da se ništa nije dogodilo. Ili obrnuto: svaka aplikacija na telefonu izgubi vezu jer je klijent postavio podrazumevanu rutu u namespace koji Android zaista koristi. Oba simptoma dolaze iz istog dela koji nedostaje, i nijedan nije greška u VPN klijentu.

Shell kaže povezano, aplikacije se ne slažu

Prvi ishod je uobičajen. Tunel u korisničkom prostoru otvoren iz chroot-a može završiti rukovanje, ispisati statistiku i prenositi saobraćaj koji stvara isti shell, dok Android aplikacije nastavljaju da koriste podrazumevanu mrežu telefona. Ništa ih ne presreće, jer ništa nije reklo Androidu da VPN postoji.

Drugi ishod je opasan. Ako chroot deli mrežni namespace Androida, što po defaultu čini, proces sa dovoljno privilegija može dodati rute i TUN interfejs koji utiču na ceo telefon. Tada tunel radi za svaku aplikaciju, uključujući one koje niste nameravali da rutujete, a veza telefona sada zavisi od demona bez upravljanja životnim ciklusom, bez indikatora veze i bez politike stalnog uključenja.

Koji od dva slučaja imate može se utvrditi jednom komandom. Uporedite ip route unutar chroot-a sa istom komandom iz Android shella spolja. Identičan izlaz znači da je chroot u namespace-u hosta: svaka mrežna promena koju napravi važi za ceo telefon. Različit izlaz znači da je launcher napravio namespace za njega, i njegov tunel je Androidu nevidljiv po konstrukciji.

Šta je chroot promenio, a šta nije

Sistemski poziv chroot radi jednu stvar: menja direktorijum koji se koristi za razrešavanje imena putanja. Man stranica izričito kaže da to nije bezbednosna granica i ne govori ništa o interfejsima, rutama ili stanju VPN-a. Sve što ljudi očekuju od Linux kontejnera — privatni mrežni stek, filtrirani fajl sistem, ograničenja resursa — dolazi iz drugih mehanizama koje je launcher možda ili nije koristio.

Zato tvrdnje da chroot izoluje VPN obično odgovaraju na pogrešno pitanje. Relevantno pitanje je u kom namespace-u proces radi i na koji SELinux domen je ograničen, a oba su osobine načina na koji je pokrenut, ne reči chroot.

TUN traži tri stvari, a čvor uređaja je samo jedna

Tradicionalni tunel u korisničkom prostoru traži TUN uređaj koji može otvoriti, podršku kernela za taj uređaj i dozvolu za konfigurisanje interfejsa i ruta. To su odvojeni zahtevi, a pravljenje imena putanje pod /dev samo po sebi ne ispunjava nijedan od njih:

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

Na Androidu kernel obično ima ugrađenu TUN podršku, jer je koristi sopstvena VPN usluga platforme, ali to ne znači da vaš proces sme da je koristi. Konfiguracija interfejsa traži sposobnost mrežne administracije, a SELinux odlučuje da li proces uopšte može da dođe do čvora uređaja. Odbijanje izgleda kao greška dozvole bez očiglednog uzroka, a odgovor je u revizijskom tragu:

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

Root ovo ne rešava. SELinux ograničava procese koji rade kao uid 0 isto kao i ostale, pa chroot pokrenut iz root shella i dalje može biti odbijen za uređaj koji vidi. Isključivanje primene radi rada starog instalatera je odluka za ceo telefon sa posledicama daleko izvan tunela i nije popravka zastarelog binarnog fajla.

Zašto Android aplikacije ignorišu vaš tunel

Podržani model Androida je VPN aplikacija koja se registruje preko VPN usluge platforme, jednom traži saglasnost korisnika i dobija fajl deskriptor za svoj tunel. Platforma zatim usmerava saobraćaj u taj deskriptor i primenjuje opseg aplikacija koji je izabrao korisnik ili administrator, zato isti mehanizam može biti po aplikaciji, po profilu i kombinovan sa postavkama stalnog uključenja i blokiranja bez VPN-a. Android vodič za razvoj VPN-a opisuje to rukovanje, a ključno je da je to registracija, a ne trik sa rutiranjem.

Demon unutar chroot-a se nikada ne registruje. Nema dijaloga saglasnosti, nema ikone ključa u statusnoj traci, nema liste uključivanja ili isključivanja po aplikaciji i nema učešća u politici stalnog uključenja. Zato aplikacije nastavljaju da koriste podrazumevanu mrežu, a tunel prenosi samo ono što shell sam pošalje.

Ni odlazak u drugu krajnost ne pomaže. Guranje ruta u namespace hosta hvata sve, uključujući saobraćaj koji je platforma očekivala da ostane lokalni, i to bez kontrole po aplikaciji i bez načina da korisnik to vidi ili opozove. Nema srednje postavke u kojoj chroot demon rutuje saobraćaj samo za jednu aplikaciju.

Binarna kompatibilnost je poseban zid

Čak i kada je mrežna strana zanimljiva, izvršni fajl ima svoje zahteve: arhitekturu procesora, dinamički loader, C biblioteku i mogućnosti kernela koje očekuje. Android koristi bionic umesto glibc, a stari binarni fajl izgrađen za desktop distribuciju može tražiti biblioteke kojih više nema na uređaju.

Simboličko povezivanje imena biblioteke sa novijom verzijom ne stvara ABI kompatibilnost, a arhivirana kriptografska biblioteka iz paketa starog deceniju nije održavana komponenta. Ako plan zavisi od toga, plan je pokretati neodržavani kod sa mrežnim privilegijama na telefonu.

Dokažite to u Android kontekstu i očistite za sobom

Testirajte ono što vam je zaista važno, sa strane koja je važna: otvorite konkretnu aplikaciju, stignite do konkretnog privatnog odredišta, potvrdite koji je resolver odgovorio, zatim isključite tunel i potvrdite dokumentovano ponašanje. Rezultat iz terminala unutar chroot-a je dokaz samo o kontekstu izvršavanja tog terminala i ništa više.

Ako ste tokom eksperimenata menjali rute hosta, vratite ih i zapišite šta ste promenili. Zatim proverite da li telefon ima konfigurisan VPN sa stalnim uključenjem, jer stari eksperiment koji je ostavio pravilo može izgledati kao kvar platforme mesecima kasnije.

Za stvarnu potrebu za daljinskim pristupom koristite podržani klijent usluge ili odobren dizajn gejtveja. Pitanje koje vredi postaviti nije da li se root instalater može pokrenuti, već da li podržana implementacija prenosi potrebne aplikacije preko granice koju ste nameravali, bez ostavljanja privilegovanih izmena bez vlasnika na uređaju.