Android chroot VPN: mengapa terowong berfungsi tetapi aplikasi mengabaikannya

Anda dapatkan distribusi Linux yang berjalan di bawah chroot pada telefon, pasang klien VPN di dalamnya, dan shell mengumumkan terowong sudah siap. Kemudian anda beralih ke pelayar dan trafik keluar melalui data mudah alih seolah-olah tiada apa yang berlaku. Atau sebaliknya: setiap aplikasi pada telefon kehilangan sambungan kerana klien memasang laluan lalai dalam ruang nama yang sebenarnya digunakan Android. Kedua-dua gejala ini datang daripada bahagian yang sama yang hilang, dan kedua-duanya bukan pepijat dalam klien VPN.

Shell kata bersambung, aplikasi tidak bersetuju

Hasil pertama ialah yang biasa. Terowong ruang pengguna yang dibuka dari chroot boleh menyelesaikan jabat tangan, mencetak statistik dan membawa trafik yang dijana oleh shell yang sama, sementara aplikasi Android terus menggunakan rangkaian lalai telefon. Tiada apa yang memintasnya, kerana tiada apa yang memberitahu Android bahawa VPN wujud.

Hasil kedua ialah yang berbahaya. Jika chroot berkongsi ruang nama rangkaian Android, yang memang berlaku secara lalai, proses dengan keistimewaan yang cukup boleh menambah laluan dan antara muka TUN yang menjejaskan seluruh telefon. Kemudian terowong itu berfungsi untuk setiap aplikasi, termasuk yang anda tidak niatkan untuk dilalui, dan sambungan telefon kini bergantung pada daemon yang tiada pengurusan kitaran hayat, tiada penunjuk sambungan dan tiada dasar sentiasa hidup.

Yang mana satu anda dapat boleh dijawab dengan satu arahan. Bandingkan ip route di dalam chroot dengan arahan yang sama dari shell Android di luarnya. Output yang sama bermakna chroot berada dalam ruang nama hos: apa-apa perubahan rangkaian yang dibuatnya meliputi seluruh telefon. Output yang berbeza bermakna pelancar mencipta ruang nama untuknya, dan terowongnya tidak kelihatan kepada Android secara semula jadi.

Apa yang chroot ubah dan apa yang tidak

Panggilan sistem chroot melakukan satu perkara: ia menukar direktori yang digunakan untuk penyelesaian nama laluan. Halaman man menyatakan dengan jelas bahawa ia bukan sempadan keselamatan, dan ia tidak menyebut apa-apa tentang antara muka, laluan atau keadaan VPN. Semua yang orang jangkakan daripada bekas Linux — tindanan rangkaian peribadi, sistem fail yang ditapis, had sumber — datang daripada mekanisme lain yang mungkin digunakan atau tidak oleh pelancar.

Itulah sebabnya dakwaan bahawa chroot mengasingkan VPN biasanya menjawab soalan yang salah. Soalan yang relevan ialah ruang nama mana proses itu berjalan dan domain SELinux mana ia terbatas, dan kedua-duanya ialah sifat cara ia dimulakan, bukan sifat perkataan chroot.

TUN perlukan tiga perkara, dan nod peranti hanyalah satu

Terowong ruang pengguna tradisional memerlukan peranti TUN yang boleh dibuka, sokongan kernel untuk peranti itu, dan kebenaran untuk mengkonfigurasi antara muka serta laluan. Itu keperluan berasingan, dan mencipta nama laluan di bawah /dev tidak memenuhi mana-mana daripadanya dengan sendirinya:

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

Pada Android kernel biasanya mempunyai sokongan TUN yang dikompil, kerana perkhidmatan VPN platform sendiri menggunakannya, tetapi itu tidak bermakna proses anda boleh menggunakannya. Konfigurasi antara muka memerlukan keupayaan pentadbiran rangkaian, dan SELinux menentukan sama ada proses itu boleh mencapai nod peranti itu sama sekali. Penafian kelihatan seperti ralat kebenaran tanpa sebab yang jelas, dan jawapannya ada dalam jejak audit:

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

