Lasiet Android DNS pareizi: pēc tīkla, nevis resolv.conf
Jūsu Android lietotne atrisina vārdus, izmantojot resolver katram tīklam, nevis resolv.conf, ko tikko izlasījāt. Vispirms pārbaudiet LinkProperties, ligzdu piesaistes un Private DNS.
Jūs iegūstat čaulu ierīcē, izlasāt /etc/resolv.conf vai izrokam vecu net.dns1 vērtību, un iegūstat vienu adresi. Lietotne jums priekšā atrisina pavisam citādi. Pašreizējā Android versijā resolver ir katram tīklam: sistēma tur politiku katram Network un piemēro to ligzdai, kas nosūtīja pieprasījumu. Fails un vecā īpašība ir paliekas, un neviena no tām neapraksta ceļu, ko jūsu vaicājums patiešām gāja.
Šī plaisa parādās, ieviešot split-tunnel un Private DNS, kur divas lietotnes vienā telefonā var likumīgi redzēt dažādas atbildes. Šī rokasgrāmata sākas ar nepareizu vai trūkstošu atrisināšanu un iet atpakaļ uz konfigurāciju, kurai tā pieder.
Resolver pieder tīklam, nevis ierīcei
Vārdu atrisināšana Android 9 un jaunākās versijās iet caur sistēmas resolver, kas balstās uz Network, kurai ir piesaistīta ligzda. Katrs tīkls nes savas LinkProperties, un šīs īpašības satur DNS serveru sarakstu, meklēšanas domēnus un Private DNS stāvokli tikai šim tīklam. Nekas šajā modelī neatbilst vienam visai ierīcei kopīgam sarakstam, ko varētu nolasīt no faila.
VPN padara sadalījumu acīmredzamu. Kad tunelis ceļas, VPN lietotne nodrošina DNS serverus, kas reģistrēti pašā VPN tīklā, tāpēc lietotnes, kas tiek maršrutētas caur to, atrisina vārdus pie šiem serveriem, bet izslēgtās lietotnes turpina izmantot apakšējo tīklu. Viena ierīce, divi atbildes ceļi, nekādu pretrunu.
Nolasiet momentuzņēmumu no skartās lietotnes iekšpuses
Pajautājiet pašai lietotnei. Metode, kurai ir Context un parastā atļauja android.permission.ACCESS_NETWORK_STATE, var nolasīt momentuzņēmumu, neaiztiekot sistēmas īpašības:
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 ir jūsu procesa noklusējuma tīkls, nevis vienīgais ierīces tīkls, un tas var būt null, ja izsaucējam nav izmantojama noklusējuma. Bloķēts noklusējuma VPN ir ierastais iemesls. isPrivateDnsActive pasaka, vai vaicājumi šajā tīklā iet caur TLS uz nosauktu resolver, kas maina to, ko parādīs vienkārša UDP 53 pārbaude. API virsma ir dokumentēta sadaļā LinkProperties, un katra vērtība tajā ir konfigurācijas momentuzņēmums, nevis pierādījums, ka konkrēts vaicājums sasniedza konkrētu serveri.
Kad noklusējuma tīkls nav tas, kas veic darbu
Momentuzņēmums atbild tikai par noklusējuma tīklu. Lietotne var piesaistīt savu procesu vai vienu ligzdu citam tīklam, un tad atrisināšana seko šai izvēlei, kamēr jūsu diagnostika joprojām ziņo par noklusējuma tīklu. Pārlūks ar savu DNS-over-HTTPS resolver nemaz nevaicā sistēmas sarakstu, tāpēc tā atbildes neko nepasaka par pārējo ierīci. Darba profila lietotne darbojas zem atsevišķa lietotāja ar savu politiku. Pārbaudiet piesaisti, pirms vainojat serverus.
VPN integrācija ir otrā puse. Saņemt dhcp-option DNS rindu OpenVPN profilā un reģistrēt šo adresi Android VPN tīklā ir divi atsevišķi soļi, un trūkstošs maršruts uz serveri neizdodas tikpat klusi kā nepareiza adrese. No izstrādes mašīnas adb shell dumpsys connectivity izdrukā tās pašas saites īpašības katram tīklam, kad būvējums to atļauj, kas apstiprina sarakstu, nerakstot kodu.
Salīdziniet konfigurāciju ar vienu atrisināšanu, ko drīkstat veikt
Izvēlieties vārdu, kas jāatrisina privātajā vārdu telpā, un vienu publisku vārdu, un pierakstiet abus rezultātus blakus momentuzņēmumam: tīkls, konfigurētie serveri, Private DNS stāvoklis un precīzais kļūdas teksts. Tiešs vaicājums nosauktam serverim pierāda, ka šis serveris jums atbild; tas nepierāda, ka parastā lietotnes atrisināšana to izvēlējās. Atbilde no kešatmiņas nav svaigs tests, tāpēc iztīriet kešatmiņu vai izmantojiet vārdu, par kuru šodien neviens nav vaicājis.
Ja resolver apkalpo tikai klientus no noteikta piekļuves tīkla, tas, ko tas redz pēc VPN izejas, var izlemt iznākumu, un tas ir politikas jautājums tam, kas to pārvalda, nevis pierādījums, ka operatori bloķē UDP 53. Kur Private DNS ir aktīvs, nekvalificēts resursdatora nosaukums var tikt noraidīts pēc dizaina, kamēr tas pats serveris normāli atbild uz publiskiem nosaukumiem. Īpašību lasīšana pasaka, kurš režīms ir spēkā, tāpēc jūs pārstājat minēt pakešu filtrus.
Salabojiet slāni, kuram pieder neatbilstība
Strādājiet uz augšu, nevis rediģējiet globālo stāvokli. Ja lietotne ir piesaistīta nepareizajam tīklam, salabojiet piesaisti. Ja profils nodrošina nepareizo DNS opciju, salabojiet profilu. Ja Private DNS ir stingrs tīklā, kura resolver nevar apkalpot jūsu privāto zonu, tas ir ierīces pārvaldības lēmums, nevis iemesls izslēgt funkciju visur.
Publisku resolver iespiešana DHCP āķī vai sistēmas īpašībā ir labojums, kas pastāvīgi izraisa incidentus: privātie vārdi pārstāj atrisināties, izmaiņa pārdzīvo VPN sesiju, un nākamā persona ierīcē atrod novecojušu adresi bez īpašnieka. Turiet izmaiņu VPN, lietotnes vai pārvaldības slānī, kuram pieder neatbilstība, un pēc tam vēlreiz nolasiet momentuzņēmumu, lai apstiprinātu, ka serveru saraksts patiešām mainījās.
Beigās jūs vēlaties vienu lietotnes pieprasījumu, kas piesaistīts vienam tīklam, resolver sarakstam un Private DNS stāvoklim. Kad varat parādīt šo ķēdi, pazīstama adrese failā vairs nav nekāda pierādījums.