Una aplicació Android resol noms fora de la VPN: llista de verificació de la vinculació

Android pot resoldre noms per la xarxa per defecte mentre hi ha una VPN activa. Vincula el procés a la xarxa VPN i comprova quin resolutor ha fet servir realment l’aplicació.

Una aplicació Android no aconsegueix resoldre un nom intern mentre el navegador del client VPN hi arriba, i la mateixa compilació funciona en un altre telèfon. La variable no és la URL. La variable és quina xarxa pot fer servir el procés de l’aplicació per resoldre, i Android no garanteix que la VPN activa sigui la que fan servir els vostres sockets. Feu aquestes comprovacions en ordre i atureu-vos quan la instantània del resolutor no coincideixi amb la vostra suposició.

Pas 1: Demostreu en quina xarxa és l’aplicació

Llegiu la visió de la pròpia aplicació en lloc de la barra d’estat. Des de ConnectivityManager obteniu la xarxa activa, les seves LinkProperties , la llista de servidors DNS i el paràmetre de DNS privat. Si la llista conté el resolutor de la VPN, l’aplicació hi té camí; si conté el resolutor del Wi-Fi, el túnel no és la xarxa per defecte d’aquell procés.

Una icona de VPN només diu que hi ha un túnel. No diu que el procés de l’aplicació hi estigui vinculat, i Android no sempre encamina la resolució de noms per la xarxa que sembla activa. Les aplicacions VPN locals que reenvien a un altre dispositiu, les xarxes Wi-Fi sense internet i les compilacions dels fabricants poden fer que una aplicació pregunti el resolutor per defecte en lloc dels servidors del túnel.

Pas 2: Demaneu el transport VPN i vinculeu el procés

Quan l’aplicació ha de fer servir el resolutor del túnel, demaneu una xarxa amb el transport VPN i vinculeu el procés al callback, perquè el codi no endevini quan apareix la xarxa:

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

La crida canvia la xarxa per defecte de tot el procés, de manera que cada socket creat després la fa servir. Els sockets que ja existeixen conserven la xarxa on es van crear, i per això un pool de connexions obert abans de la vinculació pot continuar resolent pel camí antic. El valor retornat és un booleà, i un resultat false vol dir que la vinculació no s’ha fet; torneu-ho a provar amb un retard curt i registreu tots dos intents.

Pas 3: Limiteu la vinculació al que la necessita

La vinculació a tot el procés és grollera. La telemetria, les comprovacions d’actualització i els SDK de tercers també passen al túnel, i si el túnel no té internet comencen a fallar. Per a una sola petició, feu servir la fàbrica de sockets de la xarxa i manteniu el valor per defecte del dispositiu per a tota la resta. Trieu un model deliberadament: una vinculació estreta per connexió, o una vinculació de procés amb un desvinculament explícit quan la VPN desaparegui.

Dues funcions del resolutor poden derrotar la vinculació sense cap error. El DNS privat en mode estricte envia les consultes a un servidor DoT amb nom en lloc del resolutor de la xarxa, i una aplicació que porta el seu propi client DNS-over-HTTPS evita del tot el resolutor del sistema. Comproveu les dues coses abans de concloure que la vinculació ha fallat. Una consulta que no arriba mai al servidor DNS de la VPN no apareixerà en cap registre del costat del túnel.

Pas 4: No confieu en una restricció CONNECTED

El NetworkType.CONNECTED de WorkManager significa que hi ha una xarxa connectada, i el transport VPN la satisfà fins i tot quan l’enllaç Wi-Fi o mòbil subjacent ha desaparegut. La tasca s’executa, cada petició falla, i la política de reintents la converteix en una tempesta que sembla un error de planificació. El túnel és una xarxa; la restricció mai no va ser una comprovació d’internet.

Comproveu la capacitat que la feina necessita de veritat, com ara accés a internet validat, i manteniu una política de reintents limitada amb retrocés. Si la feina necessita un nom intern, resoleu aquest nom a la xarxa seleccionada abans de fer la feina, i fallau ràpid amb un error clar en lloc de repetir una petició que no pot tenir èxit.

Pas 5: Registreu les proves i torneu a testar el rang

Registreu els tipus de transport de la xarxa seleccionada, els servidors DNS de LinkProperties , si la vinculació ha retornat true i la fallada exacta de la primera petició. Després executeu un nom intern i un nom públic sota la mateixa vinculació. Aquesta parella mostra si l’aplicació ha fet servir el resolutor del túnel o ha caigut en silenci al valor per defecte del dispositiu, i aquesta és la diferència que viu l’usuari.

Repetiu-ho a la versió d’Android més antiga que suporteu i en una versió actual. El comportament del resolutor que fa que el camí per defecte sembli correcte és exactament on difereixen dispositius i versions, i una compilació que només passa al dispositiu de prova més nou no està verificada per al rang que distribuïu. adb shell dumpsys connectivityés una manera ràpida de confirmar quines xarxes i capacitats informa el dispositiu mentre reproduïu la fallada.

Articles relacionats