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

Android може да решава имиња преку стандардната мрежа додека VPN е активен. Поврзете го процесот со VPN мрежата и проверете кој resolver апликацијата навистина го користела.

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

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

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

Иконата за 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 е брз начин да потврдите кои мрежи и можности ги пријавува уредот додека го репродуцирате дефектот.

Поврзани статии