resolver पियर गरिएको VNet मा हुँदा Azure P2S DNS असफल हुन्छ

VM लाई पिङ गर्नुहोस् र त्यसले जवाफ दिन्छ; त्यसको नाम सोध्नुहोस् र क्लाइन्ट भन्छ होस्ट अज्ञात छ। जब 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 जोनहरूलाई जवाफ दिन्छ, तर तपाईंका आफ्नै डाइरेक्टरी सर्भरमा होस्ट गरिएको जोनका लागि केही दिँदैन, र यही तैनाथीले त्यही प्रयोग गर्छ। क्लाइन्टलाई त्यहाँ देखाउनुहोस् र सार्वजनिक नामहरू खुसीसाथ समाधान हुन्छन् जबकि आन्तरिक होस्ट अज्ञात रहन्छ।

अरू केही बदल्नु अघि जोडिएको ल्यापटपबाट resolver लाई सोध्नुहोस्।

nslookup dc01.corp.example 10.1.0.4

समय सकिनुले मार्ग अझै छैन भन्छ। आधिकारिक जवाफले समस्या क्लाइन्टतर्फ धकेल्छ, सामान्यतया कहिल्यै नजोडिने प्रत्यय, त्यसैले छोटा नामहरू तिनलाई खुसीसाथ असफल गराउने सार्वजनिक resolver तर्फ जान्छन्।

साइट-टु-साइट पक्षमा त्यही सम्झौता तुलना गर्नुहोस्

यीमध्ये केही पनि विशेष रूपमा ल्यापटपको होइन। क्लाइन्टको ठाउँमा साइट-टु-साइटको शाखा राख्नुहोस् र दुई पक्षको सर्त फर्किन्छ: शाखा सिधै गेटवे नेटवर्कमा आउँछ, र दुई नेटवर्क टाढाको सेवा अझै पियरिङ पछाडि छ।

ट्रान्जिट दुवै पियरिङमा दिनुपर्छ, र जो स्विच यो दिन्छ त्यो क्लाइन्ट प्रकारमा होइन, पियरिङमा बस्छ।

गेटवेलाई दोष दिनु अघि

Windows हरेक एडाप्टरका लागि resolver सूची राख्छ, त्यसैले गेटवेलाई दोष दिनु अघि टनेल इन्टरफेसले वास्तवमै के पायो पक्का गर्नुहोस्।

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

नकारात्मक जवाफ क्यासमा राउटिङ सुधारभन्दा लामो बस्छ, र पुरानो प्रत्यय सूचीले जोन कहिल्यै होस्ट नभएको ठाउँमा प्रश्नहरू पठाइरहन्छ। फ्ल्यास गर्नुहोस्, फेरि सोध्नुहोस्, र कुन सर्भरले जवाफ दिन्छ नोट गर्नुहोस्।

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