Legi la Android-DNS ĝuste: laŭ reto, ne en resolv.conf

Via Android-aplikaĵo solvas per unu solvilo laŭ reto, ne per la resolv.conf, kiun vi ĵus legis. Unue kontrolu LinkProperties, soketajn ligojn kaj Private DNS.

Vi ricevas ŝelon sur la aparato, legas /etc/resolv.conf aŭ elfosas malnovan valoron de net.dns1, kaj ricevas unu adreson. La aplikaĵo antaŭ vi solvas per io tute alia. En nuna Android-eldono la solvilo estas laŭ reto: la sistemo tenas regularon por ĉiu Network kaj aplikas ĝin al la soketo, kiu faris la peton. La dosiero kaj la malnova eco estas restaĵoj, kaj neniu el ili priskribas la vojon, kiun via demando efektive iris.

Tiu breĉo montriĝas dum enkonduko de split-tunnel kaj Private DNS, kie du aplikaĵoj sur la sama telefono rajte vidas malsamajn respondojn. Ĉi tiu trairo komenciĝas ĉe la malĝusta aŭ mankanta solvo kaj iras malantaŭen al la agordo, al kiu ĝi apartenas.

La solvilo apartenas al reto, ne al la aparato

Nom-solvado en Android 9 kaj poste iras tra sistema solvilo, kiu bazas sur la Network, al kiu soketo estas ligita. Ĉiu reto havas siajn proprajn LinkProperties, kaj tiuj ecoj enhavas la DNS-servilan liston, la serĉajn domajnojn kaj la Private DNS-staton nur por tiu reto. Nenio en tiu modelo respondas al unu aparatvasta listo, kiun vi povus legi el dosiero.

VPN evidentigas la dividon. Kiam la tunelo ekfunkcias, la VPN-aplikaĵo provizas DNS-servilojn registritajn sur la propra reto de la VPN, do aplikaĵoj enkursigitaj tra ĝi solvas per tiuj serviloj, dum ekskluditaj aplikaĵoj plu uzas la suban reton. Unu aparato, du respondvojoj, neniu kontraŭdiro.

Legi la momentfoton el la trafita aplikaĵo

Demandu la aplikaĵon mem. Metodo, kiu havas Context kaj la normalan permeson android.permission.ACCESS_NETWORK_STATE, povas legi la momentfoton sen tuŝi sistemajn ecojn:

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 estas la defaŭlto por via procezo, ne la sola reto sur la aparato, kaj ĝi povas esti null, kiam la vokanto ne havas uzeblan defaŭlton. Blokita VPN-defaŭlto estas la kutima kialo. isPrivateDnsActive diras al vi, ĉu demandoj sur tiu reto iras tra TLS al nomita solvilo, kio ŝanĝas, kion montros simpla UDP 53-sondo. La API-surfaco estas dokumentita sub LinkProperties, kaj ĉiu valoro en ĝi estas momentfoto de agordo, ne pruvo, ke difinita demando atingis difinitan servilon.

Kiam la defaŭlta reto ne estas tiu, kiu faras la laboron

La momentfoto respondas nur por la defaŭlto. Aplikaĵo povas ligi sian procezon aŭ unu soketon al alia reto, kaj tiam la solvado sekvas tiun elekton, dum via diagnozo plu raportas la defaŭlton. Retumilo, kiu liveras sian propran DNS-over-HTTPS-solvilon, tute ne konsultas la sisteman liston, do ĝiaj respondoj diras nenion pri la resto de la aparato. Laborprofil-a aplikaĵo funkcias sub aparta uzanto kun propra regularo. Kontrolu la ligon, antaŭ ol vi kulpigos la servilojn.

VPN-integriĝo estas la alia duono. Ricevi linion dhcp-option DNS en OpenVPN-profilo kaj registri tiun adreson sur la Android-VPN-reto estas du apartaj paŝoj, kaj mankanta vojo al la servilo malsukcesas same silente kiel malĝusta adreso. De evoluiga maŝino, adb shell dumpsys connectivity presas la samajn ligajn ecojn laŭ reto, kiam la konstruaĵo permesas, kio konfirmas la liston sen skribi kodon.

Kompari la agordon kun unu solvo, kiun vi rajtas fari

Elektu nomon, kiu devas solviĝi en la privata nomspaco, kaj unu publikan nomon, kaj notu ambaŭ rezultojn apud la momentfoto: reto, agorditaj serviloj, Private DNS-stato kaj la ekzakta erarteksto. Rekta demando al nomita servilo pruvas, ke tiu servilo respondas al vi; ĝi ne pruvas, ke la ordinara aplikaĵa solvado elektis ĝin. Kaŝmemorita respondo ne estas freŝa testo, do malplenigu la kaŝmemoron aŭ uzu nomon, pri kiu neniu demandis hodiaŭ.

Se la solvilo servas nur klientojn el difinita alira reto, tio, kion ĝi vidas post la VPN-eliro, povas decidi la rezulton, kaj tio estas regulara demando por tiu, kiu funkciigas ĝin, ne pruvo, ke operatoroj blokas UDP 53. Kie Private DNS estas aktiva, nekvalifikita gastignomo povas esti rifuzata laŭ la dezajno, dum la sama servilo normale respondas publikajn nomojn. Legi la ecojn diras al vi, kiu reĝimo validas, do vi ĉesas diveni pakaĵfiltrilojn.

Riparigi la tavolon, kiu posedas la malkongruon

Laboru supren anstataŭ redakti tutmondan staton. Se la aplikaĵo estas ligita al la malĝusta reto, riparu la ligon. Se la profilo liveras la malĝustan DNS-opcion, riparu la profilon. Se Private DNS estas strikta sur reto, kies solvilo ne povas servi vian privatan zonon, tio estas decido de aparatadministrado, ne kialo malŝalti la funkcion ĉie.

Devigi publikajn solvilojn en DHCP-hokon aŭ sisteman econ estas la riparo, kiu daŭre kaŭzas incidentojn: privataj nomoj ĉesas solviĝi, la ŝanĝo postvivas la VPN-sesion, kaj la sekva persono sur la aparato trovas malfreŝan adreson sen posedanto. Tenu la ŝanĝon ene de la VPN, la aplikaĵo aŭ la administra tavolo, kiu posedas la malkongruon, kaj poste relegu la momentfoton por konfirmi, ke la servila listo efektive ŝanĝiĝis.

Kion vi volas finfine estas unu aplikaĵa peto ligita al unu reto, solvila listo kaj Private DNS-stato. Post kiam vi povas montri tiun ĉenon, konata adreso en dosiero ĉesas esti pruvo pri io ajn.

Rilataj artikoloj