घरको VPN सर्भरका लागि डाइनामिक DNS आवश्यक छ?

डाइनामिक 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 ले अपडेट संयन्त्र आफैं वर्णन गर्छ, डेमनले तारमा के राख्छ देख्न चाहनुहुन्छ भने।

सम्बन्धित लेखहरू