Android DNS योग्यरितीने वाचा: नेटवर्कनुसार, resolv.conf मध्ये नाही

तुमचे Android ॲप प्रत्येक नेटवर्कच्या resolver द्वारे सोडवते, तुम्ही नुकतेच वाचलेल्या resolv.conf द्वारे नाही. आधी LinkProperties, socket बाइंडिंग्ज आणि Private DNS तपासा.

तुम्ही डिव्हाइसवर 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 स्थितीशी जोडलेली एक ॲप विनंती हवी आहे। ही साखळी दाखवता आल्यावर फाइलमधला ओळखीचा पत्ता कोणत्याही गोष्टीचा पुरावा राहत नाही।

संबंधित लेख