Android VPN पूरा होस्टनाम हल करता है, छोटा नाम नहीं

आपfilesकिसी टर्मिनल एमुलेटर में लिखते हैं और कुछ भी वापस नहीं आता; आपfiles.corp.exampleलिखते हैं और वही सर्वर तुरंत जवाब देता है। VPN क्रेडेंशियल में कुछ नहीं बदला, और निजी DNS सर्वर कभी खराब नहीं हुआ। Android में छोटा लेबल और पूरा नाम रिज़ॉल्वर से होकर अलग-अलग रास्तों से जाते हैं, और इनमें से एक रास्ता ऐसी सेटिंग पर निर्भर करता है जो टनल के मालिक को देनी होती है। आपके सामने यह फ़ैसला नहीं है कि कौन-सा DNS सर्वर बदलें, बल्कि यह है कि ऐप जो नेटवर्क वास्तव में इस्तेमाल कर रहा है उसे कौन नियंत्रित करता है।

खोज डोमेन कोई पता नहीं है। यह ऐसे प्रत्ययों की सूची है जो रिज़ॉल्वर हार मानने से पहले एक नंगे लेबल में जोड़ता है।

खोज प्रत्यय और DNS सर्वर अलग-अलग फ़ील्ड हैं

रिज़ॉल्वर का पता Android को बताता है कि कहाँ पूछना है। खोज प्रत्यय बताता है कि जब आप केवल सबसे बायाँ लेबल दें तो क्या पूछना है। दोनों एक ही नेटवर्क ऑब्जेक्ट पर रहते हैं, और इनमें से कोई भी अकेले गायब हो सकता है।

यही स्वतंत्रता बताती है कि पूरा होस्टनाम क्यों काम करता है। पूरी तरह योग्य नाम को प्रत्यय की ज़रूरत नहीं होती, क्योंकि वह पहले से ही वह स्ट्रिंग है जो सर्वर तक जाती है।

Android यह विभाजन इसके ज़रिए दिखाता हैLinkProperties। DNS सर्वरों की सूची और डोमेन खोज सूची एक ही ऑब्जेक्ट पर बैठती हैं, और दूसरी अक्सर खाली होती है भले ही पहली पूरी भरी हो। ऐसा नेटवर्क जिसमें रिज़ॉल्वर है पर डोमेन नहीं, वह नेटवर्क है जहाँ प्रत्यय कभी लागू ही नहीं हुआ — वह सर्वर नहीं जिसने छोटा नाम ठुकराया हो।

कुछ भी बदलने से पहले प्रभावी नेटवर्क पढ़ें

Wi-Fi, मोबाइल नेटवर्क और VPN इंटरफ़ेस तीन अलग नेटवर्क हैं, और टनल ऊपर आते ही डिफ़ॉल्ट बन जाता है। इसलिए जो प्रत्यय ऑफ़िस के Wi-Fi पर काम करता था, वह टनल सक्रिय रहने के दौरान अपने आप लागू प्रत्यय नहीं है। उस नेटवर्क को देखें जिस पर ऐप वास्तव में चुना गया है, न कि उसे जिसे आपने पिछले हफ़्ते सेट किया था।

डिवाइस पर टर्मिनल शेल यहाँ कमज़ोर गवाह है, क्योंकि उसकाresolv.confरिज़ॉल्वर के एक ही दृश्य को दिखाता है, हर ऐप के दृश्य को नहीं।

ब्राउज़र की पता पट्टियाँ एक और परत जोड़ती हैं: नंगे शब्द को खोज क्वेरी माना जा सकता है, या उसे इसके ज़रिए हल किया जा सकता हैब्राउज़र की अपनी एन्क्रिप्टेड-DNS नीति, इसलिए Chrome में लोड होता पेज सिस्टम लुकअप के बारे में कुछ साबित नहीं करता। किसी ऐसी चीज़ से परखें जो प्लेटफ़ॉर्म रिज़ॉल्वर इस्तेमाल करे और जो वापस आया उसे छापे। फिर छोटा रूप और पूरा रूप एक ही सत्र में, एक ही नेटवर्क पर चलाएँ, और लिख लें कि किसने जवाब दिया।

अगर आप VPN ऐप बनाते हैं, तो बिल्डर में ही प्रत्यय जोड़ें

जब आपका ऐप इसके ज़रिए इंटरफ़ेस स्थापित करता हैVpnService,addSearchDomainतो यह इसके लिए समर्थित इनपुट है। यह ऐसी डोमेन स्ट्रिंग लेता हैcorp.example, और यह सर्वर का पता भेजने का वैकल्पिक तरीका नहीं है।

यह कॉल प्रत्यय को उस नेटवर्क से बाँधती है जिसे आप बना रहे हैं, इसलिए बाद में पलटने के लिए कोई वैश्विक सेटिंग नहीं है। अगर ऐप इंटरफ़ेस तोड़कर दोबारा कनेक्ट होने पर उसे फिर बनाता है, तो नए बिल्डर को प्रत्यय दोबारा जोड़ना होगा, वरना बदला हुआ नेटवर्क उसके बिना ही ऊपर आ जाएगा।

