Android lietotne atrisina vārdus ārpus VPN: saistīšanas kontrolsaraksts

Android lietotne nespēj atrisināt iekšēju vārdu, kamēr paša VPN klienta pārlūks to sasniedz, un tā pati būve darbojas citā telefonā. URL nav mainīgais. Mainīgais ir tas, kuru tīklu lietotnes procesam ir atļauts izmantot atrisināšanai, un Android negarantē, ka aktīvais VPN ir tas, ko izmanto jūsu ligzdas. Veiciet šīs pārbaudes secīgi un apstājieties, kad resolvera momentuzņēmums neatbilst jūsu pieņēmumam.

1. solis: pierādiet, kurā tīklā ir lietotne

Lasiet pašas lietotnes skatu, nevis statusjoslu. No ConnectivityManager iegūstiet aktīvo tīklu, tā LinkProperties, DNS serveru sarakstu un privātā DNS iestatījumu. Ja sarakstā ir VPN resolveris, lietotnei ir ceļš uz to; ja tajā ir Wi-Fi resolveris, tunelis nav noklusējuma tīkls šim procesam.

VPN ikona tikai norāda, ka tunelis pastāv. Tā nenorāda, ka lietotnes process bija ar to saistīts, un Android ne vienmēr maršrutē vārdu atrisināšanu caur tīklu, kas izskatās aktīvs. Vietējās VPN lietotnes, kas pārsūta uz citu ierīci, Wi-Fi tīkli bez interneta un ražotāja būves var atstāt lietotni jautājam noklusējuma resolverim, nevis tuneļa serveriem.

2. solis: pieprasiet VPN transportu un saistiet procesu

Kad lietotnei obligāti jāizmanto tuneļa resolveris, pieprasiet tīklu ar VPN transportu un saistiet procesu atzvanīšanas funkcijā, lai kods neuzminētu, kad tīkls parādīsies:

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

Izsaukums maina visa procesa noklusējuma tīklu, tāpēc katra pēc tam izveidotā ligzda to izmanto. Jau esošās ligzdas saglabā tīklu, kurā tās tika izveidotas, tāpēc pirms saistīšanas atvērtais savienojumu kopums var turpināt atrisināt pa veco ceļu. Atgrieztā vērtība ir loģiskā, un false rezultāts nozīmē, ka saistīšana nenotika; mēģiniet vēlreiz ar īsu aizkavi un reģistrējiet abus mēģinājumus.

3. solis: ierobežojiet saistīšanu ar to, kam tā nepieciešama

Visa procesa saistīšana ir rupja. Telemetrija, atjauninājumu pārbaudes un trešo pušu SDK arī pāriet uz tuneli, un, ja tunelim nav interneta, tie sāk neizdoties. Vienam pieprasījumam izmantojiet tīkla ligzdas fabriku un visu pārējo atstājiet ierīces noklusējumā. Apzināti izvēlieties vienu modeli: šauru saistīšanu katram savienojumam vai procesa saistīšanu ar skaidru atsaisti, kad VPN pazūd.

Divas resolvera funkcijas var pārspēt saistīšanu bez jebkādas kļūdas. Privātais DNS stingrā režīmā sūta vaicājumus uz nosauktu DoT serveri, nevis uz tīkla resolveri, un lietotne, kas ietver savu DNS-over-HTTPS klientu, pilnībā apiet sistēmas resolveri. Pārbaudiet abus, pirms secināt, ka saistīšana neizdevās. Vaicājums, kas nekad nesasniedz VPN DNS serveri, neparādīsies nevienā tuneļa puses žurnālā.

4. solis: neuzticieties CONNECTED ierobežojumam

NetworkType.CONNECTED WorkManager nozīmē, ka tīkls ir pievienots, un VPN transports to apmierina arī tad, kad pamatā esošais Wi-Fi vai šūnu savienojums ir zudis. Darbs tiek izpildīts, katrs pieprasījums neizdodas, un atkārtošanas politika to pārvērš vētrā, kas izskatās pēc plānošanas kļūdas. Tunelis ir tīkls; ierobežojums nekad nav bijis interneta pārbaude.

Pārbaudiet iespēju, kas darbam patiešām nepieciešama, piemēram, apstiprinātu interneta piekļuvi, un saglabājiet ierobežotu atkārtošanas politiku ar atkāpšanos. Ja darbam nepieciešams privāts vārds, atrisiniet šo vārdu izvēlētajā tīklā pirms darba veikšanas un ātri neizdodieties ar skaidru kļūdu, nevis atkārtojiet pieprasījumu, kas nevar izdoties.

5. solis: reģistrējiet pierādījumus un atkārtoti pārbaudiet diapazonu

Reģistrējiet izvēlētā tīkla transporta veidus, DNS serverus no LinkProperties, vai saistīšana atgrieza true, un precīzu pirmā pieprasījuma kļūmi. Pēc tam palaidiet privātu vārdu un publisku vārdu ar to pašu saistīšanu. Šis pāris parāda, vai lietotne izmantoja tuneļa resolveri vai klusi atkrita uz ierīces noklusējumu, un tā ir atšķirība, ko lietotājs izjūt.

Atkārtojiet vecākajā atbalstītajā Android versijā un vienā pašreizējā laidienā. Resolvera uzvedība, kas liek noklusējuma ceļam izskatīties pareizam, ir tieši tā vieta, kur ierīces un versijas atšķiras, un būve, kas iztur tikai jaunākajā testa ierīcē, nav pārbaudīta diapazonam, ko piegādājat. adb shell dumpsys connectivity ir ātrs veids, kā apstiprināt, kurus tīklus un iespējas ierīce ziņo, kamēr atkārtojat kļūmi.