Root tidak menyelesaikan ini. SELinux mengekang proses yang berjalan sebagai uid 0 sama seperti yang lain, jadi chroot yang dimulakan dari shell root masih boleh ditolak peranti yang dapat dilihatnya. Mematikan penguatkuasaan supaya pemasang lama berfungsi ialah keputusan seluruh telefon dengan akibat jauh melebihi terowong, dan ia bukan pembaikan untuk binari lama.

Mengapa aplikasi Android mengabaikan terowong anda

Model Android yang disokong ialah aplikasi VPN yang mendaftar melalui perkhidmatan VPN platform, meminta persetujuan pengguna sekali, dan menerima deskriptor fail untuk terowongnya. Platform kemudian menyalurkan trafik ke deskriptor itu dan menguatkuasakan skop aplikasi yang dipilih pengguna atau pentadbir, sebab itulah mekanisme yang sama boleh menjadi per-aplikasi, per-profil, dan digabungkan dengan tetapan sentiasa hidup serta blok-tanpa-VPN. Panduan pembangunan Android VPN menerangkan jabat tangan itu, dan perkara utama ialah ia pendaftaran, bukan helah penghalaan.

Daemon di dalam chroot tidak pernah mendaftar. Tiada dialog persetujuan, tiada ikon kunci di bar status, tiada senarai sertakan atau kecualikan per-aplikasi, dan tiada penyertaan dalam dasar sentiasa hidup. Oleh itu aplikasi terus menggunakan rangkaian lalai, dan terowong hanya membawa apa yang dihantar oleh shell itu sendiri.

Berjalan ke arah lain juga tidak membantu. Menolak laluan ke ruang nama hos menangkap segala-galanya, termasuk trafik yang platform jangkakan kekal setempat, dan ia berbuat demikian tanpa kawalan per-aplikasi dan tanpa cara untuk pengguna melihat atau membatalkannya. Tiada tetapan pertengahan di mana daemon chroot menghalakan trafik untuk satu aplikasi sahaja.

Keserasian binari ialah dinding berasingan

Walaupun bahagian rangkaian menarik, fail boleh laku mempunyai keperluannya sendiri: seni bina CPU, pemuat dinamik, pustaka C, dan kemudahan kernel yang dijangka. Android menggunakan bionic dan bukan glibc, dan binari lama yang dibina untuk distribusi desktop mungkin memerlukan pustaka yang tidak lagi wujud pada peranti.

Memautkan nama fail pustaka secara simbolik kepada versi yang lebih baharu tidak mencipta keserasian ABI, dan pustaka kriptografi yang diarkibkan daripada pakej berusia sedekad bukan komponen yang diselenggara. Jika rancangan bergantung pada itu, rancangannya ialah menjalankan kod tidak diselenggara dengan keistimewaan rangkaian pada telefon.

Buktikan dalam konteks Android dan bersihkan selepasnya

Uji apa yang sebenarnya anda pentingkan, dari sisi yang penting: buka aplikasi tertentu, capai destinasi peribadi tertentu, sahkan penyelesai mana yang menjawab, kemudian putuskan terowong dan sahkan tingkah laku yang didokumenkan. Hasil daripada terminal di dalam chroot ialah bukti tentang konteks pelaksanaan terminal itu sahaja dan tidak lebih.

Jika anda mengubah laluan hos semasa bereksperimen, pulihkannya dan catat apa yang anda ubah. Kemudian semak sama ada telefon mempunyai VPN sentiasa hidup yang dikonfigurasi, kerana eksperimen lama yang meninggalkan peraturan boleh kelihatan seperti kerosakan platform berbulan-bulan kemudian.

Untuk keperluan akses jauh yang sebenar, gunakan klien yang disokong oleh perkhidmatan atau reka bentuk gerbang yang diluluskan. Soalan yang patut ditanya bukanlah sama ada pemasang berakar boleh dibuat berjalan, tetapi sama ada pelaksanaan yang disokong membawa aplikasi yang anda perlukan merentasi sempadan yang anda niatkan, tanpa meninggalkan perubahan istimewa tanpa pemilik pada peranti.