Preberite Android DNS pravilno: po omrežju, ne v resolv.conf
Vaša aplikacija Android razrešuje prek resolverja za vsako omrežje, ne prek resolv.conf, ki ste ga pravkar prebrali. Najprej preglejte LinkProperties, vezave vtičnic in Private DNS.
Dobite lupino na napravi, preberete /etc/resolv.conf ali izkopljete staro vrednost net.dns1, in dobite en naslov. Aplikacija pred vami razrešuje prek nečesa povsem drugega. V trenutni izdaji Androida je resolver za vsako omrežje: sistem hrani pravilnik za vsak Network in ga uporabi za vtičnico, ki je poslala zahtevo. Datoteka in stara lastnost sta ostanka in nobena od njiju ne opisuje poti, ki jo je vaša poizvedba v resnici ubrala.
Ta vrzel se pokaže pri uvajanju split-tunnela in Private DNS, kjer lahko dve aplikaciji na istem telefonu upravičeno vidita različna odgovora. Ta pregled se začne pri napačnem ali manjkajočem razreševanju in gre nazaj do konfiguracije, ki ji pripada.
Resolver pripada omrežju, ne napravi
Razreševanje imen v Androidu 9 in novejšem poteka prek sistemskega resolverja, ki se opira na Network, na katero je vezana vtičnica. Vsako omrežje nosi svoje LinkProperties, te lastnosti pa vsebujejo seznam strežnikov DNS, iskalne domene in stanje Private DNS samo za to omrežje. Nič v tem modelu ne ustreza enemu seznamu za vso napravo, ki bi ga lahko prebrali iz datoteke.
VPN naredi razdelitev očitno. Ko se tunel dvigne, aplikacija VPN zagotovi strežnike DNS, registrirane v lastnem omrežju VPN, zato aplikacije, usmerjene skozenj, razrešujejo pri teh strežnikih, medtem ko izključene aplikacije še naprej uporabljajo spodnje omrežje. Ena naprava, dve poti odgovora, brez protislovja.
Preberite posnetek od znotraj prizadete aplikacije
Vprašajte aplikacijo samo. Metoda s Context in običajnim dovoljenjem android.permission.ACCESS_NETWORK_STATE lahko prebere posnetek, ne da bi se dotaknila sistemskih lastnosti:
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?.privateDnsServerNameactiveNetwork je privzeto omrežje vašega procesa, ne edino omrežje v napravi, in je lahko null, ko klicatelj nima uporabnega privzetega omrežja. Blokiran privzeti VPN je običajen razlog. isPrivateDnsActive vam pove, ali poizvedbe v tem omrežju potekajo prek TLS do imenovanega resolverja, kar spremeni, kaj vam bo pokazala preprosta sonda UDP 53. Površina API je dokumentirana pod LinkProperties, vsaka vrednost v njej pa je posnetek konfiguracije in ne dokaz, da je določena poizvedba dosegla določen strežnik.
Ko privzeto omrežje ni tisto, ki opravlja delo
Posnetek odgovarja le za privzeto omrežje. Aplikacija lahko svoj proces ali eno vtičnico veže na drugo omrežje, nato pa razreševanje sledi tej izbiri, medtem ko vaša diagnostika še vedno poroča privzeto omrežje. Brskalnik z lastnim resolverjem DNS-over-HTTPS sistemskega seznama sploh ne posvetuje, zato njegovi odgovori ne povedo ničesar o preostanku naprave. Aplikacija delovnega profila teče pod ločenim uporabnikom z lastnim pravilnikom. Preverite vezavo, preden okrivite strežnike.
Integracija VPN je druga polovica. Prejeti vrstico dhcp-option DNS v profilu OpenVPN in to naslov registrirati v omrežju VPN Androidu sta dva ločena koraka, manjkajoča pot do strežnika pa odpove enako tiho kot napačen naslov. Z razvojnega stroja ukaz adb shell dumpsys connectivity izpiše enake lastnosti povezave za vsako omrežje, ko to gradnja dovoli, kar seznam potrdi brez pisanja kode.
Primerjajte konfiguracijo z enim razreševanjem, ki ga smete izvesti
Izberite ime, ki se mora razrešiti v zasebnem imenskem prostoru, in eno javno ime, ter zapišite oba izida ob posnetek: omrežje, konfigurirani strežniki, stanje Private DNS in natančno besedilo napake. Neposredna poizvedba na imenovan strežnik dokaže, da vam ta strežnik odgovarja; ne dokaže, da ga je izbralo običajno razreševanje aplikacije. Odgovor iz predpomnilnika ni svež test, zato počistite predpomnilnik ali uporabite ime, po katerem danes še nihče ni povprašal.
Če resolver streže le odjemalcem iz določenega dostopovnega omrežja, lahko to, kar vidi po izstopu iz VPN, odloči izid, in to je vprašanje pravilnika za tistega, ki ga upravlja, ne dokaz, da operaterji blokirajo UDP 53. Kjer je Private DNS aktiven, je nekvalificirano ime gostitelja lahko zavrnjeno po zasnovi, medtem ko isti strežnik javna imena odgovarja normalno. Branje lastnosti vam pove, kateri način velja, zato nehate ugibati filtre paketov.
Popravite plast, ki ji pripada neskladje
Delajte navzgor namesto urejanja globalnega stanja. Če je aplikacija vezana na napačno omrežje, popravite vezavo. Če profil prinaša napačno možnost DNS, popravite profil. Če je Private DNS strog v omrežju, katerega resolver ne more streči vaši zasebni coni, je to odločitev upravljanja naprave in ne razlog, da funkcijo povsod izklopite.
Vsiljevanje javnih resolverjev v kavelj DHCP ali sistemsko lastnost je popravilo, ki nenehno povzroča incidente: zasebna imena se nehajo razreševati, sprememba preživi sejo VPN in naslednja oseba na napravi najde zastarel naslov brez lastnika. Držite spremembo znotraj VPN, aplikacije ali plasti upravljanja, ki ji pripada neskladje, nato znova preberite posnetek, da potrdite, da se je seznam strežnikov res spremenil.
Na koncu želite eno zahtevo aplikacije, vezano na eno omrežje, seznam resolverjev in stanje Private DNS. Ko lahko pokažete to verigo, znan naslov v datoteki ni več dokaz za nič.