नेटवर्क बदलने पर MOBIKE IKEv2 VPN को कैसे जीवित रखता है

एक फ़ोन Wi-Fi छोड़कर सेलुलर नेटवर्क से जुड़ता है, एक लैपटॉप Ethernet से हॉटस्पॉट पर जाता है, और IKEv2 सुरंग या तो बची रहती है या नहीं। MOBIKE वह एक्सटेंशन है जो उसे बचाए रखता है, दूर के सिरे को बताकर कि स्रोत पता बदल गया है, शुरू से फिर शुरू करने के बजाय। जो यह नहीं करता, वह है बदलाव के दौरान हर ऐप्लिकेशन को जीवित रखना। ये दो दावे हैं, और दूसरा वही है जो लोग आम तौर पर मतलब रखते हैं।

बदलाव को चरणों में देखें, क्योंकि हर चरण अलग तरह से विफल होता है।

अपडेट वास्तव में क्या बदलता है

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

MOBIKE ट्रैफ़िक को UDP एन्कैप्सुलेशन में भी ले जा सकता है, इसीलिए काम करती सुरंग कभी-कभी नेटवर्क बदलने के बाद पोर्ट 4500 का उपयोग करने लगती है। वह बदलाव अपने आप यह साबित नहीं करता कि NAT पहचाना गया, हालाँकि दोनों अक्सर साथ दिखते हैं।

क्या आपकी प्रोफ़ाइल वाकई इसे सक्षम करती है

दोनों पक्षों को एक्सटेंशन का समर्थन करना होगा, और परिनियोजन को इसे सक्षम करना होगा। strongSwan में व्यवहार प्रति कनेक्शन कॉन्फ़िगर करने योग्य है, और इंटरफ़ेस या रूट बदलाव ज़रूरत पड़ने पर पथ खोज और अपडेट शुरू कर सकते हैं। हर IKEv2 प्रोफ़ाइल इसे चालू करता है यह मानने के बजाय कनेक्शन की वास्तविक सेटिंग्स देखें। इस सुविधा से पहले की गाइड से नकल की गई प्रोफ़ाइल इसका आम कारण है।

दोनों सिरों पर बातचीत की गई स्थिति ही अधिकार है, उत्पाद परिवार का दस्तावेज़ नहीं।

बदलाव को चरणों में देखें

नेटवर्क बदलने से पहले ऐप्लिकेशन की स्थिति दर्ज करें। फिर बदलें, और बाद में क्लाइंट और सर्वर की स्थिति दर्ज करें। गुम पता, अगम्य साथी और ऐसा ऐप्लिकेशन जिसे अपना सत्र खुद फिर से जोड़ना है—ये तीन अलग परिणाम हैं। केवल पहले दो VPN परत के हैं; तीसरा उस प्रोटोकॉल का है जो ऐप्लिकेशन बोलता है।

नेटवर्क स्विच की तुलना स्थिर परीक्षण से करें, ताकि आप जान सकें कि कौन सी घटना समस्या शुरू करती है। अंतिम नेटवर्क पर थ्रूपुट माप किसी बदलाव को दोहरा नहीं सकता। यह गंतव्य मापता है, यात्रा नहीं।

विफलता की परतें अलग करें

लंबे समय तक चलने वाला TCP सत्र IKEv2 विनिमय के बाहर के कारणों से विफल हो सकता है। नया नेटवर्क अलग तरह से फ़िल्टर, हल या रूट कर सकता है। सुरंग का पता बिल्कुल न बदले जबकि उसके नीचे का पथ बदल जाए। इसीलिए ऐप्लिकेशन का फिर से जुड़ना कुछ ऐसा ठीक कर सकता है जो VPN ने कभी नहीं तोड़ा।

सुधार के दौरान भी अवरोधक नीति को जगह पर रखें।

स्वचालित गतिशीलता और सीधे ट्रैफ़िक को रोकने वाला नियम दो अलग नियंत्रण हैं, और पहले के काम करने के लिए दूसरे को बंद करना खराब सौदा है। अगर गतिशीलता अपडेट विफल हो, तो अवरोध को टिके रहना चाहिए, सुरंग के आसपास ट्रैफ़िक रिसने देने के बजाय।

जब यह दोहराए तो क्या दर्ज करें

दोनों पक्षों से टाइमस्टैम्प और दोनों पता मान रखें। वह रिकॉर्ड दिखाता है कि अपडेट ऐप्लिकेशन के संपर्क खोने से पहले पूरा हुआ या नहीं, जो गतिशीलता बग और ऐप्लिकेशन टाइमआउट के बीच का अंतर है। फिर स्विच की दिशा की तुलना करें: Wi-Fi छोड़कर सेलुलर पर जाना उलटे के साथ सममित नहीं है। एक दिशा काम कर सकती है जबकि दूसरी विफल हो।

यह असममिति इतनी आम है कि इसे परखने वाली पहली चीज़ होनी चाहिए।

रिकॉर्ड हाथ में होने पर घटना एक और कटा हुआ आइकन होने से बच जाती है और ज्ञात स्वामी वाले क्रम में एक घटना बन जाती है। और किसी यात्रा के ईमानदारी से वादा करने लायक बस इतना ही है।