Apl Android menyelesaikan nama di luar VPN: senarai semak pengikatan

Apl Android gagal menyelesaikan nama dalaman sementara pelayar klien VPN itu sendiri mencapainya, dan binaan yang sama berfungsi pada telefon lain. URL bukan pemboleh ubahnya. Pemboleh ubahnya ialah rangkaian mana yang dibenarkan digunakan oleh proses apl untuk penyelesaian, dan Android tidak menjamin bahawa VPN aktif ialah rangkaian yang digunakan oleh soket anda. Lakukan semakan ini mengikut urutan dan berhenti apabila petikan resolver tidak sepadan dengan andaian anda.

Langkah 1: buktikan rangkaian mana apl berada

Baca paparan apl itu sendiri, bukan bar status. Daripada ConnectivityManager, dapatkan rangkaian aktif, LinkProperties-nya, senarai pelayan DNS dan tetapan DNS peribadi. Jika senarai mengandungi resolver VPN, apl mempunyai laluan kepadanya; jika ia mengandungi resolver Wi-Fi, terowong bukan rangkaian lalai bagi proses itu.

Ikon VPN hanya mengatakan terowong wujud. Ia tidak mengatakan proses apl telah diikat kepadanya, dan Android tidak sentiasa menghalakan penyelesaian nama melalui rangkaian yang kelihatan aktif. Apl VPN setempat yang memajukan ke peranti lain, rangkaian Wi-Fi tanpa internet dan binaan vendor semuanya boleh membiarkan apl bertanya kepada resolver lalai dan bukannya pelayan terowong.

Langkah 2: minta pengangkutan VPN dan ikat proses

Apabila apl mesti menggunakan resolver terowong, minta rangkaian dengan pengangkutan VPN dan ikat proses dalam panggilan balik, supaya kod tidak meneka bila rangkaian 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 menukar rangkaian lalai seluruh proses, jadi setiap soket yang dicipta selepas itu menggunakannya. Soket yang sudah wujud mengekalkan rangkaian tempat ia dicipta, sebab itulah kolam sambungan yang dibuka sebelum pengikatan boleh terus menyelesaikan melalui laluan lama. Nilai pulangan ialah boolean, dan keputusan palsu bermakna pengikatan tidak berlaku; cuba lagi dengan kelewatan singkat dan log kedua-dua percubaan.

Langkah 3: hadkan pengikatan kepada apa yang memerlukannya

Pengikatan seluruh proses adalah kasar. Telemetri, semakan kemas kini dan SDK pihak ketiga juga berpindah ke terowong, dan jika terowong tiada internet semuanya mula gagal. Untuk satu permintaan, gunakan kilang soket rangkaian itu dan biarkan lalai peranti untuk semua yang lain. Pilih satu model dengan sengaja: pengikatan sempit bagi setiap sambungan, atau pengikatan proses dengan pelepasan jelas apabila VPN hilang.

Dua ciri resolver boleh mengalahkan pengikatan tanpa sebarang ralat. DNS peribadi dalam mod ketat menghantar pertanyaan ke pelayan DoT bernama dan bukannya resolver rangkaian, dan apl yang membawa klien DNS-over-HTTPS sendiri memintas resolver sistem sepenuhnya. Semak kedua-duanya sebelum membuat kesimpulan bahawa pengikatan gagal. Pertanyaan yang tidak pernah sampai ke pelayan DNS VPN tidak akan muncul dalam mana-mana log sebelah terowong.

Langkah 4: jangan percaya kekangan CONNECTED

NetworkType.CONNECTED dalam WorkManager bermaksud rangkaian bersambung, dan pengangkutan VPN memenuhinya walaupun pautan Wi-Fi atau selular di bawahnya telah hilang. Kerja berjalan, setiap permintaan gagal, dan dasar cubaan semula mengubahnya menjadi badai yang kelihatan seperti pepijat penjadualan. Terowong ialah rangkaian; kekangan itu tidak pernah menjadi semakan internet.

Semak keupayaan yang benar-benar diperlukan oleh kerja, seperti akses internet yang disahkan, dan kekalkan dasar cubaan semula terhad dengan pengunduran. Jika kerja memerlukan nama peribadi, selesaikan nama itu dalam rangkaian yang dipilih sebelum melakukan kerja, dan gagal cepat dengan ralat yang jelas dan bukannya mengulangi permintaan yang tidak mungkin berjaya.

Langkah 5: rekod bukti dan uji semula julat

Log jenis pengangkutan rangkaian yang dipilih, pelayan DNS daripada LinkProperties, sama ada pengikatan mengembalikan benar, dan kegagalan tepat permintaan pertama. Kemudian jalankan nama peribadi dan nama awam di bawah pengikatan yang sama. Pasangan itu menunjukkan sama ada apl menggunakan resolver terowong atau senyap kembali ke lalai peranti, dan itulah perbezaan yang dialami pengguna.

Ulang pada versi Android tertua yang anda sokong dan pada satu keluaran semasa. Tingkah laku resolver yang membuat laluan lalai kelihatan betul ialah tepat tempat peranti dan versi berbeza, dan binaan yang lulus hanya pada peranti ujian terbaharu belum disahkan untuk julat yang anda hantar. adb shell dumpsys connectivity ialah cara cepat untuk mengesahkan rangkaian dan keupayaan yang dilaporkan peranti semasa anda menghasilkan semula kegagalan.