Android DNS યોગ્ય રીતે વાંચો: નેટવર્ક મુજબ, resolv.conf માં નહીં

તમે ઉપકરણ પર shell લો છો, /etc/resolv.conf વાંચો છો અથવા જૂનું net.dns1 મૂલ્ય ખોદી કાઢો છો, અને એક સરનામું મળે છે. તમારી સામેની એપ સાવ બીજી કોઈ વસ્તુ દ્વારા ઉકેલે છે. વર્તમાન Android આવૃત્તિમાં resolver નેટવર્ક મુજબ છે: સિસ્ટમ દરેક Network માટે નીતિ રાખે છે અને તેને વિનંતી મોકલનાર socket પર લાગુ કરે છે. ફાઇલ અને જૂની મિલકત બચેલા ભાગો છે, અને તેમાંથી કોઈ પણ તમારી ક્વેરીએ ખરેખર લીધેલો માર્ગ વર્ણવતું નથી.

આ અંતર split-tunnel અને Private DNS રોલઆઉટમાં દેખાય છે, જ્યાં એક જ ફોન પરની બે એપ કાયદેસર રીતે જુદા જવાબો જોઈ શકે છે. આ માર્ગદર્શિકા ખોટા કે ગેરહાજર ઉકેલથી શરૂ થાય છે અને જે કન્ફિગરેશનની તે માલિકી ધરાવે છે ત્યાં પાછી જાય છે.

resolver નેટવર્કનો હોય છે, ઉપકરણનો નહીં

Android 9 અને પછીના નામ-ઉકેલ સિસ્ટમ resolver દ્વારા જાય છે જે socket જે Network સાથે બંધાયેલ છે તેના પર આધારિત છે. દરેક નેટવર્ક પોતાની LinkProperties ધરાવે છે, અને આ લક્ષણો ફક્ત તે નેટવર્ક માટે DNS સર્વરોની યાદી, શોધ ડોમેન અને Private DNS સ્થિતિ રાખે છે. તે મોડેલમાં ફાઇલમાંથી વાંચી શકાય તેવી એક જ ઉપકરણ-વ્યાપી યાદી સાથે મેળ ખાતું કંઈ નથી.

VPN આ વિભાજન સ્પષ્ટ કરે છે. ટનલ ઉપર આવે ત્યારે VPN એપ VPN ના પોતાના નેટવર્ક પર નોંધાયેલ DNS સર્વર આપે છે, તેથી તેમાંથી રૂટ થતી એપ તે સર્વરો પર ઉકેલે છે જ્યારે બહાર રાખેલી એપ નીચેનું નેટવર્ક વાપરતી રહે છે. એક ઉપકરણ, બે જવાબ માર્ગ, કોઈ વિરોધાભાસ નહીં.

સ્નેપશોટ અસરગ્રસ્ત એપની અંદરથી વાંચો

એપને જ પૂછો. જે પદ્ધતિ પાસે 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 હેઠળ દસ્તાવેજીકૃત છે, અને તેમાં દરેક મૂલ્ય કન્ફિગરેશનનો સ્નેપશોટ છે, ચોક્કસ ક્વેરી ચોક્કસ સર્વર સુધી પહોંચી તેનો પુરાવો નહીં.

જ્યારે ડિફોલ્ટ નેટવર્ક કામ કરતું નેટવર્ક ન હોય

સ્નેપશોટ ફક્ત ડિફોલ્ટ માટે જવાબ આપે છે. એપ તેની પ્રક્રિયા કે એક socket બીજા નેટવર્ક સાથે બાંધી શકે છે, અને પછી ઉકેલ તે પસંદગીને અનુસરે છે જ્યારે તમારું નિદાન હજી ડિફોલ્ટ જણાવે છે. પોતાનું DNS-over-HTTPS resolver લાવતું બ્રાઉઝર સિસ્ટમ યાદીને બિલકુલ પૂછતું નથી, તેથી તેના જવાબો બાકીના ઉપકરણ વિશે કંઈ કહેતા નથી. કાર્ય પ્રોફાઇલ એપ પોતાની નીતિ સાથે અલગ વપરાશકર્તા હેઠળ ચાલે છે. સર્વરોને દોષ આપતાં પહેલાં બાઇન્ડિંગ તપાસો.

