Android апликација разрешава имена изван VPN-а: контролна листа за повезивање

Android апликација не успева да разреши интерно име док прегледач самог VPN клијента до њега стиже, а исто се издање исправно понаша на другом телефону. URL није променљива. Променљива је којој мрежи процес апликације сме да користи за разрешавање, а Android не гарантује да је активни VPN онај који користе ваши сокети. Прођите ове провере редом и зауставите се када се снимак resolver-а не слаже са вашом претпоставком.

Корак 1: докажите на којој је мрежи апликација

Читајте сопствени приказ апликације, а не статусну траку. Из ConnectivityManager узмите активну мрежу, њене LinkProperties, списак DNS сервера и подешавање приватног DNS-а. Ако списак садржи resolver VPN-а, апликација има пут до њега; ако садржи Wi-Fi resolver, тунел није подразумевана мрежа за тај процес.

Икона VPN-а говори само да тунел постоји. Не говори да је процес апликације био повезан са њим, а Android не усмерава увек разрешавање имена кроз мрежу која изгледа активно. Локалне VPN апликације које прослеђују другом уређају, Wi-Fi мреже без интернета и издања произвођача могу оставити апликацију да пита подразумевани resolver уместо сервера тунела.

Корак 2: затражите VPN транспорт и повежите процес

Када апликација мора да користи resolver тунела, затражите мрежу са 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)
    }
})

Позив мења подразумевану мрежу целог процеса, па сваки сокет створен после тога користи њу. Сокети који већ постоје задржавају мрежу на којој су створени, зато скуп веза отворен пре повезивања може наставити да разрешава старим путем. Повратна вредност је boolean, а резултат false значи да се повезивање није догодило; покушајте поново са кратком паузом и забележите оба покушаја.

Корак 3: ограничите повезивање на оно чему је потребно

Повезивање целог процеса је грубо. Телеметрија, провере ажурирања и SDK трећих страна такође прелазе на тунел, а ако тунел нема интернет, почињу да отказују. За један захтев употребите фабрику сокета мреже, а све остало оставите на подразумеваној вредности уређаја. Намерно изаберите један модел: уско повезивање по вези или повезивање процеса са изричитим одвезивањем када VPN нестане.

Две особине resolver-а могу победити повезивање без икакве грешке. Приватни DNS у строгом режиму шаље упите именованом DoT серверу уместо resolver-у мреже, а апликација која доноси сопствени DNS-over-HTTPS клијент потпуно заобилази системски resolver. Проверите обоје пре него што закључите да је повезивање неуспешно. Упит који никада не стигне до DNS сервера VPN-а неће се појавити ни у једном дневнику на страни тунела.

Корак 4: не верујте ограничењу CONNECTED

NetworkType.CONNECTED у WorkManager-у значи да је мрежа повезана, а VPN транспорт га задовољава и када је основна Wi-Fi или мобилна веза нестала. Посао се извршава, сваки захтев не успева, а политика понављања претвара то у олују која изгледа као грешка у распоређивању. Тунел је мрежа; ограничење никада није било провера интернета.

Проверите могућност која послу заиста треба, попут потврђеног приступа интернету, и држите ограничену политику понављања са одлагањем. Ако послу треба приватно име, разрешите то име у изабраној мрежи пре обављања посла и брзо откажите са јасном грешком уместо да понављате захтев који не може успети.

Корак 5: забележите доказе и поново проверите опсег

Забележите врсте транспорта изабране мреже, DNS сервере из LinkProperties, да ли је повезивање вратило true и тачан неуспех првог захтева. Затим покрените приватно име и јавно име под истим повезивањем. Тај пар показује да ли је апликација користила resolver тунела или је тихо пала на подразумевану вредност уређаја, а то је разлика коју корисник осећа.

Поновите на најстаријој Android верзији коју подржавате и на једном актуелном издању. Понашање resolver-а због којег подразумевани пут изгледа исправно управо је место где се уређаји и верзије разликују, а издање које пролази само на најновијем тестном уређају није проверено за опсег који испоручујете. adb shell dumpsys connectivity је брз начин да потврдите које мреже и могућности уређај пријављује док репродукујете квар.