VPN अन्त्य बिन्दुको नाम र निजी सेवाको नाम: दुई मालिक

दुई नामले एउटै शाखाको वर्णन गर्न सक्छन् र पूर्ण रूपमा फरक प्रश्नको जवाफ दिन सक्छन्। vpn.branch.example ले टाढाको साझेदारलाई VPN अन्त्य बिन्दु कहाँ भेटिन्छ भनी बताउँछ, र कुनै पनि सुरुङ बन्नुअघि यो समाधान हुनुपर्छ। inventory.branch.example ले अधिकृत प्रयोगकर्तालाई निजी अनुप्रयोग कहाँ बस्छ भनी बताउँछ, र सुरुङ बनेपछि मात्र यसको महत्त्व हुन्छ। एउटाको मर्मतले अर्कोका लागि केही गर्दैन।

कुनै पनि एकलाई डिबग गर्नुअघि दुवै रेकर्डको नाम राख्नुहोस्

दुवैलाई तिनका मालिकसँगै लेख्नुहोस्। अन्त्य बिन्दुका लागि सार्वजनिक ठेगाना कसले अद्यावधिक गर्छ र VPN क्लाइन्टले आफ्नो जवाफ कसरी ताजा गर्छ लेख्नुहोस्। सेवाका लागि निजी ठेगानाको मालिक को हो, कुन जोनले रेकर्ड राख्छ र कुन रिजोल्भरहरूले यसका लागि जवाफ दिनुपर्छ लेख्नुहोस्।

यो छोटो सूचीले यस क्षेत्रको सबैभन्दा सामान्य गलत निदान रोक्छ: पूर्ण रूपमा भित्रै बस्ने रेकर्ड सुधार्न काम गरिरहेको शाखा सुरुङ पुनः सुरु गर्नु। सुरुङ सेवाको नामका लागि यातायात हो; यो त्यसको अधिकार होइन।

परिवर्तन प्रस्ताव गरिँदा दुई रेकर्डमध्ये कुनलाई छुन्छ भनी सोध्नुहोस्। यदि कोही जवाफ दिन सक्दैन भने परिवर्तन तालिकाका लागि तयार छैन।

कुनै पनि सुरुङ बन्नुअघि अन्त्य बिन्दु समाधान हुनुपर्छ

मान्नुहोस् शाखाको इन्टरनेट जडानले नयाँ सार्वजनिक ठेगाना पायो। अन्त्य बिन्दु अद्यावधिककर्ताले नयाँ ठेगाना प्रकाशित गर्छ, र टाढाको VPN कार्यान्वयनले परिवर्तित जवाफ पढ्न सक्नुपर्छ। जुनसुकै रिजोल्भरले त्यो जवाफ दिए पनि त्यो सुरुङ बिना पहुँचयोग्य हुनुपर्छ, नत्र क्लाइन्ट आफूले भेट्न नसक्ने कुरासँग जोडिएपछि मात्र समाधान गर्न सक्ने नामको पछि दौडिरहेको हुन्छ।

यो सुरुवाती निर्भरता स्पष्ट भन्न योग्य छ, किनकि सबै आन्तरिक रिजोल्भरहरू VPN पछाडि हुँदा यसलाई दुर्घटनावश बनाउन सजिलो छ। अन्त्य बिन्दु खोजीका लागि सुरुङअघिको मार्ग राख्नुहोस्, र नयाँ जवाफ तुरुन्तै लिइन्छ भनी मान्नुको सट्टा क्लाइन्टको पुनःजडान व्यवहार पुष्टि गर्नुहोस्।

गतिशील DNS का पनि सीमाहरू छन् जुन रेकर्ड अद्यावधिकले पार गर्न सक्दैन। रेकर्ड अद्यावधिक गर्दा कुनै फायरवाल पोर्ट खुल्दैन, NAT म्यापिङ बन्दैन र कुनै साझेदारको पहिचान प्रमाणित हुँदैन। बन्द पोर्टसहित प्रकाशित ठेगानाले सही रूपमा समाधान गर्ने तर कुनै पनि कुरासँग जोडिन नसक्ने क्लाइन्ट दिन्छ।

