Apl Android enggan berjalan melalui VPN: lapisan mana yang menentukan

Apabila apl Android berhenti berfungsi pada saat terowong naik, tiga perkara berbeza boleh bertanggungjawab, dan semuanya menghasilkan kegagalan yang kelihatan serupa. Apl mungkin membaca keadaan rangkaian telefon itu sendiri lalu menolak secara setempat. Pelayan mungkin mengelaskan alamat tempat anda datang lalu menolaknya. Atau penolakan itu langsung tidak berkaitan dengan VPN. Urutan di bawah mengumpul bukti sebelum mengubah apa-apa, kerana menukar pintu keluar ialah langkah paling mahal dan paling kurang mungkin membantu jika semakan itu setempat.

Langkah 1: ketahui bila apl menolak

Masa ialah pembeza pertama. Kosongkan penimbal log, hasilkan semula kegagalan dan lihat apa yang apl lakukan sebelum ia merungut:

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

Jika apl menolak sebelum sebarang permintaan keluar dicuba, anda melihat keputusan setempat. Jika ia bersambung, menghantar sesuatu dan kemudian memaparkan ralat, penolakan datang dari sebelah sana. Jika apl gagal sama apabila terowong dimatikan, VPN tidak pernah menjadi pemboleh ubah.

Anggap masa itu sebagai bukti, bukan pengesahan. Apl boleh memainkan semula respons yang dicache, dan permintaan latar belakang mungkin telah berjaya atau gagal sebelum anda melihat. Catat cap masa permintaan terakhir yang berjaya dan ralat itu, bukan hanya saat mesej muncul.

Langkah 2: baca pandangan telefon sendiri tentang rangkaian

Android mendedahkan keadaan VPN sebagai keupayaan rangkaian, jadi apl tidak memerlukan senarai penyedia komersial untuk perasan bahawa terowong aktif. Ia bertanya kepada perkhidmatan kesambungan rangkaian apa rangkaian semasa, dan jawapannya mengandungi bit pengangkutan VPN:

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

Semakan itu setempat dan murah, dan ia menjelaskan seluruh kelas laporan “apl ini tidak berfungsi melalui VPN” tanpa sebarang pengelasan jauh. Apa yang apl boleh lihat masih bergantung pada konteks rangkaiannya sendiri, jadi jangan anggap setiap apl memeriksa setiap profil pada peranti.

Dari stesen kerja anda boleh melihat keadaan yang sama pada peranti ujian dengan adb shell dumpsys connectivity dan dengan mencari entri rangkaian VPN. Bandingkan satu larian dengan terowong naik dengan satu larian dengan terowong turun, dan simpan kedua-dua keluaran.

Langkah 3: baca apa yang pelayan sebenarnya lihat

Pemerhati yang satu lagi ialah perkhidmatan. Ia melihat alamat sumber yang tiba, dan ia mungkin bertindak atas alamat itu, rangkaian hosting di belakangnya, wilayah, pembawa atau isyarat yang terikat pada akaun dan peranti. Tiada satu pun daripadanya identiti unik, dan pengalamatan bersama menjadikan sekatan sampingan perkara biasa: satu alamat terhad boleh menjatuhkan pengguna tidak berkaitan di belakang terjemahan yang sama.

Dapatkan alamat itu melalui laluan yang sama seperti yang digunakan oleh apl, bukan dari pelayar pada komputer riba. Pada telefon, permintaan mudah kepada perkhidmatan gema alamat menunjukkan apa yang diterima oleh sebelah jauh, dan membandingkannya dengan permintaan melalui rangkaian selular memberitahu anda sama ada alamat itu berubah sama sekali.

Jika apl berfungsi melalui rangkaian selular dan gagal melalui terowong dengan akaun yang sama, penolakan itu di hujung jauh atau dalam dasar apl itu sendiri. Jika ia gagal pada kedua-duanya, VPN bukan pembezanya dan anda patut berhenti menguji titik akhir.

Langkah 4: padankan bukti dengan salah satu daripada tiga keputusan

Tiga gabungan meliputi hampir setiap laporan. Penolakan tanpa sebarang percubaan keluar semasa terowong aktif menunjuk kepada semakan pengangkutan setempat. Permintaan yang keluar dan kembali dengan ralat, tamat masa pada hos tertentu atau mesej wilayah menunjuk kepada sebelah jauh. Kegagalan yang berulang melalui rangkaian selular tanpa terowong menunjuk kepada akaun, versi apl atau dasar perkhidmatan itu sendiri, dan tiada perubahan VPN akan menggerakkannya.

Tuliskan keputusan itu bersama bukti yang menghasilkannya. Nilai langkah ini ialah ia menghentikan gelung di mana seseorang menukar nod keluar empat kali untuk membaiki semakan yang berjalan pada telefon itu sendiri.

Ia juga memastikan dakwaan jujur. Pengehosan sendiri menukar titik akhir dan pintu keluar internetnya; ia tidak membuat Android lupa bahawa rangkaian VPN aktif, dan ia tidak menjamin penerimaan oleh perkhidmatan yang mengelaskan alamat. Penapis setempat boleh tercetus pada rangkaian VPN milik anda sendiri semudah pada rangkaian komersial.

Langkah 5: ikut laluan yang disokong dan sahkan

Mulakan dengan dasar produk yang didokumenkan dan pemilik sokongannya. Hantar versi klien, mesej tepat dan tetingkap kegagalan yang sempit; jangan hantar tangkapan trafik penuh atau kelayakan hanya untuk membuktikan ralat wujud.

Jika perkhidmatan membenarkan akses terus dan dasar peranti membenarkannya, pengecualian setiap apl ialah mekanisme yang disokong, dan ia sengaja mengeluarkan apl itu daripada terowong dan bukannya menyembunyikan terowong. Trafik apl kemudian keluar melalui laluannya sendiri, yang merupakan keputusan dasar yang seseorang mesti pikul. Dalam konfigurasi yang menyekat tanpa VPN, apl yang dikecualikan mungkin hanya kehilangan kesambungan, jadi uji gabungan itu sebelum berjanji ia berfungsi.

Selepas setiap perubahan, ulangi ujian masa langkah satu, sahkan apl berfungsi dan sahkan setiap apl lain masih menggunakan terowong. Kemudian pulihkan konfigurasi sebelumnya dan periksa sama ada kegagalan itu kembali, kerana pembaikan yang tidak dapat anda hasilkan semula ialah kebetulan yang akan anda temui lagi.