यहीं बहुत से डेस्कटॉप प्रोफ़ाइल आयात यह फ़ील्ड खो देते हैं। निर्यातक डोमेन को अपने मॉडल में लिखता है, Android फ़्रंटएंड केवल उन्हीं विकल्पों का मैपिंग करता है जिन्हें वह जानता है, और परिणामी इंटरफ़ेस बाकी हर मायने में सही दिखता है। जो प्रोफ़ाइल लैपटॉप पर चलती है और फ़ोन पर विफल होती है, वह आमतौर पर मैपिंग की खाई है, प्रोटोकॉल की समस्या नहीं।

अगर आप केवल VPN इस्तेमाल करते हैं, तो यह आपकी सेटिंग नहीं है

क्लाइंट की तरफ़ कोई ऐसा संपादन नहीं है जो प्रत्यय जोड़े, और कोई वैश्विक गुण भी नहीं जिसे बदलकर आप उसे नकली बना सकें। मान वही देता है जिसके पास टनल है: प्रबंधित क्लाइंट की प्रोफ़ाइल में, उसके प्रति-प्लेटफ़ॉर्म मैपिंग में, या सर्वर जो भेजता है उसके ज़रिए। बताएँ कि आप किस प्लेटफ़ॉर्म पर हैं और कौन-सा नाम विफल होता है, क्योंकि डेस्कटॉप और मोबाइल फ़्रंटएंड ठीक इसी फ़ील्ड पर अलग होते हैं।

डेस्कटॉप प्रोफ़ाइल दोबारा आयात करना मोबाइल मैपिंग के बारे में फिर कुछ साबित नहीं करता।

तीन शर्तें तय करती हैं कि आपके पास खोट है या अपेक्षित सीमा। पहली, क्या संगठन छोटे लेबल को बिल्कुल भी समर्थित नाम मानता है, या वह ऐसी सुविधा है जो कभी केवल ऑफ़िस के Wi-Fi पर ही चली? दूसरी, क्या विफल लुकअप किसी ब्राउज़र से आ रहा है, जो सिस्टम रिज़ॉल्वर को पूरी तरह बायपास कर सकता है? तीसरी, क्या छोटा नाम टनल से पहुँचने योग्य होना चाहिए, या केवल LAN से? अगर आख़िरी जवाब केवल-LAN है, तो प्रत्यय जोड़ने से ऐसा नाम बनेगा जो ऑफ़िस के बाहर हल होगा और फिर रूट नहीं होगा।

जब प्रत्यय मौजूद है और छोटे नाम फिर भी विफल होते हैं

अगर डोमेन खोज सूची पहले सेcorp.exampleदिखाती है, तो प्रत्यय को दोष देना बंद करें। देखें कि रिज़ॉल्वर विस्तारित नाम के लिए बिल्कुल भी जवाब देता है या नहीं, क्योंकि प्रत्यय केवल वह सवाल बदलता है जो आप पूछते हैं। यह सर्वर को कभी ऐसे ज़ोन के लिए आधिकारिक नहीं बनाता जिसे वह होस्ट नहीं करता।

फिर रूट देखें। जो पता हल होता है पर टनल उसे नहीं ढोती, वह कनेक्ट के समय विफल होता है, जो ब्राउज़र में चुपचाप हार मानने वाली लुकअप विफलता जैसा ही दिखता है।

प्रमाणपत्रों को अलग उल्लेख मिलना चाहिए। HTTPS सत्यापन उसी होस्टनाम का उपयोग करता है जो आपने वास्तव में टाइप किया, इसलिए सही ढंग से विस्तारित होने वाला छोटा नाम हैंडशेक में अब भीfilesप्रस्तुत करता है। जो प्रमाणपत्रfiles.corp.exampleके लिए जारी हुआ है, वह उसके लिए मान्य नहीं होगा, और वह त्रुटि सही व्यवहार है, आपकी शुरुआती DNS समस्या का लक्षण नहीं।

अब क्या करें

किसी भी चीज़ को छूने से पहले विभाजन की पुष्टि करें: पूरा नाम हल होता है, छोटा नहीं, वही ऐप, वही सत्र। फिर चुना गया नेटवर्क खोजें और उसकी डोमेन खोज सूची उसकी रिज़ॉल्वर सूची के साथ पढ़ें। इन दोनों में से जो खाली है, वही बताता है कि किसे कार्रवाई करनी है — आप, अगर ऐप आपका है; टनल ऑपरेटर, अगर नहीं।

अंत में, जहाँ भी सुवाह्यता मायने रखती है, बुकमार्क और क्लाइंट कॉन्फ़िगरेशन में पूरा सेवा होस्टनाम पसंद करें। यह नेटवर्क बदलाव में टिका रहता है, ऐसी मैपिंग पर निर्भर नहीं है जिसे मोबाइल फ़्रंटएंड शायद लागू न करे, और उस नाम से मेल खाता है जिसके लिए प्रमाणपत्र जारी हुआ था।