Androidi rakendus ei suuda lahendada sisemist nime, samal ajal kui VPN-kliendi enda brauser jõuab selleni, ja sama build töötab teises telefonis. Muutuja ei ole URL. Muutuja on see, millist võrku tohib rakenduse protsess lahendamiseks kasutada, ja Android ei taga, et aktiivne VPN on see, mida teie soketid kasutavad. Käige need kontrollid järjekorras läbi ja lõpetage, kui lahendaja hetkepilt teie eeldusega ei ühti.

Samm 1: Tõestage, millises võrgus rakendus on

Lugege rakenduse enda vaadet, mitte olekuriba. Hankige ConnectivityManager kaudu aktiivne võrk, selle LinkProperties , DNS-serverite loend ja privaatse DNS-i säte. Kui loend sisaldab VPN-i lahendajat, on rakendusel tee sinna; kui see sisaldab Wi-Fi lahendajat, ei ole tunnel selle protsessi vaikevõrk.

VPN-i ikoon ütleb ainult, et tunnel on olemas. See ei ütle, et rakenduse protsess oli sellega seotud, ja Android ei suuna nimelahendust alati võrku, mis tundub aktiivne. Kohalikud VPN-rakendused, mis edastavad teisele seadmele, internetita Wi-Fi võrgud ja tootjate buildid võivad jätta rakenduse küsima vaikelahendajalt, mitte tunneli serveritelt.

Samm 2: Küsige VPN-i transporti ja siduge protsess

Kui rakendus peab kasutama tunneli lahendajat, küsige VPN-i transpordiga võrku ja siduge protsess callbackis, et kood ei oletaks, millal võrk ilmub:

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

Kutse muudab kogu protsessi vaikevõrku, seega kasutab seda iga hiljem loodud soket. Juba olemasolevad soketid säilitavad võrgu, milles need loodi, ja seetõttu võib enne sidumist avatud ühenduste bassein jätkata lahendamist vana tee kaudu. Tagastusväärtus on tõeväärtus ja tulemus false tähendab, et sidumist ei toimunud; proovige lühikese viivituse järel uuesti ja logige mõlemad katsed.

Samm 3: Piirake sidumine sellega, mis seda vajab

Kogu protsessi sidumine on jäme. Telemeetria, värskenduste kontrollid ja kolmandate osapoolte SDK-d liiguvad samuti tunnelisse, ja kui tunnelil pole internetti, hakkavad need ebaõnnestuma. Ühe päringu jaoks kasutage võrgu soketi tehast ja hoidke seadme vaikeväärtust kõige muu jaoks. Valige teadlikult üks mudel: kitsas sidumine ühenduse kohta või protsessi sidumine koos selgesõnalise lahtisidumisega, kui VPN kaob.

Kaks lahendaja funktsiooni võivad sidumise ilma ühegi veata nurjata. Privaatne DNS range režiimis saadab päringud nimetatud DoT-serverile, mitte võrgu lahendajale, ja oma DNS-over-HTTPS-kliendiga rakendus möödub süsteemi lahendajast täielikult. Kontrollige mõlemat, enne kui järeldate, et sidumine ebaõnnestus. Päring, mis ei jõua kunagi VPN-i DNS-serverini, ei ilmu üheski tunnelipoolses logis.

Samm 4: Ärge usaldage piirangut CONNECTED

WorkManageri NetworkType.CONNECTED tähendab, et võrk on ühendatud, ja VPN-i transport rahuldab selle ka siis, kui selle all olev Wi-Fi või mobiililink on kadunud. Töö jookseb, iga päring ebaõnnestub ja kordusstrateegia muudab selle tormiks, mis näeb välja nagu planeerimisviga. Tunnel on võrk; piirang ei olnud kunagi interneti kontroll.

Kontrollige võimekust, mida töö tegelikult vajab, näiteks kinnitatud internetiühendust, ja hoidke piiratud kordusstrateegiat tagasihoidmisega. Kui töö vajab sisemist nime, lahendage see nimi valitud võrgus enne töö tegemist ja ebaõnnestuge kiiresti selge veaga, selle asemel et korrata päringut, mis ei saa õnnestuda.

Samm 5: Salvestage tõendid ja testige vahemikku uuesti

Logige valitud võrgu transporditüübid, DNS-serverid LinkProperties , kas sidumine tagastas true, ja esimese päringu täpne tõrge. Seejärel käivitage sisemine ja avalik nimi sama sidumise all. See paar näitab, kas rakendus kasutas tunneli lahendajat või langes vaikselt seadme vaikeväärtusele, ja see on erinevus, mida kasutaja kogeb.

Korrake vanimal toetatud Androidi versioonil ja ühel praegusel versioonil. Lahendaja käitumine, mis teeb vaiketeest õige näiva, on täpselt see, mille poolest seadmed ja versioonid erinevad, ja build, mis läbib ainult uusimal testseadmel, ei ole teie tarnitava vahemiku jaoks kontrollitud. adb shell dumpsys connectivityon kiire viis kinnitada, milliseid võrke ja võimekusi seade tõrke taasesitamise ajal teatab.

Seotud artiklid