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 तर्फ देखाउने सार्वजनिक होस्टनाम सुधार्दैन।