Android-sovellus ratkaisee nimiä VPN:n ulkopuolella: sidonnan tarkistuslista

Android-sovellus ei saa ratkaistua sisäistä nimeä, vaikka VPN-asiakasohjelman oma selain tavoittaa sen, ja sama build toimii toisessa puhelimessa. Muuttuja ei ole URL. Muuttuja on se, mitä verkkoa sovelluksen prosessi saa käyttää ratkaisemiseen, eikä Android takaa, että aktiivinen VPN on se, jota sokettisi käyttävät. Käy nämä tarkistukset järjestyksessä ja pysähdy, kun ratkaisijan tilannekuva ei vastaa oletustasi.

Vaihe 1: Todista, missä verkossa sovellus on

Lue sovelluksen oma näkymä tilapalkin sijaan. Hae ConnectivityManager kautta aktiivinen verkko, sen LinkProperties , DNS-palvelimien luettelo ja yksityisen DNS:n asetus. Jos luettelossa on VPN:n ratkaisija, sovelluksella on polku siihen; jos siinä on Wi-Fi-ratkaisija, tunneli ei ole kyseisen prosessin oletusverkko.

VPN-kuvake kertoo vain, että tunneli on olemassa. Se ei kerro, että sovelluksen prosessi sidottiin siihen, eikä Android ohjaa nimien ratkaisua aina verkon kautta, joka näyttää aktiiviselta. Paikalliset VPN-sovellukset, jotka välittävät toiselle laitteelle, ilman internetyhteyttä olevat Wi-Fi-verkot ja valmistajien buildit voivat saada sovelluksen kysymään oletusratkaisijalta tunnelin palvelimien sijaan.

Vaihe 2: Pyydä VPN-siirtoa ja sido prosessi

Kun sovelluksen on käytettävä tunnelin ratkaisijaa, pyydä verkkoa VPN-siirrolla ja sido prosessi callbackissa, jotta koodi ei arvaa, milloin verkko ilmestyy:

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

Kutsu vaihtaa koko prosessin oletusverkon, joten jokainen sen jälkeen luotu soketti käyttää sitä. Jo olemassa olevat soketit säilyttävät verkon, johon ne luotiin, ja siksi ennen sidontaa avattu yhteyspooli voi jatkaa ratkaisemista vanhaa polkua pitkin. Paluuarvo on boolean, ja false tarkoittaa, että sidontaa ei tapahtunut; yritä uudelleen lyhyen viiveen jälkeen ja kirjaa molemmat yritykset.

Vaihe 3: Rajaa sidonta siihen, mikä sitä tarvitsee

Koko prosessin sidonta on karkeaa. Telemetria, päivitystarkistukset ja kolmannen osapuolen SDK:t siirtyvät myös tunneliin, ja jos tunnelissa ei ole internetyhteyttä, ne alkavat epäonnistua. Yhtä pyyntöä varten käytä verkon sokettitehdasta ja pidä laitteen oletus kaikelle muulle. Valitse tietoisesti yksi malli: kapea sidonta yhteyttä kohden tai prosessin sidonta ja eksplisiittinen irrotus, kun VPN katoaa.

Kaksi ratkaisijan ominaisuutta voi voittaa sidonnan ilman mitään virhettä. Yksityinen DNS tiukassa tilassa lähettää kyselyt nimetylle DoT-palvelimelle verkon ratkaisijan sijaan, ja sovellus, joka tuo mukanaan oman DNS-over-HTTPS-asiakasohjelmansa, ohittaa järjestelmän ratkaisijan kokonaan. Tarkista molemmat ennen kuin päättelet sidonnan epäonnistuneen. Kysely, joka ei koskaan saavuta VPN:n DNS-palvelinta, ei näy missään tunnelin puolen lokissa.

Vaihe 4: Älä luota CONNECTED-rajoitteeseen

WorkManagerin NetworkType.CONNECTED tarkoittaa, että verkko on yhdistetty, ja VPN-siirto täyttää sen myös silloin, kun alla oleva Wi-Fi- tai matkapuhelinlinkki on poissa. Työ ajetaan, jokainen pyyntö epäonnistuu ja uudelleenyrityskäytäntö muuttaa sen myrskyksi, joka näyttää ajoitusbugilta. Tunneli on verkko; rajoite ei koskaan ollut internettarkistus.

Tarkista kyvykkyys, jota työ todella tarvitsee, kuten vahvistettu internetyhteys, ja pidä rajoitettu uudelleenyrityskäytäntö takaisinvedolla. Jos työ tarvitsee sisäisen nimen, ratkaise se nimi valitussa verkossa ennen työn tekemistä ja epäonnistu nopeasti selkeällä virheellä sen sijaan, että toistat pyynnön, joka ei voi onnistua.

Vaihe 5: Kirjaa todisteet ja testaa alue uudelleen

Kirjaa valitun verkon siirtotyypit, DNS-palvelimet LinkProperties , palauttiko sidonta true-arvon ja ensimmäisen pyynnön tarkka epäonnistuminen. Aja sitten sisäinen ja julkinen nimi saman sidonnan alla. Tämä pari näyttää, käyttikö sovellus tunnelin ratkaisijaa vai putosiko se hiljaa laitteen oletukseen, ja juuri sen eron käyttäjä kokee.

Toista vanhimmassa tukemassasi Android-versiossa ja yhdessä nykyisessä versiossa. Ratkaisijan käyttäytyminen, joka saa oletuspolun näyttämään oikealta, on juuri siinä, missä laitteet ja versiot eroavat, eikä build, joka läpäisee vain uusimmalla testilaitteella, ole vahvistettu sille alueelle, jonka toimitat. adb shell dumpsys connectivityon nopea tapa vahvistaa, mitkä verkot ja kyvykkyydet laite ilmoittaa, kun toistat vikaa.