Чытайце Android DNS правільна: па сетцы, а не ў resolv.conf

Вы атрымліваеце shell на прыладзе, чытаеце /etc/resolv.conf або выкопваеце старое значэнне net.dns1, і атрымліваеце адзін адрас. Праграма перад вамі развязвае імёны праз нешта зусім іншае. У бягучай версіі Android resolver існуе для кожнай сеткі: сістэма трымае палітыку для кожнага Network і прымяняе яе да сокета, які адправіў запыт. Файл і старая ўласцівасць — рэшткі, і ні адно з іх не апісвае шлях, які ваш запыт сапраўды прайшоў.

Гэты разрыў праяўляецца падчас укаранення split-tunnel і Private DNS, дзе дзве праграмы на адным тэлефоне могуць законна бачыць розныя адказы. Гэты дапаможнік пачынаецца з памылковага або адсутнага развязання і ідзе назад да канфігурацыі, якой яно належыць.

Resolver належыць сетцы, а не прыладзе

Развязанне імёнаў у Android 9 і навейшых ідзе праз сістэмны resolver, які абапіраецца на Network, да якой прывязаны сокет. Кожная сетка нясе ўласныя LinkProperties, і гэтыя ўласцівасці ўтрымліваюць спіс DNS-сервераў, дамены пошуку і стан Private DNS толькі для гэтай сеткі. Нішто ў гэтай мадэлі не адпавядае адзінаму спісу на ўсю прыладу, які можна прачытаць з файла.

VPN робіць падзел відавочным. Калі тунель падымаецца, праграма VPN перадае DNS-серверы, зарэгістраваныя ва ўласнай сетцы VPN, таму праграмы, накіраваныя праз яго, развязваюць імёны праз гэтыя серверы, а выключаныя праграмы далей выкарыстоўваюць сетку пад імі. Адна прылада, два шляхі адказу, ніякага супярэчання.

Прачытайце здымак знутры пацярпелай праграмы

Спытайце саму праграму. Метад, які мае Context і звычайны дазвол android.permission.ACCESS_NETWORK_STATE, можа прачытаць здымак, не кранаючы сістэмных уласцівасцей:

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 — гэта сетка па змаўчанні для вашага працэсу, а не адзіная сетка на прыладзе, і яна можа быць null, калі ў выклікальніка няма прыдатнай сеткі па змаўчанні. Заблакаваная VPN па змаўчанні — звычайная прычына. isPrivateDnsActive паведамляе, ці запыты ў гэтай сетцы ідуць праз TLS да найменаванага resolver, што змяняе тое, што пакажа простая проба UDP 53. Паверхня API апісана ў LinkProperties, і кожнае значэнне ў ёй — здымак канфігурацыі, а не доказ, што пэўны запыт дайшоў да пэўнага сервера.

Калі сетка па змаўчанні — не тая, што выконвае працу

Здымак адказвае толькі за сетку па змаўчанні. Праграма можа прывязаць свой працэс або адзін сокет да іншай сеткі, і тады развязанне ідзе за гэтым выбарам, пакуль ваша дыягностыка ўсё яшчэ паведамляе пра сетку па змаўчанні. Браўзер з уласным DNS-over-HTTPS resolver зусім не звяртаецца да сістэмнага спісу, таму яго адказы нічога не кажуць пра астатнюю частку прылады. Праграма працоўнага профілю працуе пад асобным карыстальнікам са сваёй палітыкай. Праверце прывязку, перш чым вінаваціць серверы.

Інтэграцыя з VPN — другая палова. Атрымаць радок dhcp-option DNS у профілі OpenVPN і зарэгістраваць гэты адрас у сетцы VPN Android — гэта два асобныя крокі, і адсутны маршрут да сервера збоіць так жа ціха, як няправільны адрас. З машыны распрацоўшчыка adb shell dumpsys connectivity друкуе тыя ж уласцівасці злучэння па сетцы, калі зборка гэта дазваляе, што пацвярджае спіс без напісання кода.

Параўнайце канфігурацыю з адным развязаннем, якое вам дазволена

Выберыце імя, якое павінна развязвацца ў прыватнай прасторы імёнаў, і адно публічнае імя, і запішыце абодва вынікі побач са здымкам: сетка, наладжаныя серверы, стан Private DNS і дакладны тэкст памылкі. Прамы запыт да найменаванага сервера даказвае, што гэты сервер вам адказвае; ён не даказвае, што звычайнае развязанне праграмы выбрала яго. Адказ з кэша — не свежы тэст, таму ачысціце кэш або выкарыстайце імя, якое сёння ніхто не запытваў.

Калі resolver абслугоўвае толькі кліентаў з пэўнай сеткі доступу, тое, што ён бачыць пасля выхаду з VPN, можа вырашыць вынік, і гэта пытанне палітыкі для таго, хто ім кіруе, а не доказ, што аператары блокуюць UDP 53. Там, дзе Private DNS актыўны, некваліфікаванае імя хоста можа быць адхіленае па задуме, пакуль той самы сервер нармальна адказвае на публічныя імёны. Чытанне ўласцівасцей кажа вам, які рэжым дзейнічае, так што вы перастаеце гадаць фільтры пакетаў.

Выпраўце слой, якому належыць неадпаведнасць

Працуйце ўверх, а не рэдагуйце глабальны стан. Калі праграма прывязана да няправільнай сеткі, выпраўце прывязку. Калі профіль дае няправільную опцыю DNS, выпраўце профіль. Калі Private DNS строгі ў сетцы, чый resolver не можа абслугоўваць вашу прыватную зону, гэта рашэнне кіравання прыладай, а не прычына выключаць функцыю ўсюды.

Праштурхванне публічных resolver-аў у DHCP-хук або сістэмную ўласцівасць — гэта выпраўленне, якое пастаянна выклікае інцыдэнты: прыватныя імёны перастаюць развязвацца, змена перажывае сесію VPN, і наступны чалавек на прыладзе знаходзіць састарэлы адрас без уладальніка. Трымайце змену ўнутры VPN, праграмы або слоя кіравання, якому належыць неадпаведнасць, а потым перачытайце здымак, каб пацвердзіць, што спіс сервераў сапраўды змяніўся.

У канцы вы хочаце адзін запыт праграмы, прывязаны да адной сеткі, спісу resolver-аў і стану Private DNS. Як толькі вы можаце паказаць гэты ланцуг, знаёмы адрас у файле перастае быць доказам чагосьці.