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

वाहतूक पत्ते एका यादीत आणि अनुप्रयोगाचे पत्ते दुसऱ्यात ठेवा. खरेच हललेल्या नोंदीच अद्ययावत करा. टनेलचा बाहेरील पत्ता बदलल्यामुळे आतील अवलंबित्वे पुन्हा क्रमांकित करणे हे टाळता येण्याजोगे काम आहे.