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

परिवहन पते एक सूची में और एप्लिकेशन पते दूसरी में रखें। केवल वही प्रविष्टियाँ अद्यतन करें जो वास्तव में हिली हैं। टनल का बाहरी पता बदलने के कारण आंतरिक निर्भरताओं को फिर से नंबर करना टालने योग्य काम है।