Android-forrit leysir nöfn utan VPN: gátlisti fyrir bindingu

Android-forrit tekst ekki að leysa innra nafn á meðan vafri VPN-biðlaraforritsins sjálfs nær því, og sama byggingin virkar í öðrum síma. Slóðin er ekki breytan. Breytan er hvaða net ferli forritsins má nota til nafnaleysingar, og Android ábyrgist ekki að virka VPN-ið sé það sem socketarnir þínir nota. Farðu í gegnum þessar athuganir í réttri röð og stöðvaðu þegar skyndimynd leysisins stangast á við forsendu þína.

Skref 1: Sannaðu á hvaða neti forritið er

Lestu eigið yfirlit forritsins frekar en stöðustikuna. Fáðu virka netið úr ConnectivityManager, LinkProperties þess, lista yfir DNS-þjóna og stillingu einkadns. Ef listinn inniheldur leysi VPN-sins hefur forritið leið að honum; ef hann inniheldur leysi Wi-Fi er tunillinn ekki sjálfgefna net þess ferlis.

VPN-tákn segir aðeins að tunill sé til. Það segir ekki að ferli forritsins hafi verið bundið við hann, og Android beinir nafnaleysingu ekki alltaf um netið sem virðist virkt. Staðbundin VPN-forrit sem senda áfram til annars tækis, Wi-Fi-net án internets og byggingar framleiðenda geta allt látið forrit spyrja sjálfgefna leysinn í stað þjóna tunilsins.

Skref 2: Biddu um VPN-flutning og bundu ferlið

Þegar forritið verður að nota leysi tunilsins skaltu biðja um net með VPN-flutningi og binda ferlið í kallsvöruninni, svo kóðinn giski ekki hvenær netið birtist:

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

Kallið breytir sjálfgefnu neti alls ferlisins, svo hver socket sem stofnaður er eftir það notar það. Socketar sem þegar eru til halda netinu sem þeir voru stofnaðir á, og þess vegna getur tengjasafn sem opnað var fyrir bindinguna haldið áfram að leysa um gömlu leiðina. Skilagildið er boolean, og niðurstaðan false þýðir að bindingin átti sér ekki stað; reyndu aftur með stuttri töf og skráðu báðar tilraunir.

Skref 3: Takmarkaðu bindinguna við það sem þarf á henni að halda

Binding fyrir allt ferlið er gróf. Fjarmælingar, uppfærsluathuganir og SDK frá þriðja aðila flytjast líka yfir á tunilinn, og ef tunillinn hefur ekki internet byrja þau að bila. Fyrir eina beiðni skaltu nota socket-verksmiðju netsins og halda sjálfgefnu tækisins fyrir allt annað. Veldu eitt líkan af åsettu ráði: þrönga bindingu fyrir hverja tengingu, eða bindingu ferlis með skýrri aftengingu þegar VPN-ið hverfur.

Tveir eiginleikar leysisins geta sigrað bindinguna án nokkurrar villu. Einkadns í ströngum ham sendir fyrirspurnir til nafngreinds DoT-þjóns í stað leysis netsins, og forrit sem kemur með eigin DNS-over-HTTPS-biðlara fer algjörlega fram hjá leysi kerfisins. Athugaðu hvort tveggja áður en þú ályktar að bindingin hafi brugðist. Fyrirspurn sem nær aldrei til DNS-þjóns VPN-sins mun ekki birtast í neinu skrá á tunilshliðinni.

Skref 4: Treystu ekki CONNECTED-skilyrðinu

NetworkType.CONNECTED í WorkManager þýðir að net er tengt, og VPN-flutningur uppfyllir það jafnvel þótt undirliggjandi Wi-Fi- eða farsímaleið sé farin. Verkið keyrir, hver beiðni bilar, og endurtökustefnan breytir því í storm sem lítur út eins og villu í tímaáætlun. Tunillinn er net; skilyrðið var aldrei internetathugun.

Athugaðu getuna sem verkið þarf í raun, svo sem staðfesta internetaðgang, og haltu afmörkuðri endurtökustefnu með afturhvarfi. Ef verkið þarf einkanafl skaltu leysa það nafn á völdu netinu áður en verkið er unnið, og bila fljótt með skýrri villu í stað þess að endurtaka beiðni sem getur ekki tekist.

Skref 5: Skráðu sönnunargögnin og prófaðu sviðið aftur

Skráðu flutningstegundir valds netsins, DNS-þjónana úr LinkProperties, hvort bindingin skilaði true og nákvæma bilun fyrstu beiðninnar. Keyrðu síðan einkanafl og opinbert nafn undir sömu bindingu. Þetta par sýnir hvort forritið notaði leysi tunilsins eða féll hljóðlega aftur á sjálfgefið tækið, og það er sá munur sem notandinn upplifir.

Endurtaktu á elstu Android-útgáfunni sem þú styður og á einni núverandi útgáfu. Hegðun leysisins sem lætur sjálfgefnu leiðina líta rétta út er einmitt þar sem tæki og útgáfur eru ólík, og bygging sem stenst aðeins á nýjasta prófunartækinu hefur ekki verið staðfest fyrir það svið sem þú sendir frá þér. adb shell dumpsys connectivity er fljótleg leið til að staðfesta hvaða net og getu tækið tilkynnir meðan þú endurgerir bilunina.