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 बाजूने प्रभावी-मार्ग तपासणी आणि क्लायंटकडून एक थेट प्रश्न याने ते सिद्ध करा, जेणेकरून झोन समस्या, प्रत्यय समस्या किंवा फिल्टर कधीही अनुपस्थित ट्रान्झिट समजला जाणार नाही.