VPN Android tanpa root: siapa pemilik persetujuan, rute, dan pemblokiran

Root bukanlah yang memungkinkan aplikasi VPN Android mengangkut lalu lintas, memblokir kebocoran, atau bertahan setelah reboot. Orang merangkum semua itu sebagai „aplikasi punya izin VPN“, yang menyembunyikan tiga mekanisme terpisah: persetujuan dari pengguna, antarmuka paket yang dibuat sistem, dan kebijakan pemblokiran platform yang bukan wewenang aplikasi untuk menetapkannya. Meninjau desain VPN Android berarti menanyakan pada yang mana dari ketiganya sebuah klaim benar-benar bersandar, karena masing-masing punya pemilik dan mode kegagalan berbeda.

Persetujuan datang melalui aktivitas sistem

VpnService.prepare() tidak memberikan apa pun. Ia mengembalikan intent ke aktivitas persetujuan sistem saat persetujuan belum ada, dan aplikasi meluncurkan dialog itu agar pengguna menyetujui layanan. Menjalankan proses aplikasi sendiri, menambahkan izin ke manifes, atau menampilkan layar „aktifkan VPN“ khusus tidak menciptakan izin tersebut.

Izin itu juga dibatasi cakupannya. Ia milik sebuah paket dalam profil pengguna, jadi salinan pribadi dan salinan kerja adalah keputusan terpisah, dan pemilik perangkat dapat menyiapkan profil terkelola secara berbeda dari profil pribadi. Jika dialog tidak pernah muncul dan prepare() mengembalikan null, persetujuan sudah ada untuk paket itu di profil tersebut; itu bukan bukti aplikasi tepercaya, hanya bahwa izinnya sudah ada.

Antarmuka adalah permintaan yang dipenuhi sistem

Setelah persetujuan, aplikasi menjelaskan apa yang diinginkannya dengan VpnService.Builder: alamat, rute, server DNS, MTU dan, jika didukung, aplikasi yang disertakan atau dikecualikan. establish() meminta sistem membuat antarmuka terowongan dan mengarahkan lalu lintas yang cocok ke dalamnya. Sistem memiliki keputusan perutean; aplikasi menerima deskriptor berkas dan kemudian harus melakukan sesuatu yang berguna dengan paket.

Tabel itu adalah arsitekturnya di satu tempat. Aplikasi berperan serta dalam penanganan paket; ia tidak memiliki antarmuka, tabel perutean, atau jumlah layanan yang boleh berjalan.

Soket terowongan harus lolos dari terowongannya sendiri

Koneksi yang mengangkut lalu lintas terenkripsi itu sendiri adalah soket. Jika dialihkan kembali ke antarmuka yang baru dibuat aplikasi, terowongan bergantung pada terowongan dan macet. VpnService.protect() mengikat soket itu ke jaringan di bawahnya agar melewati penangkapan, dan itulah sebabnya klien yang benar 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 menampilkan jaringan VPN yang terpasang, paket selalu aktif, dan apakah penguncian diatur. Semuanya pengamatan hanya-baca: jika nilainya tidak cocok dengan yang diklaim desain, klaim itu tentang antarmuka aplikasi, bukan tentang keadaan sistem.

Pemblokiran bisa menjadi milik platform

Android mendokumentasikan kebijakan yang memblokir koneksi yang tidak memakai VPN. Penegakan itu adalah kontrak platform, bukan aplikasi yang mengulang percobaan koneksi dalam perulangan. Sakelarnya ada di pengaturan VPN perangkat sebagai Blokir koneksi tanpa VPN, dan pada perangkat terkelola pemilik dapat menyalakannya untuk seluruh profil. Perbedaan ini penting saat menilai klaim pemasaran: klien dapat menampilkan ikon gembok dan menyambung ulang secara agresif sementara lalu lintas langsung masih mungkin, atau aplikasi yang tercakup dapat tetap offline karena sistem menegakkan penguncian.

Ikon gembok digambar oleh aplikasi, jadi itu hanya membuktikan aplikasi percaya dirinya tersambung. Apakah aplikasi lain kehilangan akses jaringannya diputuskan platform, jadi pemeriksaan yang berguna adalah melihat aplikasi itu gagal saat terowongan aktif.

Label „selalu aktif“ dari toko aplikasi juga tidak menggantikan kontrak itu. Selalu aktif dan penguncian adalah pengaturan perangkat, sering diterapkan pemilik perangkat, dan perilakunya bagi aplikasi yang dikecualikan ditentukan platform. Bacalah pengaturannya, bukan lencananya.

Empat pertanyaan untuk tinjauan desain

Pertama, siapa yang menyetujui: paket mana, profil mana, dan apakah pengguna atau kebijakan perangkat terkelola? Kedua, apa yang diminta aplikasi: rute mana, keluarga alamat mana, aplikasi mana yang disertakan atau dikecualikan? Ketiga, apa yang terjadi saat terowongan tidak tersedia: sistem memblokir, atau lalu lintas mundur ke jaringan di bawahnya? Keempat, apa yang dilakukan aplikasi dengan paket yang diterimanya?

Pertanyaan keempat adalah yang tidak dapat dijawab model izin. Persetujuan dan antarmuka TUN membuktikan aplikasi dapat menerima lalu lintas, bukan bahwa ia mengenkripsinya, mengautentikasi rekan, atau pulih dengan bersih. Itu sifat implementasi, dan di situlah tinjauan yang jujur menghabiskan waktunya.

Permintaan root yang tidak perlu tidak menjadi sah dengan menyebut hasilnya kill switch, dan dialog persetujuan bukan audit keamanan. Jaga ketiga izin tetap terpisah dan setiap klaim menjadi dapat diperiksa.