Aplikasi Android Menyelesaikan Nama di Luar VPN: Daftar Periksa Pengikatan

Sebuah aplikasi Android gagal menyelesaikan nama internal sementara peramban milik klien VPN itu sendiri berhasil mencapainya, dan build yang sama berfungsi di ponsel lain. URL bukan variabelnya. Variabelnya adalah jaringan mana yang boleh dipakai proses aplikasi untuk resolusi, dan Android tidak menjamin bahwa VPN yang aktif adalah VPN yang dipakai socket Anda. Lakukan pemeriksaan ini secara berurutan dan berhenti ketika cuplikan resolver tidak sesuai dengan asumsi Anda.

Langkah 1: Buktikan di jaringan mana aplikasi berada

Baca tampilan aplikasi itu sendiri, bukan bilah status. Dari ConnectivityManager, ambil jaringan aktif, LinkProperties-nya, daftar server DNS, dan pengaturan DNS privat. Jika daftar memuat resolver VPN, aplikasi punya jalur ke sana; jika memuat resolver Wi-Fi, terowongan bukan jaringan default untuk proses tersebut.

Ikon VPN hanya menyatakan bahwa terowongan ada. Itu tidak menyatakan proses aplikasi terikat padanya, dan Android tidak selalu merutekan resolusi nama melalui jaringan yang tampak aktif. Aplikasi VPN lokal yang meneruskan ke perangkat lain, jaringan Wi-Fi tanpa internet, dan build dari vendor semuanya dapat membuat aplikasi menanyakan resolver default alih-alih server terowongan.

Langkah 2: Minta transport VPN dan ikat prosesnya

Ketika aplikasi harus memakai resolver terowongan, minta jaringan dengan transport VPN dan ikat proses di callback, agar kode tidak menebak kapan jaringan muncul:

val request = NetworkRequest.Builder()
    .addTransportType(NetworkCapabilities.TRANSPORT_VPN)
    .build()

connectivityManager.requestNetwork(request, object : NetworkCallback() {
    override fun onAvailable(network: Network) {
        val bound = connectivityManager.bindProcessToNetwork(network)
        Log.i(TAG, "bound to VPN network: " + bound)
    }
})

Panggilan itu mengubah jaringan default seluruh proses, sehingga setiap socket yang dibuat sesudahnya memakainya. Socket yang sudah ada tetap memakai jaringan tempat ia dibuat, itulah sebabnya kumpulan koneksi yang dibuka sebelum pengikatan dapat terus menyelesaikan melalui jalur lama. Nilai kembaliannya boolean, dan hasil false berarti pengikatan tidak terjadi; coba lagi dengan jeda singkat dan catat kedua percobaan.

Langkah 3: Batasi pengikatan pada yang membutuhkannya

Pengikatan seluruh proses bersifat kasar. Telemetri, pemeriksaan pembaruan, dan SDK pihak ketiga juga berpindah ke terowongan, dan bila terowongan tidak punya internet semuanya mulai gagal. Untuk satu permintaan, gunakan pabrik socket milik jaringan dan biarkan default perangkat untuk sisanya. Pilih satu model dengan sengaja: pengikatan sempit per koneksi, atau pengikatan proses dengan pelepasan eksplisit saat VPN menghilang.

Dua fitur resolver dapat mengalahkan pengikatan tanpa kesalahan apa pun. DNS privat dalam mode ketat mengirim kueri ke server DoT bernama alih-alih ke resolver jaringan, dan aplikasi yang membawa klien DNS-over-HTTPS sendiri melewati resolver sistem sepenuhnya. Periksa keduanya sebelum menyimpulkan pengikatan gagal. Kueri yang tidak pernah mencapai server DNS VPN tidak akan muncul di log sisi terowongan mana pun.

Langkah 4: Jangan percaya batasan CONNECTED

NetworkType.CONNECTED di WorkManager berarti ada jaringan yang terhubung, dan transport VPN memenuhinya bahkan ketika tautan Wi-Fi atau seluler di bawahnya sudah hilang. Pekerjaan berjalan, setiap permintaan gagal, dan kebijakan percobaan ulang mengubahnya menjadi badai yang tampak seperti bug penjadwalan. Terowongan adalah jaringan; batasan itu tidak pernah menjadi pemeriksaan internet.

Periksa kemampuan yang benar-benar dibutuhkan pekerjaan, seperti akses internet tervalidasi, dan pertahankan kebijakan percobaan ulang terbatas dengan backoff. Jika pekerjaan memerlukan nama privat, selesaikan nama itu di jaringan terpilih sebelum melakukan pekerjaan, dan gagal cepat dengan kesalahan yang jelas alih-alih mengulang permintaan yang tidak mungkin berhasil.

Langkah 5: Catat buktinya dan uji ulang rentangnya

Catat jenis transport jaringan terpilih, server DNS dari LinkProperties, apakah pengikatan mengembalikan true, dan kegagalan persis permintaan pertama. Lalu jalankan nama privat dan nama publik di bawah pengikatan yang sama. Pasangan itu menunjukkan apakah aplikasi memakai resolver terowongan atau diam-diam jatuh ke default perangkat, dan itulah perbedaan yang dialami pengguna.

Ulangi pada versi Android tertua yang Anda dukung dan pada satu rilis terkini. Perilaku resolver yang membuat jalur default tampak benar justru adalah tempat perangkat dan versi berbeda, dan build yang hanya lolos pada perangkat uji terbaru belum terverifikasi untuk rentang yang Anda kirimkan. adb shell dumpsys connectivity adalah cara cepat untuk memastikan jaringan dan kemampuan apa yang dilaporkan perangkat saat Anda mereproduksi kegagalan.