VPN Android tanpa root: siapa pemilik persetujuan, laluan dan sekatan

Root bukanlah yang membolehkan aplikasi VPN Android membawa trafik, menyekat kebocoran atau bertahan selepas but semula. Orang ramai merumuskan semua itu sebagai „aplikasi mempunyai kebenaran VPN“, yang menyembunyikan tiga mekanisme berasingan: persetujuan daripada pengguna, antara muka paket yang sistem wujudkan, dan dasar sekatan platform yang bukan milik aplikasi untuk menentukan. Menyemak reka bentuk VPN Android bermaksud bertanya pada yang mana antara ketiga-tiganya sesuatu dakwaan benar-benar bersandar, kerana setiap satu mempunyai pemilik dan mod kegagalan yang berbeza.

Persetujuan datang melalui aktiviti sistem

VpnService.prepare() tidak memberikan apa-apa. Ia mengembalikan intent kepada aktiviti persetujuan sistem apabila persetujuan tiada, dan aplikasi melancarkan dialog itu supaya pengguna boleh meluluskan perkhidmatan. Memulakan proses aplikasi itu sendiri, menambah kebenaran pada manifes, atau memaparkan skrin „dayakan VPN“ tersuai tidak mencipta kebenaran itu.

Kebenaran itu juga terhad skopnya. Ia milik pakej dalam profil pengguna, jadi salinan peribadi dan salinan kerja ialah keputusan berasingan, dan pemilik peranti boleh menyediakan profil terurus secara berbeza daripada profil peribadi. Jika dialog tidak pernah muncul dan prepare() mengembalikan null, persetujuan sudah wujud untuk pakej itu dalam profil tersebut; itu bukan bukti aplikasi boleh dipercayai, hanya bukti kebenaran itu ada.

Antara muka ialah permintaan yang sistem penuhi

Selepas persetujuan, aplikasi menerangkan apa yang dikehendakinya dengan VpnService.Builder: alamat, laluan, pelayan DNS, MTU dan, jika disokong, aplikasi yang hendak disertakan atau dikecualikan. establish() meminta sistem mencipta antara muka terowong dan menyalurkan trafik yang sepadan ke dalamnya. Sistem memiliki keputusan penghalaan; aplikasi menerima deskriptor fail dan kemudian mesti melakukan sesuatu yang berguna dengan paket tersebut.

Jadual itu ialah seni bina di satu tempat. Aplikasi mengambil bahagian dalam pengendalian paket; ia tidak memiliki antara muka, jadual penghalaan atau bilangan perkhidmatan yang boleh berjalan.

Soket terowong mesti terlepas dari terowongnya sendiri

Sambungan yang membawa trafik tersulit itu sendiri ialah soket. Jika ia dihalakan semula ke antara muka yang baru dicipta aplikasi, terowong bergantung pada terowong dan tersekat. VpnService.protect() mengikat soket itu kepada rangkaian di bawahnya supaya ia memintas tangkapan, dan itulah sebabnya klien yang betul melindungi soket luarnya sebelum jabat tangan pertama.

adb shell dumpsys connectivity | grep -i -A5 vpn
adb shell settings get global always_on_vpn_app
adb shell settings get global always_on_vpn_lockdown

Perintah ini menunjukkan rangkaian VPN yang dipasang, pakej sentiasa aktif dan sama ada kunci ditetapkan. Semuanya pemerhatian baca sahaja: jika nilai tidak sepadan dengan apa yang didakwa reka bentuk, dakwaan itu tentang antara muka aplikasi, bukan keadaan sistem.

Sekatan mungkin milik platform

Android mendokumenkan dasar yang menyekat sambungan yang tidak menggunakan VPN. Penguatkuasaan itu ialah kontrak platform, bukan aplikasi yang mencuba semula sambungan dalam gelung. Suis itu terletak dalam tetapan VPN peranti sebagai Sekat sambungan tanpa VPN, dan pada peranti terurus pemilik boleh menghidupkannya untuk seluruh profil. Perbezaan ini penting apabila menilai dakwaan pemasaran: klien boleh memaparkan ikon mangga dan menyambung semula secara agresif sementara trafik langsung masih mungkin, atau aplikasi yang dilindungi boleh kekal luar talian kerana sistem menguatkuasakan kunci.

Ikon mangga dilukis oleh aplikasi, jadi ia hanya membuktikan aplikasi percaya ia bersambung. Sama ada aplikasi lain kehilangan akses rangkaiannya ditentukan platform, jadi pemeriksaan yang berguna ialah melihat aplikasi itu gagal semasa terowong aktif.

Label „sentiasa aktif“ dari kedai aplikasi juga tidak menggantikan kontrak itu. Sentiasa aktif dan kunci ialah tetapan peranti, selalunya digunakan oleh pemilik peranti, dan tingkah lakunya untuk aplikasi yang dikecualikan ditentukan platform. Baca tetapan, bukan lencana.

Empat soalan untuk semakan reka bentuk

Pertama, siapa yang bersetuju: pakej mana, profil mana, dan adakah pengguna atau dasar peranti terurus? Kedua, apa yang diminta aplikasi: laluan mana, keluarga alamat mana, aplikasi mana yang disertakan atau dikecualikan? Ketiga, apa yang berlaku apabila terowong tidak tersedia: sistem menyekat atau trafik kembali ke rangkaian di bawahnya? Keempat, apa yang aplikasi lakukan dengan paket yang diterimanya?

Soalan keempat ialah yang tidak dapat dijawab model kebenaran. Persetujuan dan antara muka TUN membuktikan aplikasi boleh menerima trafik, bukan bahawa ia menyulitkannya, mengesahkan rakan atau pulih dengan bersih. Itu sifat pelaksanaan, dan di situlah semakan yang jujur menghabiskan masanya.

Permintaan root yang tidak perlu tidak menjadi sah dengan menamakan hasilnya kill switch, dan dialog persetujuan bukan audit keselamatan. Kekalkan ketiga-tiga kebenaran berasingan dan setiap dakwaan menjadi boleh disemak.