Azure P2S DNS तब विफल होता है जब resolver पियर्ड VNet में हो

VM को ping करें और वह जवाब देता है; उसका नाम पूछें और क्लाइंट कहता है कि host अज्ञात है। जब resolver VPN गेटवे वाले नेटवर्क के बजाय पियर्ड वर्चुअल नेटवर्क में बैठा हो, तो नतीजों की यह जोड़ी अपेक्षित है, और resolver की कोई भी ट्रबलशूटिंग इसे नहीं बदलती। जो अनुपस्थित है वह एक रूटिंग अनुबंध है जिसे पियरिंग डिफ़ॉल्ट रूप से रोक रखती है। दो टोपोलॉजी कागज़ पर लगभग एक जैसी दिखती हैं, और काम करने व बिगड़े के बीच का अंतर सही दिशा में सेट किए गए पियरिंग स्विचों की एक जोड़ी है।

एक लैपटॉप की कल्पना करें जो VNet2 में एक गेटवे में टनल कर रहा है, जबकि DNS परोसने वाला डोमेन कंट्रोलर VNet1 में बैठा है।

दो टोपोलॉजी, एक अंतर

resolver को गेटवे के अपने वर्चुअल नेटवर्क के अंदर रखें और टनल ऊपर आते ही नाम हल हो जाता है। कोई भी पियरिंग सेटिंग उस लुकअप में भाग नहीं लेती।

उसी resolver को पियरिंग के पार ले जाएँ और क्लाइंट को अब भी VM से जवाब मिलता है जबकि नाम अज्ञात रहता है। प्रमाणपत्र, टनल और क्लाइंट अपरिवर्तित हैं। केवल एक चीज़ हिली है कि resolver कहाँ रहता है। पियरिंग ने उसे उस पते तक एक रूट दिया, गेटवे को वहाँ ट्रैफ़िक ले जाने का अधिकार नहीं।

पक्ष A: गेटवे के मालिक पर गेटवे ट्रांज़िट की अनुमति दें

पियरिंग दो वर्चुअल नेटवर्क जोड़ती है, लेकिन यह जोड़ गेटवे से आने वाले ट्रैफ़िक के लिए पारगामी नहीं है, और पॉइंट-टू-साइट अनुरोध ठीक इसी तरह आता है। इसलिए VNet2 में गेटवे के पास लुकअप VNet1 को सौंपने का अधिकार नहीं है जब तक डिज़ाइन इसे न दे। अनुमति गेटवे वाले नेटवर्क के स्वामित्व वाली पियरिंग पर एक स्विच है।

VNet2 से VNet1 की ओर पियरिंग पर Allow gateway transit सेट करें। यह गुण गेटवे संसाधन का नहीं, पियरिंग ऑब्जेक्ट का है, इसलिए इसे पियरिंग ब्लेड में पढ़ा और बदला जाता है। पूरा पक्ष A यही है।

पक्ष B: साथी पर रिमोट गेटवे का उपयोग करें

दूसरा आधा दर्पण प्रतिबिंब है: VNet1 से VNet2 की ओर पियरिंग पर Use remote gateways सक्षम करें। वही फ़्लैग दोनों सिरों पर, या केवल एक पर चालू करने से आधा बना रास्ता और मूल लक्षण अछूते रह जाते हैं। केवल VPN गेटवे वाला नेटवर्क ट्रांज़िट की अनुमति देता है, और साथी वह पक्ष है जो इसका उपयोग करता है।

पोर्टल ब्लेड पर भरोसा करने के बजाय दोनों नेटवर्क पर दोनों गुण पढ़ें जिसे आपने आखिरी बार खोला था।

Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet2 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet1 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways

जोड़ी को साथ-साथ देखना उलटी सेटिंग पकड़ने का सबसे तेज़ तरीका है। गेटवे पक्ष पर AllowGatewayTransit false बताने वाली पियरिंग पैकेट कैप्चर के बिना पूरी विफलता समझा देती है।

क्लाइंट को अभी भी क्या मिलना चाहिए

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

कुछ और बदलने से पहले जुड़े लैपटॉप से resolver से पूछें।

nslookup dc01.corp.example 10.1.0.4

टाइमआउट कहता है कि रास्ता अभी भी नहीं है। आधिकारिक उत्तर समस्या को क्लाइंट पर वापस धकेलता है, आमतौर पर ऐसा प्रत्यय जो कभी जोड़ा ही नहीं जाता, इसलिए छोटे नाम सार्वजनिक resolver तक जाते हैं जो उन्हें खुशी से विफल कर देता है।

साइट-टू-साइट पक्ष पर वही अनुबंध तुलना करें

इसमें से कुछ भी विशेष रूप से लैपटॉप का नहीं है। क्लाइंट को साइट-टू-साइट की शाखा से बदलें और दो-तरफ़ा शर्त लौट आती है: शाखा सीधे गेटवे नेटवर्क में आती है, और दो नेटवर्क दूर की सेवा अभी भी पियरिंग के पीछे है।

ट्रांज़िट दोनों पियरिंग पर देना होता है, और जो स्विच इसे देता है वह क्लाइंट प्रकार पर नहीं, पियरिंग पर रहता है।

गेटवे को दोष देने से पहले

Windows हर एडाप्टर के लिए resolver सूची रखता है, इसलिए गेटवे को दोष देने से पहले जाँचें कि टनल इंटरफ़ेस को वास्तव में क्या मिला।

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /flushdns

नकारात्मक उत्तर कैश में रूटिंग सुधार से अधिक टिकता है, और पुरानी प्रत्यय सूची प्रश्नों को ऐसी जगह भेजती रहती है जहाँ ज़ोन कभी होस्ट नहीं हुआ। फ़्लश करें, फिर पूछें, और नोट करें कि कौन सा सर्वर जवाब देता है।

दो छोटी शर्तें तय करती हैं कि रास्ता टिकेगा या नहीं: पता स्थान एक-दूसरे को ओवरलैप नहीं कर सकते, और resolver के सबनेट पर नेटवर्क सुरक्षा समूह को क्लाइंट पूल स्वीकार करना होगा, जो केवल एक और स्रोत श्रेणी है। इसे VM पक्ष से प्रभावी-रूट जाँच और क्लाइंट से एक सीधे प्रश्न के साथ सिद्ध करें, ताकि ज़ोन समस्या, प्रत्यय समस्या या फ़िल्टर को कभी अनुपस्थित ट्रांज़िट न समझा जाए।