Aplikacija Android razrešuje imena zunaj VPN: kontrolni seznam za vezavo

Aplikacija Android ne more razrešiti notranjega imena, medtem ko brskalnik samega odjemalca VPN do njega pride, in ista gradnja deluje na drugem telefonu. URL ni spremenljivka. Spremenljivka je, katero omrežje sme proces aplikacije uporabljati za razreševanje, in Android ne zagotavlja, da je aktivni VPN tisto omrežje, ki ga uporabljajo vaše vtičnice. Izvedite te kontrole po vrsti in ustavite se, ko se posnetek resolverja ne ujema z vašo predpostavko.

Korak 1: dokažite, v katerem omrežju je aplikacija

Berite pogled same aplikacije, ne vrstice stanja. Iz ConnectivityManager pridobite aktivno omrežje, njegove LinkProperties, seznam strežnikov DNS in nastavitev zasebnega DNS. Če seznam vsebuje resolver VPN, ima aplikacija pot do njega; če vsebuje resolver Wi-Fi, tunel ni privzeto omrežje za ta proces.

Ikona VPN pove le, da tunel obstaja. Ne pove, da je bil proces aplikacije vezan nanj, in Android ne usmerja vedno razreševanja imen skozi omrežje, ki je videti aktivno. Lokalne aplikacije VPN, ki posredujejo na drugo napravo, omrežja Wi-Fi brez interneta in gradnje proizvajalcev lahko pustijo aplikacijo, da sprašuje privzeti resolver namesto strežnikov tunela.

Korak 2: zahtevajte transport VPN in povežite proces

Ko mora aplikacija uporabiti resolver tunela, zahtevajte omrežje s transportom VPN in v povratnem klicu povežite proces, da koda ne ugiba, kdaj se omrežje pojavi:

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

Klic spremeni privzeto omrežje celotnega procesa, zato vsaka vtičnica, ustvarjena pozneje, uporablja to omrežje. Vtičnice, ki že obstajajo, obdržijo omrežje, v katerem so bile ustvarjene, zato lahko nabor povezav, odprt pred vezavo, še naprej razrešuje po stari poti. Vrnjena vrednost je logična, in rezultat false pomeni, da se vezava ni zgodila; poskusite znova s kratko zakasnitvijo in zabeležite oba poskusa.

Korak 3: omejite vezavo na tisto, kar jo potrebuje

Vezava celotnega procesa je groba. Telemetrija, preverjanja posodobitev in SDK tretjih strani se prav tako preselijo na tunel, in če tunel nima interneta, začnejo odpovedovati. Za eno zahtevo uporabite tovarno vtičnic omrežja, vse drugo pa pustite na privzeti nastavitvi naprave. Zavestno izberite en model: ozka vezava na povezavo ali vezava procesa z izrecno odvezo, ko VPN izgine.

Dve funkciji resolverja lahko premagata vezavo brez vsake napake. Zasebni DNS v strogem načinu pošilja poizvedbe na imenovani strežnik DoT namesto na resolver omrežja, in aplikacija z lastnim odjemalcem DNS-over-HTTPS popolnoma obide sistemski resolver. Preverite oba, preden sklepate, da je vezava spodletela. Poizvedba, ki nikoli ne doseže strežnika DNS VPN, se ne bo pojavila v nobenem dnevniku na strani tunela.

Korak 4: ne zaupajte omejitvi CONNECTED

NetworkType.CONNECTED v WorkManager pomeni, da je omrežje povezano, in transport VPN to izpolni tudi takrat, ko spodnja povezava Wi-Fi ali mobilnega omrežja ni več na voljo. Opravilo se izvede, vsaka zahteva spodleti, in politika ponovitev to spremeni v nevihto, ki je videti kot napaka pri razporejanju. Tunel je omrežje; omejitev nikoli ni bila preverjanje interneta.

Preverite zmožnost, ki jo delo res potrebuje, na primer potrjen dostop do interneta, in ohranite omejeno politiko ponovitev z zamikom. Če opravilo potrebuje zasebno ime, to ime razrešite v izbranem omrežju pred izvedbo dela in hitro spodletite z jasno napako, namesto da ponavljate zahtevo, ki ne more uspeti.

Korak 5: zabeležite dokaze in znova preizkusite razpon

Zabeležite vrste transporta izbranega omrežja, strežnike DNS iz LinkProperties, ali je vezava vrnila true, in natančno napako prve zahteve. Nato zaženite zasebno ime in javno ime pod isto vezavo. Ta par pokaže, ali je aplikacija uporabila resolver tunela ali se tiho vrnila na privzeto nastavitev naprave, in to je razlika, ki jo uporabnik občuti.

Ponovite na najstarejši podprti različici Android in na eni trenutni izdaji. Vedenje resolverja, zaradi katerega je privzeta pot videti pravilna, je točno tisto mesto, kjer se naprave in različice razlikujejo, in gradnja, ki uspe le na najnovejši testni napravi, ni preverjena za razpon, ki ga pošiljate. adb shell dumpsys connectivity je hiter način, da potrdite, katera omrežja in zmožnosti naprava poroča, medtem ko poustvarjate napako.