Darllen DNS Android yn gywir: fesul rhwydwaith, nid resolv.conf

Rydych yn cael shell ar y ddyfais, yn darllen /etc/resolv.conf neu’n cloddio hen werth net.dns1 allan, ac yn cael un cyfeiriad. Mae’r ap o’ch blaen yn datrys trwy rywbeth hollol wahanol. Ar fersiwn Android cyfredol mae’r datryswr fesul rhwydwaith: mae’r system yn cadw polisi ar gyfer pob Network ac yn ei gymhwyso i’r soced a wnaeth y cais. Mae’r ffeil a’r hen briodwedd yn weddillion, ac nid yw’r un ohonynt yn disgrifio’r llwybr a gymerodd eich ymholiad mewn gwirionedd.

Mae’r bwlch hwnnw’n ymddangos wrth gyflwyno split-tunnel a Private DNS, lle gall dau ap ar yr un ffôn weld atebion gwahanol yn gyfreithlon. Mae’r daith hon yn dechrau gyda’r datrysiad anghywir neu goll ac yn gweithio’n ôl i’r cyfluniad sy’n berchen arno.

Mae’r datryswr yn perthyn i rwydwaith, nid i’r ddyfais

Mae datrys enwau ar Android 9 a hwyrach yn mynd trwy ddatryswr system sy’n seilio ar y Network y mae soced wedi’i rwymo iddo. Mae pob rhwydwaith yn cario ei LinkProperties ei hun, ac mae’r priodweddau hynny’n cynnwys rhestr gweinyddwyr DNS, y parthau chwilio a chyflwr Private DNS ar gyfer y rhwydwaith hwnnw’n unig. Nid oes unrhyw beth yn y model hwnnw’n cyfateb i un rhestr sy’n ymestyn dros y ddyfais y gallech ei darllen o ffeil.

Mae VPN yn gwneud y rhaniad yn amlwg. Pan ddaw’r twnnel i fyny, mae’r ap VPN yn cyflenwi gweinyddwyr DNS sydd wedi’u cofrestru ar rwydwaith ei hun y VPN, fel bod apiau a gaiff eu llwybro trwyddo’n datrys yn erbyn y gweinyddwyr hynny tra bod apiau wedi’u heithrio’n dal i ddefnyddio’r rhwydwaith sylfaenol. Un ddyfais, dau lwybr ateb, dim gwrthddywediad.

Darllen y ciplun o fewn yr ap a effeithir

Gofynnwch i’r ap ei hun. Gall dull sydd â Context a’r caniatâd arferol android.permission.ACCESS_NETWORK_STATE ddarllen y ciplun heb gyffwrdd â phriodweddau system:

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

Y activeNetwork yw’r rhagosodiad ar gyfer eich proses, nid yr unig rwydwaith ar y ddyfais, a gall fod yn null pan nad oes gan y galwr ragosodiad defnyddiadwy. VPN rhagosodedig sydd wedi’i rwystro yw’r rheswm arferol. Mae isPrivateDnsActive yn dweud wrthych a yw ymholiadau ar y rhwydwaith hwnnw’n mynd dros TLS i ddatryswr enwebedig, sy’n newid yr hyn y bydd archwiliad UDP 53 syml yn ei ddangos. Mae’r arwyneb API wedi’i ddogfennu o dan LinkProperties, ac mae pob gwerth ynddo’n giplun o gyfluniad yn hytrach na phrawf bod ymholiad penodol wedi cyrraedd gweinydd penodol.

Pan nad y rhwydwaith rhagosodedig yw’r un sy’n gwneud y gwaith

Nid yw’r ciplun yn ateb ond dros y rhagosodiad. Gall ap rwymo ei broses neu un soced i rwydwaith arall, ac yna mae’r datrysiad yn dilyn y dewis hwnnw tra bod eich diagnosteg yn dal i adrodd y rhagosodiad. Nid yw porwr sy’n cyflenwi ei ddatryswr DNS-over-HTTPS ei hun byth yn ymgynghori â rhestr y system, felly nid yw ei atebion yn dweud dim am weddill y ddyfais. Mae ap proffil gwaith yn rhedeg o dan ddefnyddiwr ar wahân gyda’i bolisi ei hun. Gwiriwch y rhwymiad cyn beio’r gweinyddwyr.

