Android հավելվածը լուծում է անունները VPN-ից դուրս. կապակցման ստուգաթերթ

Android հավելվածը չի կարողանում լուծել ներքին անուն, մինչդեռ VPN հաճախորդի սեփական դիտարկիչը հասնում է դրան, և նույն կառուցումը աշխատում է մեկ այլ հեռախոսում։ URL-ը փոփոխականը չէ։ Փոփոխականն այն է, թե որ ցանցին է թույլատրված հավելվածի գործընթացն օգտագործել լուծման համար, և Android-ը չի երաշխավորում, որ ակտիվ VPN-ը հենց այն է, որն օգտագործում են ձեր սոքեթները։ Կատարեք այս ստուգումները հերթով և կանգ առեք, երբ լուծիչի պատկերը չհամընկնի ձեր ենթադրության հետ։

Քայլ 1. ապացուցեք, թե որ ցանցում է հավելվածը

Կարդացեք հավելվածի սեփական տեսքը, ոչ թե կարգավիճակի տողը։ ConnectivityManager-ից ստացեք ակտիվ ցանցը, դրա LinkProperties-ը, DNS սերվերների ցանկը և մասնավոր DNS կարգավորումը։ Եթե ցանկը պարունակում է VPN-ի լուծիչը, հավելվածն ունի դեպի այն ուղի. եթե այն պարունակում է Wi-Fi-ի լուծիչը, թունելը այդ գործընթացի լռելյայն ցանցը չէ։

VPN պատկերակը միայն ասում է, որ թունել գոյություն ունի։ Այն չի ասում, որ հավելվածի գործընթացը կապակցված էր դրան, և Android-ը միշտ չէ, որ անունների լուծումը ուղղում է ակտիվ երևացող ցանցով։ Այլ սարքին փոխանցող տեղական VPN հավելվածները, առանց ինտերնետի Wi-Fi ցանցերը և արտադրողի կառուցումները կարող են հավելվածին թողնել հարցնելու լռելյայն լուծիչին՝ թունելի սերվերների փոխարեն։

Քայլ 2. պահանջեք VPN տրանսպորտը և կապակցեք գործընթացը

Երբ հավելվածը պարտավոր է օգտագործել թունելի լուծիչը, պահանջեք ցանց VPN տրանսպորտով և կապակցեք գործընթացը հետադարձ կապում, որպեսզի կոդը չգուշակի, երբ ցանցը կհայտնվի.

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

Կանչը փոխում է ամբողջ գործընթացի լռելյայն ցանցը, ուստի դրանից հետո ստեղծված յուրաքանչյուր սոքեթ օգտագործում է այն։ Արդեն գոյություն ունեցող սոքեթները պահում են այն ցանցը, որում ստեղծվել են, ինչի պատճառով կապակցումից առաջ բացված միացումների պահոցը կարող է շարունակել լուծել հին ուղիով։ Վերադարձվող արժեքը բուլյան է, և կեղծ արդյունքը նշանակում է, որ կապակցումը տեղի չի ունեցել. կրկնեք կարճ ուշացումով և գրանցեք երկու փորձերն էլ։

Քայլ 3. սահմանափակեք կապակցումը նրանով, ինչին այն պետք է

Ամբողջ գործընթացի կապակցումը կոպիտ է։ Հեռաչափությունը, թարմացումների ստուգումները և երրորդ կողմի SDK-ները նույնպես տեղափոխվում են թունել, և եթե թունելն ինտերնետ չունի, նրանք սկսում են ձախողվել։ Մեկ հարցման համար օգտագործեք ցանցի սոքեթ գործարանը և մնացած ամեն ինչ թողեք սարքի լռելյայնին։ Գիտակցաբար ընտրեք մեկ մոդել՝ նեղ կապակցում յուրաքանչյուր միացման համար, կամ գործընթացի կապակցում՝ բացահայտ անջատումով, երբ VPN-ը անհետանում է։

Լուծիչի երկու հատկություն կարող են հաղթահարել կապակցումը առանց որևէ սխալի։ Խիստ ռեժիմում մասնավոր DNS-ը հարցումները ուղարկում է անվանված DoT սերվերին՝ ցանցի լուծիչի փոխարեն, և սեփական DNS-over-HTTPS հաճախորդով հավելվածը լիովին շրջանցում է համակարգի լուծիչը։ Ստուգեք երկուսն էլ նախքան եզրակացնելը, որ կապակցումը ձախողվել է։ Հարցումը, որը երբեք չի հասնում VPN-ի DNS սերվերին, չի հայտնվի թունելի կողմի ոչ մի մատյանում։

Քայլ 4. մի վստահեք CONNECTED սահմանափակմանը

WorkManager-ի NetworkType.CONNECTED նշանակում է, որ ցանցը միացված է, և VPN տրանսպորտը բավարարում է դրան նույնիսկ այն դեպքում, երբ հիմքում ընկած Wi-Fi կամ բջջային կապը վերացել է։ Աշխատանքը կատարվում է, ամեն հարցում ձախողվում է, և կրկնափորձերի քաղաքականությունը դա վերածում է փոթորկի, որը նման է ժամանակացույցի սխալի։ Թունելը ցանց է. սահմանափակումը երբեք ինտերնետի ստուգում չի եղել։

Ստուգեք այն կարողությունը, որն աշխատանքին իսկապես պետք է, օրինակ՝ հաստատված ինտերնետ հասանելիությունը, և պահեք սահմանափակ կրկնափորձերի քաղաքականություն հետընթացով։ Եթե աշխատանքին մասնավոր անուն է պետք, լուծեք այդ անունը ընտրված ցանցում նախքան աշխատանքը կատարելը, և արագ ձախողվեք հստակ սխալով՝ փոխարենը կրկնելու հարցում, որը չի կարող հաջողվել։

Քայլ 5. գրանցեք ապացույցները և վերստուգեք տիրույթը

Գրանցեք ընտրված ցանցի տրանսպորտի տեսակները, LinkProperties-ից ստացված DNS սերվերները, արդյոք կապակցումը վերադարձրել է ճշմարիտ, և առաջին հարցման ճշգրիտ ձախողումը։ Այնուհետև նույն կապակցման ներքո գործարկեք մասնավոր անուն և հանրային անուն։ Այդ զույգը ցույց է տալիս՝ հավելվածն օգտագործել է թունելի լուծիչը, թե լուռ հետ է ընկել սարքի լռելյայնին, և դա այն տարբերությունն է, որ զգում է օգտատերը։

Կրկնեք ձեր աջակցած ամենահին Android տարբերակում և մեկ ընթացիկ թողարկումում։ Լուծիչի այն վարքը, որը լռելյայն ուղին ճիշտ է դարձնում, հենց այն տեղն է, որտեղ սարքերն ու տարբերակները տարբերվում են, և այն կառուցումը, որն անցնում է միայն ամենանոր փորձարկման սարքում, հաստատված չէ ձեր առաքվող տիրույթի համար։ adb shell dumpsys connectivity արագ միջոց է հաստատելու, թե սարքը ինչ ցանցեր և կարողություններ է հաղորդում, մինչ դուք վերարտադրում եք ձախողումը։