Tidak, aplikasi VpnService tidak boleh menghidupkan VPN telefon

Andaian yang salah ialah aplikasi VpnService menukar suis sistem dan selepas itu telefon dilindungi. Apa yang sebenarnya berlaku lebih sempit: aplikasi meminta persetujuan, membina antara muka, membaca dan menulis paket melalui deskriptor fail, dan mengembalikan antara muka apabila berhenti. Hanya satu terowong sebegitu boleh hidup pada satu masa, dan sistem boleh mengambilnya tanpa bertanya. Sebahagian besar tingkah laku mengelirukan yang orang salahkan pada protokol datang daripada model pemilikan itu.

Anggap setiap peralihan kitaran hayat sebagai bahagian reka bentuk, bukan kes tepi.

Mitos: aplikasi menghidupkan VPN telefon

Aliran bermula dengan VpnService.prepare(), yang mengembalikan Intent yang pengguna mesti terima, dan berterusan dengan establish(), yang selepas itu masih boleh gagal atas sebab yang tidak dikawal oleh aplikasi. Membina terowong kedua menyahaktifkan antara muka pertama dan menggantikan pemberitahuan sistem. Tidak di mana-mana dalam urutan itu aplikasi memiliki suis untuk seluruh peranti; ia memiliki deskriptor yang diberikan kepadanya dan paket yang mendarat di atasnya. Malah pemberitahuan kekal milik sistem, bukan reka bentuk aplikasi.

Kerana antara muka diberikan dan bukan dirampas, klien lain boleh mengambil tempat itu pada bila-bila masa. Aplikasi mengetahui perkara itu melalui panggilan balik, bukan melalui nilai pulangan.

Penghentian paksa aplikasi kelihatan dalam panel pemberitahuan atas sebab yang sama: sistem melaporkan apa yang diberikannya, bukan apa yang aplikasi pilih untuk dipaparkan.

Mitos: persetujuan diberikan sekali

Apabila sistem menyerahkan terowong kepada klien lain, ia menghantar transaksi pembatalan pada binder yang dikembalikan kelas asas daripada onBind(). Aplikasi yang menggantikan binder itu dengan miliknya sendiri mesti menyalurkan transaksi pembatalan itu sendiri, jika tidak VpnService.onRevoke() tidak akan tercetus dan perkhidmatan terus menulis ke deskriptor yang tidak lagi wujud. Persetujuan juga boleh ditarik balik oleh pengguna, dan sistem boleh menghentikan perkhidmatan semasa mula semula atau penyambungan semula sentiasa hidup.

Mengendalikannya ialah kerja konkrit dan bukan satu baris log: berhenti membaca deskriptor, tutupnya, kosongkan bendera bersambung dan beritahu pengguna dalam keadaan mana mereka berada. Kemudian tentukan sama ada aplikasi perlu membina semula, bertanya lagi atau menunggu, kerana dalam konfigurasi sentiasa hidup sistem boleh mengembalikan perkhidmatan itu sendiri.

Aplikasi yang menganggap pembatalan sebagai pengecualian dan bukan keadaan akan melaporkan bersambung sedangkan setiap paket yang ditulisnya dibuang, dan itu adalah mod kegagalan terburuk yang mungkin bagi alat privasi.

Mitos: antara muka menapis trafik untuk anda

Apa yang tiba ialah IP mentah. Menangkap atau menapis bermakna menghuraikan pengepala IP, TCP, UDP dan IPv6, menjejak aliran dan menulis balasan kembali ke deskriptor, yang menjadikan aplikasi tangkapan sebagai tindanan rangkaian kecil dan bukan kemudahan sistem. protect() wujud supaya soket pengangkutan aplikasi itu sendiri memintas terowongnya dan bukannya menangkap dirinya sendiri, dan ia mengembalikan boolean yang wajar diperiksa pada setiap soket yang dicipta selepas terowong itu naik.

Senarai aplikasi yang dibenarkan dan dilarang dalam pembina menentukan trafik siapa yang masuk ke antara muka. Ia tidak memberi akses kepada muatan di luar paket IP yang dibawa antara muka, dan tiada API mendedahkan terowong klien lain atau menyenaraikan profil VPN sistem. Keupayaan rangkaian boleh mengatakan sesuatu rangkaian ialah pengangkutan VPN, tetapi bukan milik siapa terowong itu.

Itulah sebabnya soalan status tentang aplikasi lain mendapat jawapan bercanggah: maklumat itu memang tidak didedahkan kepada proses anda.

Apa yang sebenarnya dituntut kitaran hayat

Jejaki keadaan yang anda kawal: sedia, terbina, dibatalkan, dihentikan. Penyambungan semula sepatutnya pembongkaran diikuti pembinaan, dengan satu pemilik untuk deskriptor dan soket pengangkutan, kerana dua komponen yang bersaing untuk membina akan berebut satu ruang yang tersedia. Permulaan latar belakang terhad pada Android moden, jadi siaran but bukan jaminan; gunakan perkhidmatan latar hadapan dengan pemberitahuannya di tempat tahap API mengizinkan.

Log peralihan itu dan bukan hanya keadaan akhir, dan kekalkan mesin keadaan cukup kecil untuk menguji setiap laluan. Keadaan yang tidak dapat anda capai dalam ujian ialah keadaan yang akan anda temui di lapangan tanpa log.

Uji kitaran hayat pada peranti

Emulator boleh memalsukan kesambungan tetapi bukan laluan persetujuan dan pembatalan secara meyakinkan, jadi jalankan ini pada peranti sebenar dengan klien VPN kedua dipasang untuk mencuri ruang itu.

adb shell dumpsys connectivity | grep -i -A3 vpn
adb shell dumpsys activity services | grep -i -A2 vpnservice
adb logcat -s VpnService:V AndroidRuntime:E
adb shell am force-stop com.example.vpnapp

Mulakan terowong, sahkan pemberitahuan dan antara muka, kemudian sambungkan klien lain dan perhatikan sama ada panggilan balik pembatalan berjalan dan keadaan dikosongkan. Hentikan aplikasi secara paksa dan semak sama ada sesuatu masih melaporkan deskriptor yang hidup.

Ulang urutan itu selepas mula semula sentiasa hidup, kerana laluan itu berbeza daripada sambungan yang dimulakan pengguna. Apa yang anda cari bukan ikon hijau tetapi bukti bahawa aplikasi berhenti menggunakan deskriptor yang bukan lagi miliknya.