Integreiddio VPN yw’r hanner arall. Mae derbyn llinell dhcp-option DNS mewn proffil OpenVPN a chofrestru’r cyfeiriad hwnnw ar rwydwaith VPN Android yn ddau gam ar wahân, ac mae llwybr coll i’r gweinydd yn methu mor dawel ag anghywir gyfeiriad. O beiriant datblygu, mae adb shell dumpsys connectivity yn argraffu’r un priodweddau cyswllt fesul rhwydwaith pan fo’r adeilad yn caniatáu, sy’n cadarnhau’r rhestr heb ysgrifennu cod.

Cymharu’r cyfluniad ag un datrysiad y cewch ei wneud

Dewiswch enw y mae’n rhaid iddo ddatrys o fewn y gofod enw preifat ac un enw cyhoeddus, ac ysgrifennwch y ddau ganlyniad wrth ymyl y ciplun: rhwydwaith, gweinyddwyr wedi’u ffurfweddu, cyflwr Private DNS a thestun union y gwall. Mae ymholiad uniongyrchol i weinydd enwebedig yn profi bod y gweinydd hwnnw’n eich ateb; nid yw’n profi i ddatrysiad arferol yr ap ei ddewis. Nid yw ateb wedi’i gacheio’n brawf ffres, felly glanhewch y storfa neu defnyddiwch enw nad oes neb wedi gofyn amdano heddiw.

Os mai dim ond cleientiaid o rwydwaith mynediad penodol y mae’r datryswr yn ei wasanaethu, gall yr hyn a wel ar ôl allanfa VPN benderfynu ar y canlyniad, ac mae hynny’n gwestiwn polisi i’r sawl sy’n ei redeg yn hytrach na phrawf bod gweithredwyr yn rhwystro UDP 53. Lle mae Private DNS yn weithredol, gellir gwrthod enw gwesteiwr heb gymhwyster yn ôl dyluniad tra bod yr un gweinydd yn ateb enwau cyhoeddus yn arferol. Mae darllen y priodweddau’n dweud wrthych pa fodd sydd mewn grym, fel yr ydych yn rhoi’r gorau i ddyfalu am hidlwyr pecynnau.

Trwsio’r haen sy’n berchen ar yr anghydweddiad

Gweithiwch i fyny yn hytrach nag olygu cyflwr byd-eang. Os yw’r ap wedi’i rwymo i’r rhwydwaith anghywir, trwsiwch y rhwymiad. Os yw’r proffil yn cyflenwi’r opsiwn DNS anghywir, trwsiwch y proffil. Os yw Private DNS yn llym ar rwydwaith na all ei ddatryswr wasanaethu’ch parth preifat, penderfyniad rheoli dyfais yw hynny ac nid rheswm i ddiffodd y nodwedd ym mhob man.

Gorfodi datryswyr cyhoeddus i mewn i fachyn DHCP neu briodwedd system yw’r atgyweiriad sy’n parhau i achosi digwyddiadau: mae enwau preifat yn peidio â datrys, mae’r newid yn goroesi sesiwn y VPN, ac mae’r person nesaf ar y ddyfais yn dod o hyd i gyfeiriad hen ffasiwn heb berchennog. Cadwch y newid o fewn y VPN, yr ap neu’r haen reoli sy’n berchen ar yr anghydweddiad, ac yna darllenwch y ciplun eto i gadarnhau bod y rhestr gweinyddwyr wedi newid mewn gwirionedd.

Yr hyn a ddymunwch yn y diwedd yw un cais ap wedi’i gysylltu ag un rhwydwaith, rhestr ddatryswyr a chyflwr Private DNS. Unwaith y gallwch ddangos y gadwyn honno, nid yw cyfeiriad cyfarwydd mewn ffeil yn brawf o unrhyw beth mwyach.