VPN वर Azure चे खाजगी DNS: रिझोल्व्हर एंडपॉइंट की फॉर्वर्डर
दोन्ही डिझाइन बोगद्यातून खाजगी झोनना उत्तर देतात. व्यवस्थापित इनबाउंड एंडपॉइंटची फॉर्वर्डर VM शी तुलना करा, नंतर दोन्ही बाबतीत असावा लागणारा मार्ग तपासा.
ऑन-प्रिमाइसचा सर्व्हर खाजगी पत्त्याने Azure VM पर्यंत पोहोचतो आणि तरीही त्याचे खाजगी होस्टनेम सोडवू शकत नाही, त्यामुळे लोक तुटलेली बोगदा शोधू लागतात. बोगदा ठीक आहे. जे कमी आहे ती DNS सीमा आहे: ऑन-प्रिमाइस बाजूला कोणालाही माहीत नाही की एखाद्या विशिष्ट Azure खाजगी झोनला VNet मधील रिझोल्व्हरने उत्तर द्यायचे आहे. दोन डिझाइन ही पोकळी भरतात आणि ते शेवटी तुम्ही काय चालवता यात वेगळे आहेत, क्वेरी चालतात का यात नाही.
बोगदा क्वेरी वाहतो, झोनचे ज्ञान नाही
साइट-टू-साइट कनेक्शन पॅकेटना दोन नेटवर्कमध्ये मार्ग देतो. ते ऑन-प्रिमाइस DNS सर्व्हरला सांगत नाही की कोणती नावे जागा Azure ची आहे किंवा कोणता पत्ता उत्तर देईल, म्हणून क्वेरी एकतर इंटरनेटवर जाते आणि रिकामी परत येते, किंवा स्थानिक रिझोल्व्हरमधून कधीच बाहेर पडत नाही.
उपायाचे सहज वेगळे करता येणारे दोन अर्धे आहेत. एक अर्धा बोगद्यातून येणाऱ्या क्वेरी स्वीकारणारा VNet मधील रिझोल्व्हर आहे. दुसरा अर्धा ऑन-प्रिमाइस बाजूचा सशर्त फॉर्वर्डर आहे जो नेमकी एक नावे जागा त्या रिझोल्व्हरला पाठवतो. कोणताही अर्धा एकटा चालत नाही.
या संपूर्ण वर्णनासाठी झोन cloud.corp.example आहे असे गृहीत धरा आणि प्रत्येक पत्ता उदाहरण माना.
पर्याय A: व्यवस्थापित इनबाउंड एंडपॉइंट
Azure DNS Private Resolver VNet च्या बाहेरून येणाऱ्या DNS क्वेरी स्वीकारणारा इनबाउंड एंडपॉइंट देतो. तुम्ही तो समर्पित प्रत्यायोजित सबनेटमध्ये तैनात करता, खाजगी झोन त्या VNet शी जोडता आणि सेवा देते तो इनबाउंड पत्ता नोंदवता.
नंतर ऑन-प्रिमाइस DNS सर्व्हरवर नेमक्या नावे जागेसाठी त्या पत्त्याकडे सशर्त फॉर्वर्डर तयार करता:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoft ची हायब्रिड DNS प्रक्रिया झोन लिंक आणि फॉर्वर्डर टप्पा दोन्ही नोंदवते. व्यवस्थापित मार्गात पॅच करायला DNS सॉफ्टवेअर उरत नाही आणि एंडपॉइंटचा पत्ता संसाधनाच्या संपूर्ण आयुष्यभर स्थिर राहतो.
किंमत ही आहे की आता तुमच्याकडे रिझोल्व्हर संसाधन, त्याचे सबनेट प्रत्यायोजन आणि त्याचा खर्च आहे, जो क्वेरीचे प्रमाण अगदी कमी असतानाही वास्तविक आहे.
पर्याय B: VNet मधील फॉर्वर्डर VM
जुने डिझाइन VNet मधील साध्या VM वर DNS सॉफ्टवेअर चालवते: Windows DNS, BIND किंवा dnsmasq, आणि खाजगी झोन एकतर स्थानिक पातळीवर होस्ट होतो किंवा 168.63.129.16 वरील Azure रिझोल्व्हरकडे पाठवला जातो. ऑन-प्रिमाइस सशर्त फॉर्वर्डर त्या VM च्या खाजगी पत्त्याकडे निर्देश करतो.
हा पर्याय आधीच DNS सर्व्हर चालवणाऱ्या संघांना परिचित आहे आणि लॉगिंग किंवा स्प्लिट-होरायझन उत्तरांसारखे अतिरिक्त तर्क वाहू शकतो. तो DNS सर्व्हरची प्रत्येक कार्यान्वयन जबाबदारीही वारसाहक्काने घेतो: पॅचिंग, उपलब्धतेसाठी दुसरी आवृत्ती, देखरेख आणि VM बदलल्यावर व त्याचा पत्ता बदलल्यावर पुनर्बांधणीचा मार्ग.
साधा VNet होस्ट सेवा स्थापित होईपर्यंत आणि त्या क्लायंटना उत्तर देण्याची परवानगी मिळेपर्यंत DNS प्रॉक्सी नाही, आणि VM क्लोन करताना लोक हाच टप्पा वगळतात.
कोणते तुमच्या कार्यासाठी योग्य आहे
तुलना कोणते डिझाइन वेगवान आहे याबद्दल नाही. ती याबद्दल आहे की तुम्हाला DNS सॉफ्टवेअर चालवायचे आहे का, आणि क्वेरीचे प्रमाण एंडपॉइंट व क्वेरीनुसार बिल करणाऱ्या व्यवस्थापित संसाधनाला न्याय्य ठरवते का.
| Question | Managed inbound endpoint | Forwarder VM |
|---|---|---|
| Software to patch | None | The DNS service on every instance |
| Address stability | Fixed for the resource lifetime | Tied to the VM or its reserved address |
| Availability work | Handled by the service | Second instance, health checks, failover |
| Extra logic | Limited to resolver features | Whatever the DNS software supports |
कोणतीही ओळ निर्णय घेवो, ऑन-प्रिमाइस फॉर्वर्डर नियम सारखाच दिसतो. हा भाग दोन्ही डिझाइनमध्ये असणे आवश्यक आहे आणि Azure मधून रिझोल्यूशन चालते पण कार्यालयातून चालत नाही असे कोणी सांगितल्यावर सर्वात जास्त गहाळ होणारा भाग हाच असतो.
मार्ग क्रमाने तपासा
झोन रिझोल्व्हर असलेल्या VNet शी जोडलेला आहे आणि ऑन-प्रिमाइस फॉर्वर्डर पालक डोमेन नव्हे तर नावे जागा नाव देतो याची खात्री करा. corp.example साठीचा फॉर्वर्डर रिझोल्व्हरने स्वतः प्रत्यायोजित केल्याशिवाय cloud.corp.example शी जुळणार नाही, आणि ही विसंगती गहाळ रेकॉर्डसारखे दिसणारे स्वच्छ नकारात्मक उत्तर देते.
नंतर क्वेरी एंडपॉइंटपर्यंत पोहोचते का तपासा: ऑन-प्रिमाइस स्रोताला रिझोल्व्हर पत्त्यापर्यंत मार्ग आणि परतीचा मार्ग लागतो, आणि धोरण परवानगी देतो तिथे UDP व TCP दोन्हीसाठी पोर्ट 53 उघडा असावा. NSG गहाळ झोन रेकॉर्ड देऊ शकत नाही आणि बरोबर झोन कधीही न येणाऱ्या क्वेरीला उत्तर देऊ शकत नाही.
निदान करताना मागितलेला FQDN निवडलेल्या रिझोल्व्हरजवळ ठेवा आणि टाइमआउट नकारात्मक उत्तरापासून वेगळा करा. टाइमआउट मार्ग किंवा धोरणाची समस्या आहे. नकारात्मक उत्तर म्हणजे क्वेरी पोहोचली आणि नावे जागा जुळली नाही. कामाचा क्रम: झोन जोडा, सशर्त फॉर्वर्डर जोडा, दोन्ही दिशांना पोर्ट 53 उघडा, ऑन-प्रिमाइसवरून एक नाव तपासा आणि त्यानंतरच अनुप्रयोगाची स्वतःची अधिकृतता पहा.