VPN એકીકરણ બીજો અડધો ભાગ છે. dhcp-option DNS લીટી OpenVPN પ્રોફાઇલમાં સ્વીકારવી અને તે સરનામું Android VPN નેટવર્ક પર નોંધવું બે અલગ પગલાં છે, અને સર્વર સુધીનો ખોવાયેલો માર્ગ ખોટા સરનામા જેટલો જ શાંતિથી નિષ્ફળ જાય છે. વિકાસ મશીનથી adb shell dumpsys connectivity build પરવાનગી આપે ત્યારે તે જ લિંક લક્ષણો પ્રતિ નેટવર્ક છાપે છે, જે કોડ લખ્યા વિના યાદીની પુષ્ટિ કરે છે.

કન્ફિગરેશનની તુલના તમને પરવાનગી હોય તેવા એક ઉકેલ સાથે કરો

ખાનગી નામ-અવકાશમાં ઉકેલાવું જરૂરી હોય તેવું નામ અને એક જાહેર નામ પસંદ કરો, અને બંને પરિણામો સ્નેપશોટ પાસે લખો: નેટવર્ક, ગોઠવેલા સર્વરો, Private DNS સ્થિતિ અને ભૂલનું ચોક્કસ લખાણ. નામાંકિત સર્વરને સીધી ક્વેરી સાબિત કરે છે કે તે સર્વર તમને જવાબ આપે છે; તે સાબિત કરતી નથી કે સામાન્ય એપ ઉકેલે તેને પસંદ કર્યું. કેશમાં રહેલો જવાબ તાજી કસોટી નથી, તેથી કેશ ખાલી કરો અથવા આજે કોઈએ ન પૂછેલું નામ વાપરો.

જો resolver ફક્ત ચોક્કસ પ્રવેશ નેટવર્કના ક્લાયન્ટને સેવા આપે છે, તો VPN નિકાસ પછી તે જે જુએ છે તે પરિણામ નક્કી કરી શકે છે, અને આ તેના સંચાલક માટે નીતિનો પ્રશ્ન છે, ઓપરેટરો UDP 53 અવરોધે છે તેનો પુરાવો નહીં. જ્યાં Private DNS સક્રિય છે ત્યાં અપૂર્ણ હોસ્ટનામ ડિઝાઇન મુજબ નકારી શકાય છે જ્યારે તે જ સર્વર જાહેર નામોને સામાન્ય રીતે જવાબ આપે છે. લક્ષણો વાંચવાથી ખબર પડે છે કે કઈ રીત લાગુ છે, તેથી તમે પેકેટ ફિલ્ટરનો અંદાજ કાઢવાનું છોડી દો છો.

જે સ્તરની આ અસંગતિ છે તેને સુધારો

જાહેર સ્થિતિ સંપાદિત કરવાને બદલે ઉપર તરફ કામ કરો. એપ ખોટા નેટવર્ક સાથે બંધાયેલી હોય તો બાઇન્ડિંગ સુધારો. પ્રોફાઇલ ખોટો DNS વિકલ્પ આપે તો પ્રોફાઇલ સુધારો. જે નેટવર્કનો resolver તમારા ખાનગી ઝોનની સેવા કરી શકતો નથી ત્યાં Private DNS કડક હોય, તો તે ઉપકરણ વ્યવસ્થાપનનો નિર્ણય છે, સુવિધા દરેક જગ્યાએ બંધ કરવાનું કારણ નહીં.

જાહેર resolver ને DHCP હૂક કે સિસ્ટમ લક્ષણમાં ધકેલવા એ એવી સમારકામ છે જે સતત ઘટનાઓ સર્જે છે: ખાનગી નામો ઉકેલવાનું બંધ થાય છે, ફેરફાર VPN સત્રથી આગળ ટકે છે, અને ઉપકરણ પરની આગલી વ્યક્તિને માલિક વગરનું જૂનું સરનામું મળે છે. ફેરફારને VPN, એપ કે જે વ્યવસ્થાપન સ્તરની આ અસંગતિ છે તેની અંદર રાખો, પછી સ્નેપશોટ ફરી વાંચીને ખાતરી કરો કે સર્વર યાદી ખરેખર બદલાઈ છે.

અંતે તમારે એક નેટવર્ક, resolver યાદી અને Private DNS સ્થિતિ સાથે બંધાયેલી એક એપ વિનંતી જોઈએ છે. આ સાંકળ બતાવી શકો ત્યારે ફાઇલમાંનું જાણીતું સરનામું કોઈ વસ્તુનો પુરાવો રહેતું નથી.