ddclient VPN एग्ज़िट प्रकाशित करता है: खोज स्रोत ठीक करें

आपका DNS नाम अब VPN प्रदाता के पते पर रिज़ॉल्व होता है, और अपडेट लॉग बिल्कुल स्वस्थ दिखता है। यह संयोजन सामान्य है। वेब-आधारित खोज प्रोब किसी बाहरी सेवा से पूछता है कि उसे कौन-सा स्रोत दिखता है, और जब अनुरोध पूर्ण-टनल VPN से बाहर जाता है, तो उत्तर VPN एग्ज़िट होता है, आपका घरेलू WAN पता नहीं। अपडेटर ने अपना काम किया; काम गलत अवलोकन की ओर निर्देशित था।

पुष्टि करें कि नाम को कहाँ पहुँचना है

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

VPN क्लाइंट के टनल पते के लिए निजी नाम दूसरे उत्तर वाली दूसरी समस्या है: वह निजी DNS में रहता है, और उसे सार्वजनिक खोज सेवा की ज़रूरत ही नहीं। दोनों आवश्यकताओं को मिलाना ही वह तरीका है जिससे काम करता कॉन्फ़िगरेशन ऐसा पता प्रकाशित करने लगता है जो किसी ने नहीं माँगा।

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

कुछ भी बदलने से पहले मान का पुनरुत्पादन करें

दोनों मार्गों को अलग-अलग देखें। टनल चालू होने पर प्रोब एग्ज़िट की रिपोर्ट करता है; टनल बंद होने पर, या प्रोब के भौतिक इंटरफ़ेस से बँधे होने पर, वह घर का पता बताता है: curl --interface eth0 https://ifconfig.me. यदि वे दोनों उत्तर भिन्न हैं, तो आपने अपडेटर को छुए बिना दोष का पुनरुत्पादन कर लिया है।

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

खोज को चुने गए मार्ग पर निर्देशित करें

यदि नाम को घरेलू WAN पता प्रकाशित करना है, तो खोज को वही पता देखना होगा। तीन विकल्प काम करते हैं, लगभग वरीयता क्रम में: राउटर को उसके अपने समर्थित अपडेटर से प्रकाशित करने दें; राउटर जिस पृष्ठ की वास्तव में सेवा देता है, उसके विरुद्ध ddclient की राउटर-स्थिति खोज का उपयोग करें; या वेब प्रोब रखें पर उसे भौतिक इंटरफ़ेस से बाँधें ताकि वह टनल के बाहर से निकले।

राउटर-स्थिति मार्ग के लिए, नए ddclient संस्करण usev4 और fwv4 विकल्प परिवार का उपयोग करते हैं, आसपास के पृष्ठ पाठ के लिए वैकल्पिक स्किप पैटर्न के साथ। अपने स्थापित संस्करण का README देखें, क्योंकि पुराने संस्करण वही विचार use और fw से लिखते हैं, और गलत संस्करण से कॉपी किया गया विकल्प नाम शुरू होते समय विफल हो जाता है।

यदि आप वेब खोज रखते हैं, तो याद रखें कि प्रोब का रूटिंग और अपडेट API कॉल का रूटिंग अलग निर्णय हैं। अपडेट कॉल रिकॉर्ड पहुँचाता है; प्रोब तय करता है कि कौन-सा मान पहुँचाया जाए।

रहस्य और संस्करण सुव्यवस्थित रखें

राउटर क्रेडेंशियल और प्रदाता टोकन सुरक्षित कॉन्फ़िगरेशन फ़ाइल में होने चाहिए, shell इतिहास में पहुँचने वाली कमांड लाइन पर नहीं। विस्तृत ट्रेस में दोनों हो सकते हैं, इसलिए टिकट में चिपकाने से पहले उन्हें हटाएँ। जिस खोज विधि के लिए प्रमाणित राउटर पृष्ठ स्क्रैप करना पड़े, उसमें फ़र्मवेयर अपडेट के दौरान भी वह क्रेडेंशियल काम करता रहना चाहिए। प्रदाता टोकन जैसी ही सावधानी से उसे रखें।

ddclient README खोज दृष्टिकोणों और उनके विकल्प नामों का दस्तावेज़ीकरण करता है। एक ही रिकॉर्ड में IPv4 और IPv6 परिणाम न मिलाएँ, और यह न मानें कि एक संस्करण में मौजूद विकल्प दूसरे में भी है।

मान सत्यापित करें, फिर पहुँच

लाइव अपडेट की अनुमति देने से पहले प्रस्तावित पते की इच्छित एंडपॉइंट से तुलना करें, फिर एक अधिकृत अपडेट के बाद आधिकारिक DNS जाँचें और रिज़ॉल्वर कैश का हिसाब रखें। कम TTL प्रतीक्षा घटाता है; गलत मान को सही नहीं बनाता।

रिकॉर्ड सही होने के बाद ही, आवश्यक फ़ायरवॉल और फ़ॉरवर्डिंग पहले से स्वीकृत होने पर, स्वतंत्र नेटवर्क से आवक सेवा का परीक्षण करें। सही A रिकॉर्ड पहुँच-योग्य सेवा सिद्ध नहीं करता, और स्थिर VPN लीज़ निजी नामकरण को सरल बना सकती है, पर गलत WAN की ओर इशारा करते सार्वजनिक होस्टनाम को ठीक नहीं करती।