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 खोल्नुहोस्, अन-प्रिमाइसबाट एउटा नाम परीक्षण गर्नुहोस्, र त्यसपछि मात्र अनुप्रयोगको आफ्नै अनुमति हेर्नुहोस्।