Azure P2S VPN निजी एंडपॉइंट का नाम हल नहीं कर पाता
जाँचें क्रम से करें: DNS कौन-सा पता लौटाता है, ज़ोन लिंक, पहुँचने योग्य रिज़ॉल्वर, प्रमाणपत्र का होस्टनेम और एक अस्थायी hosts प्रविष्टि।
आप point-to-site टनल जोड़ते हैं, निजी पते पर ping करते हैं, ऐप खोलते हैं और बदले में 403 या प्रमाणपत्र त्रुटि मिलती है। दोनों लक्षण DNS की ओर इशारा करते हैं, पर वे अलग-अलग खराबियाँ हैं: एक का अर्थ है कि क्लाइंट ने सार्वजनिक पता हल किया, दूसरे का अर्थ है कि उसने निजी पता हल किया और फिर ऐसा नाम दिया जिसे प्रमाणपत्र कवर नहीं करता। नीचे दी गई जाँचें क्रम से करें और पहली विफलता पर रुकें, क्योंकि hosts प्रविष्टि या कैश में सहेजा गया उत्तर हर बाद की जाँच को गलत कारण से पास करा सकता है। मैं यह क्रम अपनी VPN प्रोफ़ाइल के बगल में एक टेक्स्ट फ़ाइल में रखता हूँ, क्योंकि सुधार टनल में कुछ नहीं बदलता और क्लाइंट जो जानता है उसमें सब कुछ बदल देता है।
उस पते से शुरू करें जो क्लाइंट को वास्तव में मिलता है
ऐप पर भरोसा करने के बजाय रिज़ॉल्वर से सीधे पूछें। Windows पर, nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net दिखाता है कि क्लाइंट को कौन-सा दृश्य मिला। सार्वजनिक उत्तर का अर्थ है कि आगे कुछ भी एंडपॉइंट तक नहीं पहुँचेगा; एंडपॉइंट का निजी पता का अर्थ है कि DNS पूरा हुआ और अगली जाँच स्वयं कनेक्शन है।
निजी एंडपॉइंट सेवा का नाम नहीं बदलता। खाता या ऐप अपना सामान्य पूर्ण योग्य नाम रखता है, और एंडपॉइंट केवल वह पता बदलता है जिस पर वर्चुअल नेटवर्क के अंदर के क्लाइंट के लिए यह नाम हल होता है। इसीलिए वही होस्टनेम नेटवर्क की VM से निजी रूप से और ऐसे लैपटॉप से सार्वजनिक रूप से हल होता है जिसे कभी निजी दृश्य नहीं मिला।
टनल से पहले ज़ोन, उसका लिंक और रिकॉर्ड जाँचें
तीन शर्तें साथ पूरी होनी चाहिए: निजी ज़ोन मौजूद है, वह उस वर्चुअल नेटवर्क से लिंक है जहाँ VPN गेटवे और क्लाइंट Azure में प्रवेश करते हैं, और उसमें एंडपॉइंट के लिए निजी पते की ओर इशारा करने वाला A रिकॉर्ड है। ज़ोन को किसी असंबंधित नेटवर्क से लिंक करें तो गेटवे सार्वजनिक रिकॉर्ड हल करता रहेगा, जबकि टनल की हर चीज़ स्वस्थ दिखेगी।
ज़ोन के नाम सेवाओं के होते हैं, सामान्य रूप से निजी लिंक के नहीं। App Service सामान्यतः privatelink.azurewebsites.net का उपयोग करता है, स्टोरेज और SQL के अपने नेमस्पेस हैं, और किसी दूसरी सेवा का ज़ोन उधार लेने से ऐसा ज़ोन बनता है जो मौजूद है पर कुछ उपयोगी उत्तर नहीं देता।
क्लाइंट को ऐसा रिज़ॉल्वर दें जहाँ वह वास्तव में पहुँच सके
168.63.129.16 Azure वर्चुअल मशीनों से उत्तर देता है और point-to-site टनल के दूसरी ओर के लैपटॉप के लिए DNS सर्वर नहीं है। क्लाइंट को टनल से पहुँचने योग्य रिज़ॉल्वर चाहिए: Azure DNS Private Resolver का इनबाउंड एंडपॉइंट, वर्चुअल नेटवर्क के अंदर फ़ॉरवर्डर, या VPN क्लाइंट प्रोफ़ाइल में ले जाई गई DNS सर्वर प्रविष्टियाँ ताकि क्लाइंट वर्चुअल नेटवर्क से सीधे पूछे।
कॉन्फ़िगर किया गया पर पहुँच से बाहर रिज़ॉल्वर ठीक वैसे ही व्यवहार करता है जैसे कोई रिज़ॉल्वर न हो, और लक्षण गलत उत्तर के बजाय टाइमआउट है, इसीलिए इसे फ़ायरवॉल समस्या के रूप में गलत पढ़ा जाता है। इसे ऐसी क्वेरी से जाँचें जिसे टनल को ले जाना है, ऐसे सार्वजनिक नाम से नहीं जो स्थानीय लिंक पर वैसे भी सफल होता।
अगर आप सेटिंग धकेलने के बजाय फ़ॉरवर्ड करते हैं, तो वह नेमस्पेस फ़ॉरवर्ड करें जिसका मालिक निजी ज़ोन है, पूरे azurewebsites.net के बजाय privatelink.azurewebsites.net। जो सशर्त फ़ॉरवर्डर पूरा पैरेंट सफ़िक्स निगल जाता है वह सेवा की हर लुकअप Azure पर भेजता है, उन सहित जिन्हें स्थानीय रहना चाहिए।
वही नाम इस्तेमाल करें जिसके लिए प्रमाणपत्र जारी हुआ था
पता सही होते ही दूसरी खराबी सामने आती है। स्टोरेज और App Service एक privatelink उपनाम प्रकाशित करते हैं, और वह उपनाम ज़रूरी नहीं कि प्रमाणपत्र में दिया नाम हो। privatelink.blob.core.windows.net पर भेजा गया AzCopy अपलोड सत्यापन में विफल रहा; वही अपलोड <account>.blob.core.windows.net/<container> पर निजी पते पर हल हुआ और पास हो गया, इसलिए वह बिना किसी ओवरराइड के निजी मार्ग पर रहा।
यह नियम ब्राउज़र में और App Service के लिए भी लागू है: उस होस्टनेम से जुड़ें जिसे प्रमाणपत्र कवर करता है और DNS को निजी पता देने दें। सत्यापन को दरकिनार करने की कोशिश न करें, क्योंकि वह नामकरण की गलती को सुरक्षा रिग्रेशन में बदल देता है। सफल ping मार्ग साबित करता है और हैंडशेक के अंदर के नाम के बारे में कुछ नहीं कहता, इसीलिए ये अलग जाँचें रहती हैं।
चार चरणों का क्रम जो हर परत को अलग करता है
- पुष्टि करें कि VPN क्लाइंट के पास point-to-site पूल से पता है और एंडपॉइंट के निजी पते तक मार्ग है।
- ऐप जो सटीक नाम इस्तेमाल करता है उसे हल करें और उत्तर की तुलना एंडपॉइंट के पते से करें।
- सेवा पोर्ट पर एंडपॉइंट से TCP कनेक्शन खोलें, फिर उस कनेक्शन पर प्रस्तुत प्रमाणपत्र का नाम पढ़ें।
- अब ही प्राधिकरण जाँचें, क्योंकि काम करता मार्ग और वैध प्रमाणपत्र अभी संसाधन तक पहुँच नहीं देते।
पता सही होते हुए अस्वीकृत कनेक्शन DNS की ओर नहीं, नेटवर्क सुरक्षा समूह या निजी एंडपॉइंट कनेक्शन की स्थिति की ओर इशारा करता है, इसलिए रिज़ॉल्वर सेटिंग फिर संपादित करने से पहले उन्हें जाँचें। TLS नाम का बेमेल आपको URL के होस्टनेम और प्रमाणपत्र के subject पर लौटाता है। रिज़ॉल्यूशन आउटपुट, प्रमाणपत्र का नाम और सटीक URL साथ रखें; ये तीन मान गेटवे को छुए बिना इनमें से अधिकांश मामले समझा देते हैं।
नियंत्रण के रूप में वर्चुअल नेटवर्क के अंदर की VM इस्तेमाल करें। अगर नाम वहाँ निजी रूप से और टनल से सार्वजनिक रूप से हल होता है, तो ज़ोन और रिकॉर्ड सही हैं और एकमात्र अंतर क्लाइंट के रिज़ॉल्वर मार्ग का है, जिसे एंडपॉइंट कॉन्फ़िगरेशन पर एक और दौर से जल्दी पुष्टि की जा सकता है।
क्लाइंट भी कैश करते हैं। दस मिनट पहले सार्वजनिक रूप से उत्तर देने वाला रिकॉर्ड ज़ोन ठीक करने के बाद भी उत्तर देता रहता है, इसलिए दोबारा जाँचने से पहले कैश साफ़ करें। Windows पर, ipconfig /flushdns क्लाइंट कैश साफ़ करता है; नाम रिज़ॉल्यूशन नीति के नियम बने रहते हैं, तय करते हैं कि कौन-सा सफ़िक्स किस सर्वर पर जाए, और आपके द्वारा अभी बदले गए रिज़ॉल्वर पर नेमस्पेस भेजते रह सकते हैं।
hosts प्रविष्टि कहाँ बनती है
एंडपॉइंट का पता hosts फ़ाइल में जोड़ना अच्छा निदान और खराब डिज़ाइन है। यह साबित करता है कि नाम-से-पता मैपिंग ही गायब टुकड़ा है और उसके बाद की हर चीज़ जाँचने देता है, पर यह आपके उपयोगकर्ताओं के लिए अदृश्य है, एंडपॉइंट का पता बदलने पर टूट जाता है और उस ज़ोन को छिपा देता है जिसे उत्तर देना चाहिए।
बची हुई परीक्षण प्रविष्टि पुराने कैश से भी बुरी है, क्योंकि त्रुटि की दिशा के अनुसार यह ठीक किए मार्ग को टूटा या टूटे मार्ग को ठीक दिखा सकती है। अंतिम बार चलाने से पहले इसे हटाएँ और केवल उत्पादन रिज़ॉल्वर से हल करें।
छोटे नामों को खोज सफ़िक्स चाहिए और पूर्ण योग्य नामों को नहीं, इसलिए पहले पूर्ण योग्य नाम जाँचें, फिर तय करें कि वर्कफ़्लो को क्लाइंट प्रोफ़ाइल के ज़रिए धकेला गया सफ़िक्स चाहिए या नहीं। Microsoft अपने निजी एंडपॉइंट DNS मार्गदर्शन में प्रति-सेवा ज़ोन नाम और रिकॉर्ड आकार दस्तावेज़ करता है; किसी दूसरी सेवा से ज़ोन कॉपी करने के बजाय अपनी सेवा की प्रविष्टि पढ़ें।