Android chroot VPN: bakit gumagana ang tunnel at binabalewala ito ng mga app

Nakakuha ka ng Linux distribution na tumatakbo sa ilalim ng chroot sa telepono, nag-install ka ng VPN client sa loob nito, at inaanunsyo ng shell na tapos na ang tunnel. Pagkatapos ay lumipat ka sa browser at lumalabas ang trapiko sa mobile data na parang walang nangyari. O kabaligtaran: nawawalan ng koneksyon ang bawat app sa telepono dahil naglagay ang client ng default na ruta sa namespace na aktuwal na ginagamit ng Android. Ang dalawang sintomas ay nagmumula sa parehong kulang na piraso, at wala sa kanila ang bug sa VPN client.

Sabi ng shell konektado, hindi sumasang-ayon ang mga app

Ang unang resulta ang karaniwan. Ang tunnel sa user space na binuksan mula sa chroot ay maaaring tapusin ang handshake, i-print ang estadistika at magdala ng trapikong nililikha ng parehong shell, habang patuloy na ginagamit ng mga app ng Android ang default na network ng telepono. Walang humaharang sa kanila, dahil walang nagsabi sa Android na may VPN.

Ang ikalawang resulta ang mapanganib. Kung ibinabahagi ng chroot ang network namespace ng Android, na ginagawa nito bilang default, ang isang prosesong may sapat na pribilehiyo ay makakadagdag ng mga ruta at TUN interface na nakakaapekto sa buong telepono. Pagkatapos ay gumagana ang tunnel sa bawat app, kasama ang mga hindi mo intensyong i-route, at ang koneksyon ng telepono ay nakasalalay na ngayon sa isang daemon na walang pamamahala ng lifecycle, walang indicator ng koneksyon at walang always-on na patakaran.

Alin sa dalawa ang nakuha mo ay masasagot sa isang utos. Ihambing ang ip route sa loob ng chroot sa parehong utos mula sa isang shell ng Android sa labas. Ang magkatulad na output ay nangangahulugang ang chroot ay nasa namespace ng host: anumang pagbabago sa network na gagawin nito ay para sa buong telepono. Ang magkaibang output ay nangangahulugang gumawa ang launcher ng namespace para dito, at ang tunnel nito ay hindi nakikita ng Android ayon sa konstruksyon.

Ano ang binago ng chroot at ano ang hindi

Isang bagay lang ang ginagawa ng chroot system call: binabago nito ang direktoryong ginagamit sa pagresolba ng mga pangalan ng landas. Malinaw na sinasabi ng man page na hindi ito hangganan ng seguridad, at wala itong sinasabi tungkol sa mga interface, ruta o estado ng VPN. Lahat ng inaasahan ng mga tao mula sa isang Linux container — pribadong network stack, sinasala na filesystem, mga limitasyon ng resource — ay nagmumula sa iba pang mekanismong maaaring ginamit o hindi ng launcher.

Kaya ang mga pag-aangkin na iniisulate ng chroot ang isang VPN ay karaniwang sumasagot sa maling tanong. Ang kaugnay na tanong ay kung aling namespace tumatakbo ang proseso at kung aling SELinux domain ito nakakulong, at kapwa ay katangian ng paraan ng paglunsad, hindi ng salitang chroot.

Kailangan ng TUN ng tatlong bagay, at ang device node ay isa lamang

Ang tradisyonal na tunnel sa user space ay nangangailangan ng TUN device na mabubuksan, suporta ng kernel para sa device na iyon, at pahintulot na i-configure ang interface at mga ruta. Magkahiwalay ang mga ito, at ang paggawa ng pangalan ng landas sa ilalim ng /dev ay hindi mag-isa na tumutugon sa alinman sa kanila:

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

Sa Android, ang kernel ay karaniwang may naka-compile na suporta sa TUN, dahil ginagamit ito ng sariling VPN service ng platform, pero hindi ibig sabihin na maaaring gamitin ito ng iyong proseso. Ang configuration ng interface ay nangangailangan ng kakayahan sa network administration, at ang SELinux ang nagpapasya kung maaaring maabot ng proseso ang device node. Ang pagtanggi ay mukhang error sa pahintulot na walang malinaw na dahilan, at ang sagot ay nasa audit trail:

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

