Lugege Android DNS-i õigesti: võrgu kaupa, mitte resolv.conf-ist

Saate seadmes shelli, loete /etc/resolv.conf või kaevate välja vana net.dns1 väärtuse, ja saate ühe aadressi. Rakendus teie ees lahendab hoopis millegi muu kaudu. Praeguses Androidi versioonis on resolver võrgu kaupa: süsteem hoiab reeglit iga Network jaoks ja rakendab seda socketile, mis päringu saatis. Fail ja vana omadus on jäänused ning kumbki neist ei kirjelda teed, mille teie päring tegelikult läbis.

See lünk ilmneb split-tunneli ja Private DNS-i juurutamisel, kus kaks rakendust samas telefonis võivad õiguspäraselt näha erinevaid vastuseid. See juhend algab vale või puuduva lahendamise juurest ja liigub tagasi konfiguratsioonini, millele see kuulub.

Resolver kuulub võrgule, mitte seadmele

Nimede lahendamine Androidis 9 ja uuemates käib läbi süsteemse resolveri, mis toetub Network-ile, millega socket on seotud. Igal võrgul on oma LinkProperties ja need omadused sisaldavad DNS-serverite loendit, otsingudomeene ja Private DNS-i olekut ainult selle võrgu jaoks. Miski selles mudelis ei vasta ühele kogu seadme loendile, mida saaksite failist lugeda.

VPN teeb jaotuse ilmselgeks. Kui tunnel tõuseb, edastab VPN-i rakendus DNS-serverid, mis on registreeritud VPN-i enda võrgus, nii et selle kaudu suunatud rakendused lahendavad nende serverite kaudu, samal ajal kui väljajäetud rakendused kasutavad edasi alusvõrku. Üks seade, kaks vastuseteed, mingit vastuolu.

Lugege hetktõmmist kahjustatud rakenduse seest

Küsige rakenduselt endalt. Meetod, millel on Context ja tavaline luba android.permission.ACCESS_NETWORK_STATE, saab hetktõmmist lugeda süsteemiomadusi puutumata:

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 teie protsessi vaikevõrk, mitte seadme ainus võrk, ja see võib olla null, kui kutsujal pole kasutatavat vaikevõrku. Blokeeritud vaikimisi VPN on tavaline põhjus. isPrivateDnsActive ütleb, kas selle võrgu päringud lähevad TLS-i kaudu nimetatud resolverile, mis muudab seda, mida näitab lihtne UDP 53 sond. API pind on dokumenteeritud jaotises LinkProperties ja iga väärtus selles on konfiguratsiooni hetktõmmis, mitte tõestus, et konkreetne päring jõudis konkreetse serverini.

Kui vaikevõrk pole see, mis tööd teeb

Hetktõmmis vastab ainult vaikevõrgu eest. Rakendus võib siduda oma protsessi või ühe socketi teise võrguga ja siis järgib lahendamine seda valikut, samal ajal kui teie diagnostika teatab endiselt vaikevõrgust. Brauser, mis toob kaasa oma DNS-over-HTTPS resolveri, ei konsulteeri süsteemset loendit üldse, seega ei ütle selle vastused midagi ülejäänud seadme kohta. Tööprofiili rakendus töötab eraldi kasutaja all oma reegliga. Kontrollige sidumist, enne kui servereid süüdistate.

VPN-i integratsioon on teine pool. dhcp-option DNS rea vastuvõtmine OpenVPN profiilis ja selle aadressi registreerimine Androidi VPN-võrgus on kaks eraldi sammu ning puuduv marsruut serverini ebaõnnestub sama vaikselt kui vale aadress. Arendusmasinast trükib adb shell dumpsys connectivity samad lingiomadused võrgu kaupa, kui build seda lubab, mis kinnitab loendi ilma koodi kirjutamata.

Võrrelge konfiguratsiooni ühe lahendamisega, mille tegemine on lubatud

Valige nimi, mis tuleb privaatses nimeruumis lahendada, ja üks avalik nimi, ning kirjutage mõlemad tulemused hetktõmmise kõrvale: võrk, konfigureeritud serverid, Private DNS-i olek ja täpne veateade. Otsene päring nimetatud serverile tõestab, et see server teile vastab; see ei tõesta, et tavaline rakenduse lahendamine selle valis. Vahemällu salvestatud vastus pole värske test, seega tühjendage vahemälu või kasutage nime, mille kohta keegi täna ei küsinud.

Kui resolver teenindab ainult teatud juurdepääsuvõrgu kliente, võib see, mida ta pärast VPN-ist väljumist näeb, tulemuse otsustada, ja see on reegli küsimus sellele, kes seda haldab, mitte tõestus, et operaatorid blokeerivad UDP 53. Kus Private DNS on aktiivne, võidakse kvalifitseerimata hostinimi disaini järgi tagasi lükata, samal ajal kui sama server vastab avalikele nimedele tavaliselt. Omaduste lugemine ütleb, milline režiim kehtib, nii et te lõpetate paketifiltrite oletamise.

Parandage kiht, millele lahknevus kuulub

Töötage ülespoole, mitte ärge muutke globaalset olekut. Kui rakendus on seotud vale võrguga, parandage sidumine. Kui profiil edastab vale DNS-valiku, parandage profiil. Kui Private DNS on range võrgus, mille resolver ei suuda teie privaatset tsooni teenindada, on see seadmehalduse otsus, mitte põhjus funktsiooni kõikjal välja lülitada.

Avalike resolverite surumine DHCP-konksu või süsteemiomadusse on parandus, mis pidevalt põhjustab intsidente: privaatsed nimed lakkavad lahendamast, muudatus elab VPN-seansi üle ja järgmine inimene seadmes leiab aegunud aadressi ilma omanikuta. Hoidke muudatus VPN-i, rakenduse või halduskihi sees, millele lahknevus kuulub, ja seejärel lugege hetktõmmis uuesti, et kinnitada, et serverite loend tõesti muutus.

Lõpuks soovite ühte rakenduse päringut, mis on seotud ühe võrgu, resolverite loendi ja Private DNS-i olekuga. Kui suudate seda ahelat näidata, ei ole tuttav aadress failis enam millegi tõestus.