Android-app løyser namn utanfor VPN-en: sjekkliste for binding

Ein Android-app får ikkje løyst eit internt namn medan nettlesaren til sjølve VPN-klienten når det, og same byggjet fungerer på ein annan telefon. URL-en er ikkje variabelen. Variabelen er kva nettverk prosessen til appen har lov til å bruka for oppløysing, og Android garanterer ikkje at den aktive VPN-en er den nettverket sokkane dine brukar. Gjer desse kontrollane i rekkjefølgje og stopp når resolver-augneblinksbiletet ikkje stemmer med føresetnaden din.

Steg 1: prov kva nettverk appen er på

Les appen sitt eige oversyn i staden for statuslinja. Frå ConnectivityManager hentar du det aktive nettverket, LinkProperties til det, lista over DNS-tenarar og innstillinga for privat DNS. Viss lista inneheld resolveren til VPN-en, har appen ein veg til han; viss ho inneheld resolveren til Wi-Fi, er tunnelen ikkje standardnettverket for den prosessen.

Eit VPN-ikon seier berre at ein tunnel finst. Det seier ikkje at prosessen til appen var bunden til han, og Android ruter ikkje alltid namneoppløysing gjennom nettverket som ser aktivt ut. Lokale VPN-appar som videresender til ein annan eining, Wi-Fi-nettverk utan internett og bygg frå produsenten kan alle gjera at appen spør standardresolveren i staden for tenarane til tunnelen.

Steg 2: be om VPN-transporten og bind prosessen

Når appen må bruka resolveren til tunnelen, ber du om eit nettverk med VPN-transport og bind prosessen i tilbakekallet, slik at koden ikkje gissar på når nettverket dukkar opp:

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

Kallet endrar standardnettverket for heile prosessen, så kvar sokkel som blir laga etterpå, brukar det. Sokklar som alt finst, held på nettverket dei vart laga på, og difor kan ein tilkoplingspool som vart opna før bindinga, halda fram med å løysa via den gamle vegen. Returverdien er ein boolean, og eit resultat på false tyder at bindinga ikkje skjedde; prøv om att med ei kort forseinking og logg båe forsøka.

Steg 3: avgrens bindinga til det som treng ho

Binding for heile prosessen er grov. Telemetri, oppdateringskontrollar og SDK-ar frå tredjepart flyttar òg over til tunnelen, og viss tunnelen ikkje har internett, byrjar dei å feila. For éin førespurnad brukar du sokkel fabrikken til nettverket og lèt standarden til eininga gjelda for alt anna. Vel medvite éin modell: smal binding per tilkoping, eller prosessbinding med ei tydeleg avbinding når VPN-en forsvinn.

To resolverfunksjonar kan slå bindinga utan nokon feil. Privat DNS i streng modus sender spørjingar til ein namngjeven DoT-tenar i staden for resolveren til nettverket, og ein app som har sin eigen DNS-over-HTTPS-klient, går heilt utanom resolveren i systemet. Sjekk båe før du konkluderer med at bindinga feila. Ei spørjing som aldri når DNS-tenaren til VPN-en, vil ikkje dukka opp i nokon logg på tunnelsida.

Steg 4: ikkje stol på eit CONNECTED-vilkår

NetworkType.CONNECTED i WorkManager tyder at eit nettverk er tilkopla, og VPN-transporten oppfyller det sjølv når den underliggjande Wi-Fi- eller mobillenkja er borte. Jobben køyrer, kvar førespurnad feilar, og retry-policyen gjer det til ein storm som ser ut som ein planleggingsfeil. Tunnelen er eit nettverk; vilkåret var aldri ein internettkontroll.

Sjekk evna som arbeidet faktisk treng, til dømes stadfesta internettilgang, og hald på ein avgrensa retry-policy med backoff. Viss jobben treng eit privat namn, løys det namnet i det valde nettverket før du gjer arbeidet, og feil raskt med ein tydeleg feil i staden for å gjenta ein førespurnad som ikkje kan lukkast.

Steg 5: registrer prova og test området på nytt

Logg transporttypane til det valde nettverket, DNS-tenarane frå LinkProperties, om bindinga returnerte true, og den nøyaktige feilen til den første førespurnaden. Køyr så eit privat namn og eit offentleg namn under same bindinga. Det paret viser om appen bruka resolveren til tunnelen eller fall stille tilbake til standarden til eininga, og det er skilnaden brukaren opplever.

Gjenta på den eldste Android-versjonen du støttar, og på éin gjeldande utgiving. Åtferda til resolveren som gjer at standardvegen ser rett ut, er nettopp der einingar og versjonar skil seg, og eit bygg som berre går gjennom på den nyaste testeinga, er ikkje stadfesta for området du sender ut. adb shell dumpsys connectivity er ein rask måte å stadfesta kva nettverk og evner eininga rapporterer medan du reproduserer feilen.