Lue Android-DNS oikein: verkon mukaan, ei resolv.confista

Saat kuoren laitteeseen, luet /etc/resolv.conf tai kaivat esiin vanhan net.dns1-arvon, ja saat yhden osoitteen. Edessäsi oleva sovellus ratkaisee nimet aivan jostain muusta. Nykyisessä Android-julkaisussa resolver on verkkokohtainen: järjestelmä pitää käytäntöä jokaiselle Network-verkolle ja soveltaa sitä siihen socketiin, joka pyynnön lähetti. Tiedosto ja vanha ominaisuus ovat jäänteitä, eikä kumpikaan niistä kuvaa sitä polkua, jonka kyselysi todella kulki.

Tämä ero näkyy split-tunnelin ja Private DNS:n käyttöönotossa, jossa kaksi sovellusta samassa puhelimessa voi laillisesti nähdä eri vastaukset. Tämä opas alkaa väärästä tai puuttuvasta ratkaisusta ja etenee takaisin siihen konfiguraatioon, jolle se kuuluu.

Resolver kuuluu verkolle, ei laitteelle

Nimien ratkaisu Android 9:ssä ja uudemmissa kulkee järjestelmän resolverin kautta, joka perustuu siihen Network-verkkoon, johon socket on sidottu. Jokaisella verkolla on omat LinkProperties-tietonsa, ja nämä ominaisuudet sisältävät DNS-palvelinluettelon, hakudomainit ja Private DNS -tilan vain kyseiselle verkolle. Mikään mallissa ei vastaa yhtä koko laitteen laajuista luetteloa, jonka voisit lukea tiedostosta.

VPN tekee jaon ilmeiseksi. Kun tunneli nousee, VPN-sovellus toimittaa DNS-palvelimet, jotka on rekisteröity VPN:n omaan verkkoon, joten sen kautta reititetyt sovellukset ratkaisevat nimet näiden palvelimien kautta, kun taas pois jätetyt sovellukset käyttävät edelleen alla olevaa verkkoa. Yksi laite, kaksi vastauspolkua, ei ristiriitaa.

Lue tilannekuva kohdesovelluksen sisältä

Kysy sovellukselta itseltään. Metodi, jolla on Context ja tavallinen android.permission.ACCESS_NETWORK_STATE -lupa, voi lukea tilannekuvan koskematta järjestelmäominaisuuksiin:

val cm = getSystemService(ConnectivityManager::class.java) ?: return
val network = cm.activeNetwork
val links = network?.let { cm.getLinkProperties(it) }

val dnsServers = links?.dnsServers
val privateDnsActive = links?.isPrivateDnsActive
val privateDnsName = links?.privateDnsServerName

activeNetwork on prosessisi oletusverkko, ei laitteen ainoa verkko, ja se voi olla null, kun kutsujalla ei ole käyttökelpoista oletusta. Estetty oletus-VPN on tavallinen syy. isPrivateDnsActive kertoo, kulkevatko kyseisen verkon kyselyt TLS:n kautta nimettyyn resolveriin, mikä muuttaa sitä, mitä yksinkertainen UDP 53 -koetin näyttää. API-pinta on dokumentoitu kohdassa LinkProperties, ja jokainen sen arvo on tilannekuva konfiguraatiosta, ei todiste siitä, että tietty kysely saavutti tietyn palvelimen.

Kun oletusverkko ei ole se, joka tekee työn

Tilannekuva vastaa vain oletusverkosta. Sovellus voi sitoa prosessinsa tai yhden socketin toiseen verkkoon, ja silloin nimien ratkaisu seuraa tätä valintaa, kun taas diagnostiikkasi raportoi edelleen oletusverkkoa. Selain, joka tuo mukanaan oman DNS-over-HTTPS-resolverinsa, ei konsultoi järjestelmän luetteloa lainkaan, joten sen vastaukset eivät kerro mitään muusta laitteesta. Työprofiilin sovellus toimii erillisen käyttäjän alla omalla käytännöllään. Tarkista sidonta ennen kuin syytät palvelimia.

VPN-integraatio on toinen puoli. dhcp-option DNS -rivin vastaanottaminen OpenVPN-profiilissa ja kyseisen osoitteen rekisteröiminen Androidin VPN-verkkoon ovat kaksi erillistä vaihetta, ja puuttuva reitti palvelimelle epäonnistuu yhtä hiljaa kuin väärä osoite. Kehityskoneelta adb shell dumpsys connectivity tulostaa samat linkkiominaisuudet verkkokohtaisesti, kun build sen sallii, mikä vahvistaa luettelon kirjoittamatta koodia.

Vertaa konfiguraatiota yhteen ratkaisuun, jonka saat tehdä

Valitse nimi, joka on ratkaistava yksityisessä nimiavaruudessa, ja yksi julkinen nimi, ja kirjaa molemmat tulokset tilannekuvan viereen: verkko, määritetyt palvelimet, Private DNS -tila ja virheen tarkka teksti. Suora kysely nimetylle palvelimelle todistaa, että tuo palvelin vastaa sinulle; se ei todista, että tavallinen sovelluksen nimien ratkaisu valitsi sen. Välimuistissa oleva vastaus ei ole tuore testi, joten tyhjennä välimuisti tai käytä nimeä, jota kukaan ei ole tänään kysynyt.

Jos resolver palvelee vain tietyn liityntäverkon asiakkaita, se, mitä se näkee VPN-poistumisen jälkeen, voi ratkaista lopputuloksen, ja se on käytäntökysymys sille, joka sitä hallinnoi, ei todiste siitä, että operaattorit estävät UDP 53:n. Missä Private DNS on aktiivinen, kvalifioimaton isäntänimi voidaan hylätä suunnittelun mukaan, kun taas sama palvelin vastaa julkisiin nimiin normaalisti. Ominaisuuksien lukeminen kertoo, mikä tila on voimassa, joten lopetat pakettisuodattimien arvailun.

Korjaa kerros, jolle ristiriita kuuluu

Työskentele ylöspäin sen sijaan että muokkaisit globaalia tilaa. Jos sovellus on sidottu väärään verkkoon, korjaa sidonta. Jos profiili toimittaa väärän DNS-vaihtoehdon, korjaa profiili. Jos Private DNS on tiukka verkossa, jonka resolver ei voi palvella yksityistä aluettasi, se on laitehallinnan päätös, ei syy kytkeä ominaisuutta pois päältä kaikkialla.

Julkisten resolverien työntäminen DHCP-koukkuun tai järjestelmäominaisuuteen on korjaus, joka aiheuttaa jatkuvasti häiriöitä: yksityiset nimet lakkaavat ratkeamasta, muutos elää VPN-istunnon yli, ja seuraava ihminen laitteella löytää vanhentuneen osoitteen ilman omistajaa. Pidä muutos VPN:n, sovelluksen tai hallintakerroksen sisällä, jolle ristiriita kuuluu, ja lue sitten tilannekuva uudelleen vahvistaaksesi, että palvelinluettelo todella muuttui.

Lopulta haluat yhden sovelluspyynnön, joka on sidottu yhteen verkkoon, resolveriluetteloon ja Private DNS -tilaan. Kun pystyt näyttämään tuon ketjun, tuttu osoite tiedostossa ei ole enää todiste mistään.