Hindi ito nilulutas ng root. Pinaghihigpitan ng SELinux ang mga prosesong tumatakbo bilang uid 0 tulad ng iba, kaya ang chroot na inilunsad mula sa root shell ay maaari pa ring tanggihan ng device na nakikita nito. Ang pagpatay sa enforcement para gumana ang lumang installer ay desisyon para sa buong telepono na may epekto lampas pa sa tunnel, at hindi ito pag-aayos ng lipas nang binary.

Bakit binabalewala ng mga app ng Android ang iyong tunnel

Ang sinusuportahang modelo ng Android ay isang VPN app na nagrerehistro sa pamamagitan ng VPN service ng platform, humihingi ng pahintulot ng user nang isang beses at tumatanggap ng file descriptor para sa tunnel nito. Pagkatapos ay itinuturo ng platform ang trapiko sa descriptor na iyon at ipinapatupad ang saklaw ng app na pinili ng user o administrator, kaya ang parehong mekanismo ay maaaring per-app, per-profile at pinagsama sa always-on at block-without-VPN na mga setting. Inilalarawan ng Android VPN development guide ang handshake na iyon, at ang mahalagang punto ay ito ay pagpaparehistro, hindi isang routing trick.

Ang daemon sa loob ng chroot ay hindi kailanman nagrerehistro. Walang consent dialog, walang key icon sa status bar, walang per-app na listahan ng isasama o ibubukod, at walang partisipasyon sa always-on na patakaran. Kaya patuloy na ginagamit ng mga app ang default na network, at ang tunnel ay nagdadala lamang ng ipinapadala ng shell mismo.

Hindi rin nakakatulong ang pagpunta sa kabilang direksyon. Ang pagtulak ng mga ruta sa namespace ng host ay humahawak ng lahat, kasama ang trapikong inaasahan ng platform na manatiling lokal, at ginagawa ito nang walang kontrol per-app at walang paraan para makita o bawiin ito ng user. Walang gitnang setting kung saan ang chroot daemon ay nagru-route ng trapiko para sa isang app lamang.

Ang binary compatibility ay hiwalay na pader

Kahit kawili-wili ang bahagi ng network, may sariling pangangailangan ang executable: arkitektura ng CPU, dynamic loader, C library, at ang mga pasilidad ng kernel na inaasahan nito. Gumagamit ang Android ng bionic kaysa glibc, at ang lumang binary na ginawa para sa desktop distribution ay maaaring mangailangan ng mga library na wala na sa device.

Ang symbolic na pag-link ng pangalan ng library file sa mas bagong bersyon ay hindi lumilikha ng ABI compatibility, at ang naka-archive na cryptographic library mula sa sampung taong gulang na package ay hindi maintained na component. Kung nakasalalay dito ang plano, ang plano ay patakbuhin ang hindi maintained na code na may network privileges sa telepono.

Patunayan ito sa konteksto ng Android at maglinis pagkatapos

Subukan ang talagang mahalaga sa iyo, mula sa panig na mahalaga: buksan ang partikular na app, maabot ang partikular na pribadong destinasyon, kumpirmahin kung aling resolver ang sumagot, pagkatapos ay idiskonekta ang tunnel at kumpirmahin ang dokumentadong pag-uugali. Ang resulta mula sa terminal sa loob ng chroot ay ebidensya tungkol sa execution context ng terminal na iyon at wala nang iba.

Kung binago mo ang mga ruta ng host habang nag-eeksperimento, ibalik ang mga ito at itala ang binago mo. Pagkatapos ay tingnan kung may naka-configure na always-on VPN ang telepono, dahil ang lumang eksperimentong nag-iwan ng panuntunan ay maaaring mukhang platform fault pagkalipas ng mga buwan.

Para sa tunay na pangangailangan ng remote access, gamitin ang sinusuportahang client ng serbisyo o isang aprubadong disenyo ng gateway. Ang tanong na dapat itanong ay hindi kung mapapatakbo ang root na installer, kundi kung dinadala ng sinusuportahang implementasyon ang mga app na kailangan mo sa hangganang nilayon mo, nang walang iniiwang pagbabagong may pribilehiyo na walang may-ari sa device.