VPN dalam chroot di Android: mengapa tunnel bekerja dan aplikasi mengabaikannya

Anda menjalankan distribusi Linux di dalam chroot pada ponsel, memasang klien VPN di dalamnya, dan shell mengumumkan tunnel selesai. Lalu Anda beralih ke peramban dan lalu lintas keluar lewat data seluler seolah tidak terjadi apa-apa. Atau sebaliknya: setiap aplikasi di ponsel kehilangan konektivitas karena klien menambahkan rute bawaan di ruang nama yang benar-benar dipakai Android. Kedua gejala itu berasal dari satu bagian yang hilang, dan tidak satu pun merupakan bug klien VPN.

Shell bilang tersambung, aplikasi tidak setuju

Hasil pertama yang umum. Tunnel ruang pengguna yang dibuka dari chroot dapat menyelesaikan handshake, mencetak statistiknya, dan membawa lalu lintas yang dihasilkan shell yang sama, sementara aplikasi Android tetap memakai jaringan bawaan ponsel. Tidak ada yang mencegatnya, karena tidak ada yang memberi tahu Android bahwa VPN ada.

Hasil kedua yang berbahaya. Jika chroot berbagi ruang nama jaringan Android, yang memang bawaannya, proses dengan hak istimewa cukup dapat menambahkan rute dan antarmuka TUN yang memengaruhi seluruh ponsel. Maka tunnel bekerja untuk setiap aplikasi, termasuk yang tidak ingin Anda rutekan, dan konektivitas ponsel kini bergantung pada daemon tanpa pengelolaan siklus hidup, tanpa indikator koneksi, dan tanpa kebijakan selalu aktif.

Hasil mana yang Anda dapat bisa dijawab dengan satu perintah. Bandingkan ip route di dalam chroot dengan perintah yang sama dari shell Android di luar. Keluaran identik berarti chroot berada di ruang nama host: setiap perubahan jaringan yang dilakukannya berlaku untuk seluruh ponsel. Keluaran berbeda berarti peluncur membuat ruang nama untuknya, dan tunnel-nya tak terlihat oleh Android secara konstruksi.

Apa yang diubah chroot dan apa yang tidak

Panggilan sistem chroot melakukan satu hal: mengubah direktori yang dipakai untuk resolusi jalur. Halaman man menyatakan tegas itu bukan batas keamanan, dan tidak mengatakan apa pun tentang antarmuka, rute, atau status VPN. Semua yang orang harapkan dari kontainer Linux — tumpukan jaringan pribadi, sistem berkas tersaring, batas sumber daya — berasal dari mekanisme lain yang mungkin dipakai peluncur atau tidak.

Karena itu klaim bahwa chroot mengisolasi VPN biasanya menjawab pertanyaan yang salah. Pertanyaan yang relevan adalah di ruang nama mana proses berjalan dan di domain SELinux mana ia dibatasi, dan keduanya sifat dari bagaimana ia dijalankan, bukan dari kata chroot.

TUN butuh tiga hal, dan simpul perangkat hanya satu

Tunnel ruang pengguna tradisional butuh perangkat TUN yang bisa dibukanya, dukungan kernel untuk perangkat itu, dan izin mengonfigurasi antarmuka serta rute. Itu syarat terpisah, dan membuat nama jalur di bawah /dev tidak memenuhi satu pun dengan sendirinya:

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

Di Android dukungan TUN biasanya dikompilasi ke dalam kernel, karena layanan VPN platform sendiri memakainya, tetapi itu tidak berarti proses Anda boleh memakainya. Konfigurasi antarmuka memerlukan kemampuan administrasi jaringan, dan SELinux memutuskan apakah proses dapat mencapai simpul perangkat sama sekali. Penolakan tampak seperti kesalahan izin tanpa sebab jelas, dan jawabannya ada di jejak audit:

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

Root tidak menyelesaikannya. SELinux membatasi proses dengan uid 0 sama seperti yang lain, jadi chroot yang dijalankan dari shell root masih bisa ditolak untuk perangkat yang dilihatnya. Mematikan penegakan agar pemasang lama berfungsi adalah keputusan untuk seluruh ponsel dengan akibat jauh melampaui tunnel, dan itu bukan perbaikan untuk biner usang.

Mengapa aplikasi Android mengabaikan tunnel Anda

Model yang didukung Android adalah aplikasi VPN yang mendaftar melalui layanan VPN platform, meminta persetujuan pengguna sekali, dan menerima deskriptor berkas untuk tunnel-nya. Platform lalu mengarahkan lalu lintas ke deskriptor itu dan menegakkan cakupan aplikasi yang dipilih pengguna atau administrator, karena itu mekanisme yang sama bisa per aplikasi, per profil, dan digabung dengan pengaturan selalu aktif dan blokir tanpa VPN. Panduan pengembangan VPN Android menjelaskan handshake itu, dan poin kuncinya adalah ini pendaftaran, bukan trik perutean.

Daemon di dalam chroot tidak pernah mendaftar. Tidak ada dialog persetujuan, tidak ada ikon kunci di bilah status, tidak ada daftar sertakan atau kecualikan per aplikasi, dan tidak ada partisipasi dalam kebijakan selalu aktif. Karena itu aplikasi tetap memakai jaringan bawaan, dan tunnel hanya membawa apa yang dikirim shell itu sendiri.

Arah sebaliknya juga tidak menolong. Mendorong rute ke ruang nama host menangkap semuanya, termasuk lalu lintas yang diharapkan platform tetap lokal, dan melakukannya tanpa kendali per aplikasi dan tanpa cara bagi pengguna melihat atau mencabutnya. Tidak ada pengaturan tengah di mana daemon chroot merutekan lalu lintas hanya satu aplikasi.

Kompatibilitas biner adalah dinding terpisah

Bahkan ketika sisi jaringan menarik, berkas yang dapat dieksekusi punya syaratnya sendiri: arsitektur CPU, pemuat dinamis, pustaka C, dan kemampuan kernel yang diharapkannya. Android memakai bionic, bukan glibc, dan biner lama yang dibangun untuk distribusi desktop mungkin memerlukan pustaka yang sudah tidak ada di perangkat.

Menautkan nama berkas pustaka ke versi yang lebih baru tidak menciptakan kompatibilitas ABI, dan pustaka kriptografi terarsip dari paket berumur sepuluh tahun bukan komponen yang dipelihara. Jika rencana bergantung pada itu, rencananya adalah menjalankan kode tanpa pemeliharaan dengan hak istimewa jaringan di ponsel.

Buktikan dalam konteks Android dan bersihkan setelahnya

Uji apa yang benar-benar penting bagi Anda, dari sisi yang penting: buka aplikasi tertentu, capai tujuan privat tertentu, pastikan resolver mana yang menjawab, lalu putuskan tunnel dan pastikan perilaku yang didokumentasikan. Hasil dari terminal di dalam chroot adalah bukti tentang konteks eksekusi terminal itu dan tidak lebih.

Jika Anda mengubah rute host selama percobaan, kembalikan dan catat apa yang diubah. Lalu periksa apakah ponsel memiliki VPN selalu aktif, karena percobaan lama yang meninggalkan aturan bisa tampak seperti kerusakan platform berbulan-bulan kemudian.

Untuk kebutuhan akses jarak jauh sungguhan, gunakan klien resmi layanan atau desain gerbang yang disetujui. Pertanyaan yang layak diajukan bukan apakah pemasang root bisa dijalankan, melainkan apakah implementasi yang didukung membawa aplikasi yang Anda butuhkan melewati batas yang dimaksud, tanpa meninggalkan perubahan istimewa tanpa pemilik di perangkat.