निजी एंडपॉइंट अभी भी सार्वजनिक पते से उत्तर क्यों देता है
लैपटॉप से क्वेरी को बाहर की ओर ट्रेस करें: कौन सा रिज़ॉल्वर उत्तर देता है, कौन सा पता वापस आता है, और निजी एंडपॉइंट तक पहुँचने से पहले क्या जोड़ना होता है।
लैपटॉप कनेक्ट होता है, टनल खुद को चालू बताती है, और स्टोरेज खाता अब भी हर अनुरोध अस्वीकार करता है। निजी एंडपॉइंट मौजूद है, उसके सबनेट तक का रूट मौजूद है, और नाम या तो सार्वजनिक पते से उत्तर देता है या हल ही नहीं होता। टनल में कुछ भी गलत नहीं है: क्लाइंट को कभी नहीं बताया गया कि उस नाम के लिए कौन सा सर्वर उत्तर देगा। क्वेरी को बाहर की ओर ट्रेस करें और अंतर स्पष्ट हो जाएगा।
क्लाइंट के रिज़ॉल्वर से शुरू करें
टनल चालू रहने के दौरान क्लाइंट से पूछें कि वह किस सर्वर को क्वेरी करता है। पॉइंट-टू-साइट प्रोफ़ाइल वह पता देता है, और जो प्रोफ़ाइल कुछ नहीं देता वह ऑपरेटिंग सिस्टम को एडाप्टर के डिफ़ॉल्ट पर लौटने देता है।
सार्वजनिक रिज़ॉल्वर को निजी ज़ोन का कोई दृश्य नहीं होता, इसलिए वे इंटरनेट से उत्तर देते हैं, जो ठीक उनका काम है। इसलिए पहली जाँच इस्तेमाल हो रहे रिज़ॉल्वर का पता है, टनल नहीं और एंडपॉइंट नहीं।
उत्तर वास्तव में क्या है, यह पढ़ें
सेवा का नाम हल करें और लौटने वाला पता पढ़ें। सार्वजनिक उत्तर का अर्थ है कि क्वेरी ऐसे सर्वर तक पहुँची जो ज़ोन नहीं देख सकता। उत्तर न आने का अर्थ है कि नाम केवल निजी रूप से मौजूद है और क्लाइंट जिस तक पहुँच सकता है उसमें से कुछ भी उसे नहीं रखता।
ये दोनों परिणाम मिलते-जुलते एप्लिकेशन त्रुटियाँ पैदा करते हैं और अलग-अलग मालिकों के हैं। एक रिज़ॉल्वर चयन की समस्या है, दूसरी ज़ोन लिंक के गायब होने की।
hosts प्रविष्टि रास्ता साबित करती है, फिर झूठ बोलती है
स्थानीय hosts फ़ाइल में एंडपॉइंट का पता डालना यह साबित करने का सबसे तेज़ तरीका है कि टनल और सेवा का फ़ायरवॉल पहले से काम कर रहे हैं। यदि उस प्रविष्टि से अनुरोध सफल होता है, तो केवल नाम रिज़ॉल्यूशन टूटा है। यह हर मशीन के लिए अलग बदलाव भी है जो ठीक एक नाम कवर करता है।
यह दूसरे खाते, दूसरे एंडपॉइंट या किसी सहकर्मी की मदद नहीं करता, और एंडपॉइंट के नए पते पर फिर से बनने पर बिना चेतावनी टूट जाता है।
इससे भी बुरा, यह आपकी मशीन को बाकी सबसे अलग व्यवहार करवाता है, और इसी तरह रिज़ॉल्वर की खराबी एक हफ़्ते की जाँच में बची रहती है। रास्ता पुष्टि करने के लिए इसका उपयोग करें, फिर इसे हटा दें और कारण ठीक करें।
ज़ोन जोड़ें और रिज़ॉल्वर दें
दो शर्तें एक साथ पूरी होनी चाहिए। निजी ज़ोन उस वर्चुअल नेटवर्क से जुड़ा होना चाहिए जहाँ एंडपॉइंट रहता है, और क्लाइंट अपनी क्वेरी ऐसे सर्वर को भेजे जो उस ज़ोन को पढ़ सके। DNS Private Resolver का इनबाउंड एंडपॉइंट नेटवर्क के भीतर ऐसा पता देता है और टनल से आने वाली क्वेरी का उत्तर देता है। उस पते को VPN प्रोफ़ाइल में रखें और वह निजी प्रत्यय जोड़ें जो क्लाइंट को लागू करना चाहिए।
पहले से मौजूद ऑन-प्रिमाइसेस रिज़ॉल्वर ज़ोन की ओर इंगित सशर्त फ़ॉरवर्डर के ज़रिए वही परिणाम पा सकता है।
रिज़ॉल्वर पर नेटवर्क नियम रूटिंग जितने ही मायने रखते हैं। यदि इनबाउंड नियम VPN क्लाइंट की श्रेणी को बाहर रखता है, तो क्वेरी गलत उत्तर देने के बजाय समय-समाप्त हो जाती हैं। यही समय-समाप्ति लोगों को ऐसी रूट तालिका पर वापस भेजती है जहाँ कुछ भी गलत नहीं है।
नाम, पोर्ट और पहचान क्रम से जाँचें
क्रम से काम करें: नाम हल करें, पुष्टि करें कि उत्तर निजी है, पोर्ट खोलें, फिर प्रमाणित अनुरोध करें। हर चरण का अपना मालिक और अपना विफलता हस्ताक्षर है।
निजी उत्तर के बाद समय-समाप्ति किसी रूट या फ़ायरवॉल की ओर इशारा करती है। सार्वजनिक उत्तर रिज़ॉल्वर की ओर इशारा करता है। पूरा हुआ कनेक्शन जो पहचान त्रुटि लौटाता है वह सेवा का है।
एक और विफलता इस सूची में आती है। क्लाइंट पते को अनुमति देने वाला सेवा फ़ायरवॉल तब मेल खाना बंद कर देता है जब रीकनेक्ट के बाद पूल वह पता किसी दूसरे सत्र को दे देता है। क्लाइंट जो समझता है कि उसके पास है उसके बजाय सेवा द्वारा दर्ज कॉलर पता पढ़ें। दोनों लोगों की अपेक्षा से अधिक बार अलग होते हैं। Azure DNS Private Resolver मार्गदर्शन ज़ोन लिंक और फ़ॉरवर्डिंग व्यवस्था को कवर करता है।