क्या घर के VPN सर्वर के लिए डायनामिक DNS चाहिए?

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

शर्त एक: आपका पता वास्तव में बदलता है

घरेलू पते सामान्य कारणों से बदलते हैं: बिजली जाने के बाद मॉडम फिर सिंक होता है, ISP पूल फिर से संतुलित करता है, लंबे व्यवधान के बाद नया लीज़ आता है। कुछ लाइनों पर वे बहुत कम बदलते हैं, और मैंने एक ही पता साल भर टिकते देखा है; व्यावसायिक प्लान में अक्सर स्थिर पता होता है। अगर बारह महीनों में कुछ नहीं बदला, तो हाथ से संपादित एक A रिकॉर्ड एक डेमॉन कम ज़िंदा रखने वाली बात है।

अनुमान लगाने के बजाय मापें। राउटर के स्टेटस पेज पर WAN पता पढ़ें, फिर उसकी तुलना बाहरी दुनिया जो देखती है उससे करें। यह LAN की किसी मशीन से चलाएँ:

curl -fsS https://api.ipify.org; echo

अगर दोनों मान अलग हैं, तो आपके राउटर के आगे कुछ अनुवाद कर रहा है और कोई होस्टनेम अपडेट उसे ठीक नहीं करेगा। 100.64.0.0/10 के भीतर का पता कैरियर-ग्रेड NAT के लिए साझा रेंज है, और यही सामान्य कारण है कि सही ढंग से अपडेट किया गया नाम भी बाहर से समय समाप्त हो जाता है।

शर्त दो: क्लाइंट नाम फिर से खोजते हैं

छोटा TTL वह हिस्सा है जिसे लोग छोड़ देते हैं। पुनरावर्ती रिज़ॉल्वर रिकॉर्ड के TTL का सम्मान करते हैं, लेकिन क्लाइंट स्टैक अलग से कैश करते हैं, और पहले से खड़ी सुरंग कुछ भी फिर से हल नहीं करती। डिबग करते समय रिकॉर्ड को 60-300 सेकंड पर रखें; इससे वह खिड़की छोटी होती है जिसमें पुराना उत्तर परोसा जाता है, और यह जुड़े सत्र को स्थानांतरित नहीं करता।

OpenVPN हर बार फिर से जुड़ने पर लाइन remote vpn.example.net 1194 को फिर से हल करता है, और resolv-retry infinite उसे फिर से प्रयास करता रखता है, खोज विफल होने पर बाहर निकलने के बजाय। सर्वर पर float किसी स्थापित सत्र को ऐसे पीयर का अनुसरण करने देता है जिसका स्रोत पता बदल गया है। WireGuard अधिक सीधा है: wg-quick up कॉन्फ़िगरेशन लागू होने पर Endpoint को हल करता है, और क्लाइंट सुरंग फिर से बनाने पर उसे दोबारा हल करता है, इसलिए पुराने पते के विरुद्ध अब भी सफल होने वाला हैंडशेक रुकने तक सफल रहता है।

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

शर्त तीन: अंदर का रास्ता अब भी खुला है

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

बाहर से परखें। Wi-Fi बंद रखकर सेलुलर डेटा पर फ़ोन सबसे सस्ता ईमानदार परीक्षण है; उसी LAN पर लैपटॉप नहीं। जब नाम आपके सार्वजनिक पते पर हल होता है और राउटर में NAT लूपबैक नहीं है, तब अंदर का परीक्षण विफल होता है जबकि रिकॉर्ड पूरी तरह सही है, और यही ज़्यादातर लोगों को ऐसा रिकॉर्ड संपादित करने भेजता है जो कभी ग़लत नहीं था।

तीनों बैठें तो क्या चलाएँ

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

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

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

प्रतिबद्ध होने से पहले जाँचें

एक लुकअप बताता है कि बाक़ी दुनिया क्या देखती है, और वह TTL छापता है जिसका बदलाव के बाद इंतज़ार करना है:

dig +noall +answer vpn.example.net @1.1.1.1

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

एक मिनट में होने वाला रोलबैक रखें: पिछला काम करता पता और पिछला TTL नोट करें, ताकि प्रदाता की ख़राब दोपहर में दोनों हाथ से प्रकाशित कर सकें।

जब उत्तर न हो

अगर शर्त एक या तीन विफल हो, तो कॉन्फ़िगरेशन नहीं बल्कि निर्णय बदलता है। कैरियर NAT के पीछे आपके व्यावहारिक विकल्प हैं ISP से सार्वजनिक पता माँगना, प्रवेश बिंदु को स्थिर पते वाले छोटे VPS पर ले जाना, या ऐसा ओवरले इस्तेमाल करना जो अपनी मुलाक़ात रखता है। अगर पता स्थिर है, तो अपडेटर छोड़ दें: एक A रिकॉर्ड, IPv6 चलाते हैं तो एक AAAA रिकॉर्ड, वही पोर्ट फ़ॉरवर्डिंग।

अगर क्लाइंट जुड़े रहते हुए पता बदले, तो ईमानदार सुधार क्लाइंट में रहता है: पुनः कनेक्शन तर्क और पुनः प्रयास अंतराल, तेज़ अपडेटर नहीं। दूसरा प्रदाता जोड़ना सिर्फ़ अंतराल छिपाता है।

आगे बढ़ने से पहले चार बातें क्रम से पुष्ट करें:

• अपडेटर जो पता प्रकाशित करता है वह राउटर के WAN पते से मेल खाता है।
• रिकॉर्ड का TTL इतना छोटा है कि बदलाव कुछ मिनटों में दिखे।
• पोर्ट फ़ॉरवर्डिंग इंटरफ़ेस से बँधी है, स्थिर पते से नहीं।
• पिछले बदलाव के बाद एक असली क्लाइंट फिर जुड़ा है और ट्रैफ़िक निकला है।

अगर चारों बैठते हैं, तो सेटअप को छोड़ दें; आपकी अगली विफलता नामकरण की समस्या नहीं बल्कि चाबी या फ़ायरवॉल नियम है। अगर कोई विफल हो, तो दूसरा हिलता हिस्सा जोड़ने से पहले उस पंक्ति को ठीक करें। RFC 2136 स्वयं अपडेट तंत्र का वर्णन करता है, अगर आप देखना चाहें कि डेमॉन तार पर क्या रखता है।