Skaitykite Android DNS teisingai: pagal tinklą, ne resolv.conf

Jūsų Android programėlė sprendžia per kiekvieno tinklo resolver, o ne per ką tik perskaitytą resolv.conf. Pirmiausia patikrinkite LinkProperties, socket susiejimus ir Private DNS.

Gaunate apvalkalą įrenginyje, perskaitote /etc/resolv.conf arba iškrapštote seną net.dns1 reikšmę, ir gaunate vieną adresą. Programėlė priešais jus sprendžia per visiškai ką kita. Dabartinėje Android versijoje resolver yra pagal tinklą: sistema laiko taisyklę kiekvienam Network ir taiko ją lizdui, kuris išsiuntė užklausą. Failas ir sena savybė yra likučiai, ir nė vienas jų neaprašo kelio, kuriuo jūsų užklausa iš tikrųjų ėjo.

Šis atotrūkis pasimato diegiant split-tunnel ir Private DNS, kai dvi programėlės tame pačiame telefone teisėtai mato skirtingus atsakymus. Šis vadovas pradeda nuo neteisingo arba trūkstamo sprendimo ir eina atgal prie konfigūracijos, kuriai jis priklauso.

Resolver priklauso tinklui, o ne įrenginiui

Vardų sprendimas Android 9 ir naujesnėse versijose eina per sistemos resolver, kuris remiasi Network, prie kurio prijungtas lizdas. Kiekvienas tinklas turi savo LinkProperties, ir tos savybės talpina DNS serverių sąrašą, paieškos domenus ir Private DNS būseną tik tam tinklui. Niekas tame modelyje neatitinka vieno viso įrenginio sąrašo, kurį galėtumėte perskaityti iš failo.

VPN padaro padalijimą akivaizdų. Kai tunelis pakyla, VPN programėlė pateikia DNS serverius, užregistruotus pačiame VPN tinkle, todėl per jį nukreiptos programėlės sprendžia per tuos serverius, o neįtrauktos programėlės toliau naudoja po jais esantį tinklą. Vienas įrenginys, du atsakymo keliai, jokio prieštaravimo.

Perskaitykite momentinę kopiją pačioje paveiktoje programėlėje

Paklauskite pačios programėlės. Metodas, turintis Context ir įprastą leidimą android.permission.ACCESS_NETWORK_STATE, gali perskaityti momentinę kopiją neliesdamas sisteminių savybių:

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 yra numatytasis jūsų procesui tinklas, o ne vienintelis įrenginio tinklas, ir gali būti null, kai iškvietėjas neturi tinkamo numatytojo. Užblokuotas numatytasis VPN yra įprasta priežastis. isPrivateDnsActive pasako, ar užklausos tame tinkle eina per TLS į įvardytą resolver, o tai keičia, ką parodys paprasta UDP 53 patikra. API paviršius dokumentuotas LinkProperties skyriuje, ir kiekviena reikšmė jame yra konfigūracijos momentinė kopija, o ne įrodymas, kad konkreti užklausa pasiekė konkretų serverį.

Kai numatytasis tinklas nėra tas, kuris atlieka darbą

Momentinė kopija atsako tik už numatytąjį tinklą. Programėlė gali susieti savo procesą arba vieną lizdą su kitu tinklu, ir tada sprendimas seka tuo pasirinkimu, kol jūsų diagnostika vis dar praneša apie numatytąjį. Naršyklė su savo DNS-over-HTTPS resolver visai nesikreipia į sistemos sąrašą, todėl jos atsakymai nieko nesako apie likusį įrenginį. Darbo profilio programėlė veikia atskiro naudotojo teisėmis su savo taisykle. Patikrinkite susiejimą, prieš kaltindami serverius.

VPN integracija yra kita pusė. Priimti dhcp-option DNS eilutę OpenVPN profilyje ir užregistruoti tą adresą Android VPN tinkle yra du atskiri žingsniai, o trūkstamas maršrutas į serverį nepavyksta taip pat tyliai kaip neteisingas adresas. Iš kūrimo mašinos adb shell dumpsys connectivity išspausdina tas pačias ryšio savybes pagal tinklą, kai kūrimas tai leidžia, o tai patvirtina sąrašą nerašant kodo.

Palyginkite konfigūraciją su vienu sprendimu, kurį leidžiama atlikti

Pasirinkite vardą, kuris turi būti išspręstas privačioje vardų erdvėje, ir vieną viešą vardą, ir užrašykite abu rezultatus šalia momentinės kopijos: tinklas, sukonfigūruoti serveriai, Private DNS būsena ir tikslus klaidos tekstas. Tiesioginė užklausa įvardytam serveriui įrodo, kad tas serveris jums atsako; ji neįrodo, kad įprastas programėlės sprendimas jį pasirinko. Atsakymas iš podėlio nėra šviežias testas, todėl išvalykite podėlį arba naudokite vardą, kurio šiandien niekas neprašė.

Jei resolver aptarnauja tik konkrečio prieigos tinklo klientus, tai, ką jis mato po išėjimo iš VPN, gali nulemti rezultatą, ir tai yra taisyklės klausimas tam, kas jį valdo, o ne įrodymas, kad operatoriai blokuoja UDP 53. Ten, kur Private DNS aktyvus, nekvalifikuotas domeno vardas gali būti atmestas pagal sumanymą, kol tas pats serveris įprastai atsako į viešus vardus. Savybių skaitymas pasako, kuris režimas galioja, todėl nustojate spėlioti paketų filtrus.

Pataisykite sluoksnį, kuriam priklauso neatitikimas

Dirbkite aukštyn, o ne redaguokite globalią būseną. Jei programėlė susieta su netinkamu tinklu, pataisykite susiejimą. Jei profilis pateikia netinkamą DNS parinktį, pataisykite profilį. Jei Private DNS griežtas tinkle, kurio resolver negali aptarnauti jūsų privačios zonos, tai įrenginio valdymo sprendimas, o ne priežastis išjungti funkciją visur.

Viešų resolver stūmimas į DHCP kabliuką ar sisteminę savybę yra taisymas, kuris nuolat sukelia incidentus: privatūs vardai nustoja spręsti, pakeitimas pergyvena VPN sesiją, ir kitas žmogus įrenginyje randa pasenusį adresą be šeimininko. Laikykite pakeitimą VPN, programėlės ar valdymo sluoksnyje, kuriam priklauso neatitikimas, ir tada dar kartą perskaitykite momentinę kopiją, kad patvirtintumėte, jog serverių sąrašas tikrai pasikeitė.

Galiausiai norite vienos programėlės užklausos, susietos su vienu tinklu, resolver sąrašu ir Private DNS būsena. Kai galite parodyti tą grandinę, pažįstamas adresas faile nebėra nieko įrodymas.

Susiję straipsniai