Android-app los name buite die VPN op: n kontrolelys vir binding

n Android-app slaag nie daarin om n interne naam op te los nie, terwyl die VPN-kliënt se eie blaaier dit wel bereik, en dieselfde bou werk op n ander foon. Die URL is nie die veranderlike nie. Die veranderlike is watter netwerk die app-proses vir oplossing mag gebruik, en Android waarborg nie dat die aktiewe VPN die een is wat jou sokkels gebruik nie. Werk hierdie kontroles in volgorde deur en stop wanneer die oplosser-snapshot nie met jou aanname ooreenstem nie.

Stap 1: Bewys op watter netwerk die app is

Lees die app se eie siening eerder as die statusbalk. Kry uit ConnectivityManager die aktiewe netwerk, sy LinkProperties, die DNS-bedienerlys en die private DNS-instelling. As die lys die VPN se oplosser bevat, het die app n pad daarheen; as dit die Wi-Fi-oplosser bevat, is die tonnel nie die versteknetwerk vir daardie proses nie.

n VPN-ikoon sê net dat n tonnel bestaan. Dit sê nie dat die app se proses daaraan gebind is nie, en Android stuur naamoplossing nie altyd deur die netwerk wat aktief lyk nie. Plaaslike VPN-apps wat na n ander toestel deurstuur, Wi-Fi-netwerke sonder internet en vervaardigerboue kan almal veroorsaak dat n app die verstekoplosser vra in plaas van die tonnel se bedieners.

Stap 2: Vra die VPN-transport aan en bind die proses

Wanneer die app die tonnel se oplosser moet gebruik, vra n netwerk met die VPN-transport aan en bind die proses in die callback, sodat die kode nie raai wanneer die netwerk verskyn nie:

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

Die oproep verander die proseswye versteknetwerk, sodat elke sokkel wat daarna geskep word dit gebruik. Sokkels wat reeds bestaan, behou die netwerk waarop hulle geskep is, en daarom kan n verbindingspoel wat voor die binding oopgemaak is, steeds deur die ou pad oplos. Die terugkeerwaarde is n boolean, en n valse resultaat beteken die binding het nie gebeur nie; probeer weer na n kort vertraging en teken beide pogings aan.

Stap 3: Beperk die binding tot wat dit nodig het

Proseswye binding is grof. Telemetrie, opdateringskontroles en derdeparty-SDKs skuif ook na die tonnel, en as die tonnel geen internet het nie, begin hulle misluk. Vir n enkele versoek gebruik die netwerk se sokkel-fabriek en hou die toestelverstek vir alles anders. Kies doelbewus een model: n nou binding per verbinding, of n prosesbinding met n eksplisiete ontbinding wanneer die VPN verdwyn.

Twee oplosser-kenmerke kan die binding sonder enige fout verydel. Private DNS in streng modus stuur navrae na n genoemde DoT-bediener in plaas van die netwerkoplosser, en n app wat sy eie DNS-over-HTTPS-kliënt saambring, omseil die stelseloplosser heeltemal. Kontroleer albei voordat jy aflei dat die binding misluk het. n Navraag wat nooit die VPN se DNS-bediener bereik nie, sal in geen tonnelkantige log verskyn nie.

Stap 4: Moenie n CONNECTED-beperking vertrou nie

WorkManager se NetworkType.CONNECTEDbeteken n netwerk is gekonnekteer, en die VPN-transport voldoen daaraan selfs wanneer die onderliggende Wi-Fi- of sellulêre skakel weg is. Die werk loop, elke versoek misluk, en die herprobeerbeleid maak daarvan n storm wat soos n skeduleringsfout lyk. Die tonnel is n netwerk; die beperking was nooit n internetkontrole nie.

Kontroleer die vermoë wat die werk werklik nodig het, soos gevalideerde internettoegang, en hou n beperkte herprobeerbeleid met terugtrekking. As die werk n interne naam nodig het, los daardie naam in die gekose netwerk op voordat jy die werk doen, en misluk vinnig met n duidelike fout eerder as om n versoek te herhaal wat nie kan slaag nie.

Stap 5: Teken die bewyse aan en toets die reeks weer

Teken die gekose netwerk se transporttipes aan, die DNS-bedieners uit LinkProperties, of die binding waar teruggegee het, en die eerste versoek se presiese fout. Voer dan n interne naam en n openbare naam onder dieselfde binding uit. Daardie paar wys of die app die tonneloplosser gebruik het of stilweg na die toestelverstek teruggeval het, en dit is die verskil wat die gebruiker ervaar.

Herhaal op die oudste Android-weergawe wat jy ondersteun en op een huidige weergawe. Die oplosser-gedrag wat die verstekpad korrek laat lyk, is juis waar toestelle en weergawes verskil, en n bou wat net op die nuutste toestel slaag, is nie vir die reeks wat jy lewer geverifieer nie. adb shell dumpsys connectivityis n vinnige manier om te bevestig watter netwerke en vermoëns die toestel rapporteer terwyl jy die fout reproduseer.