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 समस्येचे लक्षण नाही.

पुढे काय करावे

काहीही हात लावण्यापूर्वी विभाजनाची खात्री करा: पूर्ण नाव सोडवले जाते, लहान नाही, तेच अ‍ॅप, तेच सत्र. मग निवडलेले नेटवर्क शोधा आणि त्याची डोमेन शोध यादी रिझोल्व्हर यादीच्या शेजारी वाचा. दोन्हींपैकी जी रिकामी असेल ती कोणी पावले उचलावीत हे सांगते — तुम्ही, अ‍ॅप तुमचे असल्यास; टनेल ऑपरेटर, नसल्यास.

शेवटी, जिथे सुवाह्यता महत्त्वाची आहे तिथे बुकमार्क आणि क्लायंट कॉन्फिगरेशनमध्ये पूर्ण सेवा होस्टनाव पसंत करा. ते नेटवर्क बदलात टिकते, मोबाइल फ्रंटएंड अमलात आणणार नाही अशा मॅपिंगवर अवलंबून नसते, आणि ज्या नावासाठी प्रमाणपत्र जारी झाले त्याच्याशी जुळते.