ISP परिवर्तन गर्नुहोस्, साइट VPN ठेगाना फेरि नम्बर नगरी

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

स्वतन्त्र रूपमा सर्ने दुई ठेगाना योजना

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

प्रदायक परिवर्तनले बाहिरी योजनालाई छुन्छ। यसले आफैंमा भित्री योजना बदल्न आवश्यक ठान्दैन।

दुई सूची अलग राख्नु नै अनुप्रयोगले पहिले नै आफ्नो ट्राफिक इन्क्रिप्ट गरे पनि ओभरले चलाउने व्यावहारिक कारण हो। ओभरलेले तपाईंलाई बाहिरी परिवर्तन सहने स्थिर भित्री टोपोलोजी दिन्छ। अनुप्रयोगले आफ्नो ठेगाना, फायरवाल नियम र DNS रेकर्ड राख्छ। केवल यातायात प्रविष्टि बदलिन्छ, र त्यो धेरै सानो समीक्षा हो।

बाहिरी टनेलले भित्री कुराकानी बोक्छ

गेटवे-देखि-गेटवे टनेलमा बाहिरी IP शीर्षलेखले दुई गेटवेलाई ठेगाना दिन्छ। भित्री शीर्षलेखले अझै अनुप्रयोगका वास्तविक अन्त्य बिन्दुको नाम लिन्छ। RFC 7296 को गेटवे-देखि-गेटवे वर्णन ले यसलाई टनेलका अन्त्य बिन्दुबाट ट्राफिक पुर्‍याउने साधारण रुटिङ मान्छ।

त्यसैले गेटवेको सार्वजनिक ठेगाना बदलिँदा पनि शाखा सर्भरले 10.55.8.20 राख्न सक्छ। भित्री प्याकेटमा प्रदायकको ठेगाना नै हुँदैन।

यो विभाजन डिजाइनको गुण हो, स्वचालित ग्यारेन्टी होइन। यदि प्रतिस्थापन अपलिङ्कले समर्थित टनेल स्थापना गर्न सक्दैन, वा भित्री मार्ग पुनः स्थापित हुँदैनन् भने, ठेगाना नबदलिए पनि अनुप्रयोगले आफ्नो बाटो गुमाउँछ।

प्रदायक सार्ने काममा अझै जाँच सूची छ

बाहिरी जाँच सूचीमा पाँच प्रविष्टि छन्: पियर ठेगाना वा राखिएको नाम, श्रोता र कुनै पनि माथिल्लो फिल्टरिङ, मार्गमा अनुवाद, अपेक्षित पियर पहिचान, र अर्को गेटवेका अनुमत सेटिङ। प्रत्येक अलगै असफल हुन सक्छ। प्रशासन बोक्ने लिङ्क बदल्दा अलग उद्धार मार्ग राख्नुहोस्। अपलिङ्क परिवर्तनका बेला टाढाको पहुँच काट्नु तपाईं आफैंले सिर्जना गरेको अवरोध हो।

त्यसपछि शाखा प्रिफिक्स, दुवै दिशाको मार्ग, संरक्षण नीति र एउटा वास्तविक अनुप्रयोग प्रवाह जाँच्नुहोस्। भर्खरै प्रमाणित टनेलले पुरानो निजी सबनेटतर्फ देखाउने मार्ग सुधार्दैन।

अर्को जोडिएको साइटसँग ठेगाना ओभरल्याप हुनु अलग योजना समस्या हो। प्रदायक परिवर्तनले त्यो सिर्जना गर्दैन, तर स्थानान्तरण नै सामान्यतया त्यो देखा पर्ने समय हो।

के टिक्दैन: सार्वजनिक स्रोत र सत्रहरू

स्थिर निजी सर्भर ठेगाना स्थिर सार्वजनिक स्रोत होइन। यदि ब्राउजिङ सिधै नयाँ प्रदायकबाट बाहिर जान्छ भने, वेबसाइटहरूले नयाँ प्रदायकतर्फ फर्केको ठेगाना देख्छन्।

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

स्थापित सत्रहरूले पनि मार्ग परिवर्तन सहँदैनन्। टनेल सेकेन्डभित्र फेरि स्थापित हुन सक्छ र तैपनि पुरानो मार्गमा बाँधिएका लामो अवधिका जडान तोड्न सक्छ। पुनः जडान स्वीकार्य हुने झ्यालका लागि परिवर्तन योजना गर्नुहोस्। विशिष्ट क्लाइन्ट र तिनका समयसीमा परीक्षण नगरी स्थानान्तरण अदृश्य हुने दाबी नगर्नुहोस्।

चार जाँचले सार्ने काम प्रमाणित गर्नुहोस्

परिवर्तनपछि चार कुरा क्रममा जाँच्नुहोस्: टनेल इच्छित पियरसँग स्थापित छ, शाखा प्रिफिक्ससम्म भित्री मार्ग छ, नीतिले अनुप्रयोग प्रवाहलाई अनुमति दिन्छ र अनुप्रयोगले जवाफ दिन्छ। प्रत्येकको आफ्नै आदेश छ।

Linux गेटवेमा, यी तीनले त्यो सूचीको मध्य भाग ढाक्छन्:

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

यातायात ठेगाना एउटा सूचीमा र अनुप्रयोगका ठेगाना अर्कोमा राख्नुहोस्। साँच्चै सरेका प्रविष्टि मात्र अद्यावधिक गर्नुहोस्। टनेलको बाहिरी ठेगाना बदलिएको कारण भित्री निर्भरता पुनःनम्बर गर्नु टार्न सकिने काम हो।