अन्तमा, चलिरहेको क्लाइन्टले पुनः जोडिनुअघि क्यास गरिएको अन्त्य बिन्दु प्रयोग गरिरहन सक्छ। आफ्ना टिप्पणीमा प्रकाशन, क्यास र पुनःजडान नीति अलग राख्नुहोस्, ताकि पुरानो साझेदारलाई बिग्रिएको अद्यावधिककर्ता ठानिँदैन।

सेवाको नामले अनुप्रयोग कहाँ बस्छ भनी वर्णन गर्छ

अब मान्नुहोस् सुरुङ स्वस्थ रहन्छ तर सूची सर्भर 172.26.14.20 बाट 172.26.14.35 मा सर्छ। सार्वजनिक अन्त्य बिन्दु रेकर्ड अप्रभावित रहन्छ, जबकि निजी सेवा रेकर्ड परिवर्तन हुनुपर्छ। त्यो सेवाका लागि आरक्षित ठेगाना वा स्थिर बाँडफाँट प्रयोग गर्दा यो दुर्लभ हुन्छ; अधिकृत अद्यावधिक मार्गले त्यो जानाजान भएका अवसरहरू सम्हाल्छ।

यहाँ दुई अद्यावधिक संयन्त्र मिसिन्छन्। RFC 2136 ले जोनमा DNS रेकर्ड थप्न र हटाउन प्रोटोकल परिभाषित गर्छ, जबकि व्यावसायिक गतिशील DNS प्रदायकले अर्कै उद्देश्यका लागि पूर्ण रूपमा फरक HTTP API देखाउन सक्छ। एउटा प्रयोग गर्नु भनेको अर्को तपाईंको वातावरणमा छ भन्ने होइन। यसको विरुद्ध अद्यावधिककर्ता लेख्नुअघि तपाईंको जोनले वास्तवमा कुन संयन्त्र स्वीकार्छ जाँच्नुहोस्।

सही निजी जवाफ पहिलो सर्त मात्र हो। टाढाको कलरले यसलाई प्रयोग गर्नका लागि क्लाइन्टलाई निजी जोन बोक्ने रिजोल्भर, त्यो रिजोल्भरमा प्रश्नहरू अनुमति दिने नीति, र फर्किने ठेगानाका लागि फर्वार्डिङ चाहिन्छ। क्लाइन्टले पुग्न नसक्ने ठेगानामा समाधान हुने नामले सर्भर खराबीजस्तो देखिने समय समाप्ति उत्पन्न गर्छ।

दुवै मार्ग छुट्टाछुट्टै परीक्षण गर्नुहोस्

सुरुङ बाहिरबाट अन्त्य बिन्दु र भित्रबाट सेवा जाँच्नुहोस्, र नतिजा दुई स्वतन्त्र तथ्यका रूपमा राख्नुहोस्:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

यदि पहिलो प्रश्न असफल भयो भने समस्या सार्वजनिक प्रकाशन वा सुरुङअघिको समाधान मार्गमा छ, र कुनै आन्तरिक परिवर्तनले सहयोग गर्दैन। दोस्रोले ठेगाना फर्काए पनि तेस्रोले सुरुङ हुँदै कुनै मार्ग देखाएन भने DNS तह ठीक छ र फर्वार्डिङ नीति ठीक छैन।

प्रत्येक ठेगाना परिवर्तनपछि जोडी चलाउनुहोस् र कुन रेकर्ड सर्यो लेख्नुहोस्। केवल «DNS अद्यावधिक भयो» भन्ने हस्तान्तरणले अर्को इन्जिनियरलाई दुई जीवनचक्रमध्ये कुन साँच्चै चल्यो भनी अनुमान गर्न छोड्छ।