घरच्या 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 स्वतः अपडेट यंत्रणेचे वर्णन करते, डेमॉन तारेवर काय ठेवतो हे पाहायचे असल्यास.