VPN एंडपॉइंट नाम बनाम निजी सेवा नाम: दो मालिक

दो नाम एक ही शाखा का वर्णन कर सकते हैं और पूरी तरह अलग सवालों के जवाब दे सकते हैं। vpn.branch.example दूर के साथी को बताता है कि VPN एंडपॉइंट कहाँ मिलेगा, और किसी भी टनल के बनने से पहले इसे हल होना चाहिए। inventory.branch.example अधिकृत उपयोगकर्ता को बताता है कि निजी एप्लिकेशन कहाँ रहता है, और टनल चालू होने के बाद ही यह मायने रखता है। एक का रखरखाव दूसरे के लिए कुछ नहीं करता।

किसी भी एक को डीबग करने से पहले दोनों रिकॉर्ड के नाम लिखें

दोनों को उनके मालिकों के साथ लिखें। एंडपॉइंट के लिए दर्ज करें कि सार्वजनिक पता कौन अपडेट करता है और VPN क्लाइंट अपना जवाब कैसे ताज़ा करता है। सेवा के लिए दर्ज करें कि निजी पते का मालिक कौन है, कौन-सा ज़ोन रिकॉर्ड रखता है और किन रिज़ॉल्वरों को इसके लिए जवाब देना चाहिए।

यह छोटी सूची इस क्षेत्र का सबसे आम गलत निदान रोकती है: किसी चालू शाखा टनल को फिर से शुरू करना, ऐसे रिकॉर्ड को ठीक करने के लिए जो पूरी तरह उसी के अंदर रहता है। टनल सेवा नाम के लिए परिवहन है; यह उसका अधिकार नहीं है।

जब कोई बदलाव प्रस्तावित हो, तो पूछें कि वह दोनों में से किस रिकॉर्ड को छूता है। अगर कोई जवाब नहीं दे सकता, तो बदलाव निर्धारण के लिए तैयार नहीं है।

किसी भी टनल के बनने से पहले एंडपॉइंट हल होना चाहिए

मान लें कि शाखा का इंटरनेट कनेक्शन नया सार्वजनिक पता पाता है। एंडपॉइंट अपडेटर नया पता प्रकाशित करता है, और दूर का VPN कार्यान्वयन बदला हुआ जवाब पढ़ सकना चाहिए। जो भी रिज़ॉल्वर वह जवाब देता है उसे टनल के बिना पहुँचा जा सकना चाहिए, वरना क्लाइंट ऐसे नाम के पीछे भाग रहा है जिसे वह उस चीज़ से जुड़ने के बाद ही हल कर सकता है जिसे वह खोज नहीं पाता।

यह शुरुआती निर्भरता स्पष्ट कहने योग्य है, क्योंकि सभी आंतरिक रिज़ॉल्वर VPN के पीछे होने पर इसे गलती से बनाना आसान है। एंडपॉइंट खोज के लिए टनल से पहले का पथ रखें, और नया जवाब तुरंत उठा लिया जाता है यह मानने के बजाय क्लाइंट के पुनः कनेक्ट व्यवहार की पुष्टि करें।

गतिशील DNS की भी सीमाएँ हैं जिन्हें रिकॉर्ड अपडेट पार नहीं कर सकता। रिकॉर्ड अपडेट करने से कोई फ़ायरवॉल पोर्ट नहीं खुलता, कोई NAT मैपिंग नहीं बनती और किसी साथी की पहचान सिद्ध नहीं होती। बंद पोर्ट वाला प्रकाशित पता ऐसा क्लाइंट देता है जो सही हल करता है और फिर भी किसी चीज़ से जुड़ नहीं सकता।

अंत में, चल रहा क्लाइंट पुनः कनेक्ट होने तक कैश किए गए एंडपॉइंट का उपयोग जारी रख सकता है। अपने नोट्स में प्रकाशन, कैश और पुनः कनेक्ट नीति को अलग रखें, ताकि पुराना साथी खराब अपडेटर न समझा जाए।

सेवा का नाम बताता है कि एप्लिकेशन कहाँ रहता है

अब मान लें कि टनल स्वस्थ रहता है लेकिन इन्वेंटरी सर्वर 172.26.14.20 से 172.26.14.35 पर चला जाता है। सार्वजनिक एंडपॉइंट रिकॉर्ड अप्रभावित रहता है, जबकि निजी सेवा रिकॉर्ड बदलना पड़ता है। उस सेवा के लिए आरक्षित पता या स्थिर आवंटन इस्तेमाल करने से यह दुर्लभ होता है; अधिकृत अपडेट पथ उन बारों को संभालता है जब यह जानबूझकर होता है।

यहाँ दो अपडेट तंत्र आपस में मिल जाते हैं। RFC 2136 एक ज़ोन में DNS रिकॉर्ड जोड़ने और हटाने के लिए प्रोटोकॉल परिभाषित करता है, जबकि वाणिज्यिक गतिशील DNS प्रदाता किसी और उद्देश्य के लिए पूरी तरह अलग HTTP API दे सकता है। एक का उपयोग यह नहीं बताता कि दूसरा आपके वातावरण में है। इसके विरुद्ध अपडेटर लिखने से पहले जाँचें कि आपका ज़ोन वास्तव में कौन-सा तंत्र स्वीकार करता है।

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

दोनों पथों को अलग-अलग जाँचें

टनल के बाहर से एंडपॉइंट और उसके अंदर से सेवा जाँचें, और परिणामों को दो स्वतंत्र तथ्यों के रूप में रखें:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

अगर पहली क्वेरी विफल हो, तो समस्या सार्वजनिक प्रकाशन या टनल से पहले के रिज़ॉल्यूशन पथ में है, और कोई आंतरिक बदलाव मदद नहीं करेगा। अगर दूसरी पता लौटाती है लेकिन तीसरी टनल से होकर कोई मार्ग नहीं दिखाती, तो DNS परत ठीक है और फ़ॉरवर्डिंग नीति नहीं।

हर पता बदलाव के बाद जोड़ी चलाएँ और नोट करें कि कौन-सा रिकॉर्ड हिला। जो हैंडओवर केवल कहता है «DNS अपडेट हुआ» वह अगले इंजीनियर को अनुमान लगाने पर छोड़ देता है कि दो जीवनचक्रों में से कौन-सा वास्तव में चला।