Aplikasi Android menolak berjalan lewat VPN: lapisan mana yang memutuskan

Ketika aplikasi Android berhenti bekerja tepat saat terowongan naik, tiga hal berbeda bisa bertanggung jawab, dan semuanya menghasilkan kegagalan yang tampak serupa. Aplikasi bisa membaca keadaan jaringan ponsel itu sendiri lalu menolak secara lokal. Server bisa mengklasifikasikan alamat asal Anda lalu menolaknya. Atau penolakan itu sama sekali tidak ada hubungannya dengan VPN. Urutan di bawah mengumpulkan bukti sebelum mengubah apa pun, karena mengganti jalan keluar adalah langkah termahal dan yang paling kecil kemungkinannya menolong bila pemeriksaannya lokal.

Langkah 1: cari tahu kapan aplikasi menolak

Waktu adalah pembeda pertama. Kosongkan buffer log, reproduksi kegagalan, dan lihat apa yang dilakukan aplikasi sebelum mengeluh:

adb logcat -c
# reproduce the failure in the app
adb logcat -d | grep -iE 'vpn|network|connect|http' | tail -60

Jika aplikasi menolak sebelum ada permintaan keluar yang dicoba, Anda melihat keputusan lokal. Jika aplikasi terhubung, mengirim sesuatu, lalu menampilkan kesalahan, penolakan datang dari sisi lain. Jika aplikasi gagal sama persis saat terowongan mati, VPN tidak pernah menjadi variabelnya.

Perlakukan waktu itu sebagai bukti, bukan sebagai pembenaran. Aplikasi bisa memutar ulang respons yang tersimpan di cache, dan permintaan latar belakang mungkin sudah berhasil atau gagal sebelum Anda melihat. Catat stempel waktu permintaan terakhir yang berhasil dan kesalahannya, bukan hanya saat pesan itu muncul.

Langkah 2: baca pandangan ponsel sendiri atas jaringan

Android mengekspos status VPN sebagai kemampuan jaringan, jadi aplikasi tidak perlu daftar penyedia komersial untuk menyadari bahwa terowongan aktif. Aplikasi bertanya kepada layanan konektivitas jaringan mana yang sedang aktif, dan jawabannya memuat bit transport VPN:

val cm = context.getSystemService(ConnectivityManager::class.java)
val caps = cm.getNetworkCapabilities(cm.activeNetwork)
val onVpn = caps?.hasTransport(NetworkCapabilities.TRANSPORT_VPN) == true

Pemeriksaan itu lokal dan murah, dan menjelaskan satu kelas laporan “aplikasi ini tidak jalan lewat VPN” tanpa klasifikasi jarak jauh sama sekali. Apa yang bisa dilihat aplikasi tetap bergantung pada konteks jaringannya sendiri, jadi jangan menganggap setiap aplikasi memeriksa setiap profil di perangkat.

Dari stasiun kerja Anda bisa melihat keadaan yang sama pada perangkat uji dengan adb shell dumpsys connectivity dan dengan mencari entri jaringan VPN. Bandingkan satu proses dengan terowongan naik dan satu proses dengan terowongan turun, lalu simpan kedua keluarannya.

Langkah 3: baca apa yang sebenarnya dilihat server

Pengamat lainnya adalah layanan. Ia melihat alamat sumber yang datang, dan bisa bertindak atas alamat itu, jaringan hosting di belakangnya, wilayah, operator, atau sinyal yang terkait dengan akun dan perangkat. Tidak satu pun dari itu merupakan identitas unik, dan pengalamatan bersama membuat pemblokiran sampingan menjadi normal: satu alamat yang dibatasi bisa menjatuhkan pengguna tak terkait di belakang terjemahan yang sama.

Dapatkan alamat lewat jalur yang sama dengan yang dipakai aplikasi, bukan dari peramban di laptop. Di ponsel, permintaan sederhana ke layanan gema alamat memperlihatkan apa yang diterima sisi jauh, dan membandingkannya dengan permintaan lewat jaringan seluler memberi tahu Anda apakah alamatnya berubah sama sekali.

Jika aplikasi bekerja lewat jaringan seluler dan gagal lewat terowongan dengan akun yang sama, penolakan ada di ujung jauh atau di kebijakan aplikasi itu sendiri. Jika gagal pada keduanya, VPN bukan pembedanya dan Anda sebaiknya berhenti menguji titik akhir.

Langkah 4: cocokkan bukti dengan salah satu dari tiga putusan

Tiga kombinasi mencakup hampir semua laporan. Penolakan tanpa upaya keluar saat terowongan aktif mengarah ke pemeriksaan transport lokal. Permintaan yang keluar dan kembali dengan kesalahan, waktu tunggu habis pada host tertentu, atau pesan wilayah mengarah ke sisi jauh. Kegagalan yang berulang lewat jaringan seluler tanpa terowongan mengarah ke akun, versi aplikasi, atau kebijakan layanan itu sendiri, dan tidak ada perubahan VPN yang akan menggesernya.

Tuliskan putusan bersama bukti yang menghasilkannya. Nilai langkah ini adalah ia menghentikan lingkar di mana seseorang mengganti node keluar empat kali untuk memperbaiki pemeriksaan yang berjalan di ponsel itu sendiri.

Ini juga menjaga klaim tetap jujur. Hosting sendiri mengubah titik akhir dan jalan keluar internetnya; itu tidak membuat Android lupa bahwa jaringan VPN aktif, dan tidak menjamin penerimaan oleh layanan yang mengklasifikasikan alamat. Filter lokal bisa terpicu pada jaringan VPN milik Anda sendiri sama mudahnya seperti pada jaringan komersial.

Langkah 5: tempuh jalur yang didukung dan verifikasi

Mulai dari kebijakan produk yang terdokumentasi dan pemilik dukungannya. Kirim versi klien, pesan persisnya, dan jendela kegagalan yang sempit; jangan kirim tangkapan lalu lintas penuh atau kredensial hanya untuk membuktikan bahwa kesalahan itu ada.

Jika layanan mengizinkan akses langsung dan kebijakan perangkat mengizinkannya, pengecualian per aplikasi adalah mekanisme yang didukung, dan itu sengaja mengeluarkan aplikasi tersebut dari terowongan alih-alih menyembunyikan terowongannya. Lalu lintas aplikasi kemudian keluar pada jalurnya sendiri, yang merupakan keputusan kebijakan yang harus diambil seseorang. Dalam konfigurasi yang memblokir tanpa VPN, aplikasi yang dikecualikan bisa sekadar kehilangan konektivitas, jadi uji kombinasi itu sebelum menjanjikan bahwa ia bekerja.

Setelah setiap perubahan, ulangi uji waktu langkah satu, pastikan aplikasi bekerja, dan pastikan setiap aplikasi lain masih memakai terowongan. Lalu pulihkan konfigurasi sebelumnya dan periksa apakah kegagalannya kembali, karena perbaikan yang tidak bisa Anda reproduksi adalah kebetulan yang akan Anda temui lagi.