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 स्थितिसँग बाँधिएको एउटा एप अनुरोध चाहिन्छ। यो शृंखला देखाउन सक्नुभएपछि फाइलमा भएको चिनजानको ठेगाना कुनै कुराको प्रमाण रहँदैन।