Android-a aplikaĵo solvas nomojn ekster la VPN: kontrol-listo por ligado

Android povas solvi nomojn per la implicita reto dum VPN estas aktiva. Ligu la procezon al la VPN-reto kaj kontrolu kiun solvilon la aplikaĵo efektive uzis.

Android-a aplikaĵo malsukcesas solvi internan nomon dum la propra retumilo de la VPN-kliento atingas ĝin, kaj la sama konstruo funkcias sur alia telefono. La variablo ne estas la URL. La variablo estas kiun reton la procezo de la aplikaĵo rajtas uzi por solvado, kaj Android ne garantias, ke la aktiva VPN estas tiu, kiun uzas viaj poŝoj. Trairu ĉi tiujn kontrolojn laŭorde kaj haltu, kiam la momenta bildo de la solvilo malkongruas kun via supozo.

Paŝo 1: Pruvu, en kiu reto la aplikaĵo estas

Legu la propran vidon de la aplikaĵo anstataŭ la statan breton. El ConnectivityManager prenu la aktivan reton, ĝiajn LinkProperties , la liston de DNS-serviloj kaj la agordon de privata DNS. Se la listo enhavas la solvilon de la VPN, la aplikaĵo havas vojon al ĝi; se ĝi enhavas la solvilon de Wi-Fi, la tunelo ne estas la implicita reto por tiu procezo.

VPN-ikono nur diras, ke tunelo ekzistas. Ĝi ne diras, ke la procezo de la aplikaĵo estis ligita al ĝi, kaj Android ne ĉiam direktas nomosolvadon tra la reto, kiu aspektas aktiva. Lokaj VPN-aplikaĵoj, kiuj plusendas al alia aparato, Wi-Fi-retoj sen interreto kaj konstruoj de produktejoj povas lasi aplikaĵon demandi la implicitan solvilon anstataŭ la servilojn de la tunelo.

Paŝo 2: Petu la VPN-transporton kaj ligu la procezon

Kiam la aplikaĵo devas uzi la solvilon de la tunelo, petu reton kun la VPN-transporto kaj ligu la procezon en la relanĉo, por ke la kodo ne divenu, kiam la reto aperas:

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)
    }
})

La voko ŝanĝas la implicitan reton por la tuta procezo, do ĉiu poŝo kreita poste uzas ĝin. Poŝoj, kiuj jam ekzistas, konservas la reton, sur kiu ili estis kreitaj, kaj tial naĝejo de konektoj malfermita antaŭ la ligado povas daŭre solvi laŭ la malnova vojo. La redonita valoro estas bulea, kaj rezulto false signifas, ke la ligado ne okazis; reprovu post mallonga prokrasto kaj registru ambaŭ provojn.

Paŝo 3: Limigu la ligadon al tio, kio bezonas ĝin

Ligado por la tuta procezo estas maldelikata. Telemetrio, ĝisdatigaj kontroloj kaj SDK-oj de triaj partioj ankaŭ transiras al la tunelo, kaj se la tunelo ne havas interreton, ili komencas malsukcesi. Por unu peto uzu la poŝan fabrikon de la reto kaj konservu la implicitan agordon de la aparato por ĉio alia. Elektu konscie unu modelon: mallarĝa ligado por ĉiu konekto, aŭ proceza ligado kun eksplicita malligado, kiam la VPN malaperas.

Du trajtoj de la solvilo povas venki la ligadon sen iu ajn eraro. Privata DNS en strikta reĝimo sendas demandojn al nomita DoT-servilo anstataŭ al la reta solvilo, kaj aplikaĵo kun propra DNS-over-HTTPS-kliento tute preterpasas la sisteman solvilon. Kontrolu ambaŭ antaŭ ol konkludi, ke la ligado malsukcesis. Demando, kiu neniam atingas la DNS-servilon de la VPN, ne aperos en iu ajn protokolo ĉe la tunela flanko.

Paŝo 4: Ne fidu limigon CONNECTED

La flago NetworkType.CONNECTED de WorkManager signifas, ke reto estas konektita, kaj la VPN-transporto plenumas ĝin eĉ kiam la suba Wi-Fi aŭ poŝtelefona ligo malaperis. La tasko rulas, ĉiu peto malsukcesas, kaj la ripeta politiko transformas ĝin en ŝtormon, kiu aspektas kiel planada cimo. La tunelo estas reto; la limigo neniam estis interreta kontrolo.

Kontrolu la kapablon, kiun la laboro efektive bezonas, ekzemple validigitan interretan aliron, kaj tenu limigitan ripetan politikon kun malantaŭeniĝo. Se la tasko bezonas internan nomon, solvu tiun nomon en la elektita reto antaŭ ol fari la laboron, kaj malsukcesu rapide kun klara eraro anstataŭ ripeti peton, kiu ne povas sukcesi.

Paŝo 5: Registru la pruvojn kaj retestu la gamon

Registru la transportajn tipojn de la elektita reto, la DNS-servilojn el LinkProperties , ĉu la ligado redonis true, kaj la precizan malsukceson de la unua peto. Poste rulu internan kaj publikan nomon sub la sama ligado. Tiu paro montras, ĉu la aplikaĵo uzis la solvilon de la tunelo aŭ silente refalis al la implicita agordo de la aparato, kaj tio estas la diferenco, kiun la uzanto spertas.

Ripetu sur la plej malnova Android-versio, kiun vi subtenas, kaj sur unu aktuala eldono. La solvila konduto, kiu igas la implicitan vojon aspekti ĝusta, estas ĝuste tie, kie aparatoj kaj versioj malsamas, kaj konstruo, kiu pasas nur sur la plej nova testa aparato, ne estas kontrolita por la gamo, kiun vi liveras. adb shell dumpsys connectivityestas rapida maniero konfirmi, kiujn retojn kaj kapablojn la aparato raportas dum vi reproduktas la fiaskon.

Rilataj artikoloj