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 कडे निर्देश करणारे सार्वजनिक होस्टनाव दुरुस्त करत नाही.