दो IPsec गेटवे, कोई साझा IP नहीं: फ़ेलओवर असल में क्या करता है

मीटिंग के दौरान गेटवे A को बंद कर दें और एक मिनट बाद टनल को B से लौटते देखें; कनेक्शन काम करता है, वीडियो कॉल शायद नहीं। यह स्वतंत्र पतों वाले दो IPsec गेटवे के बीच कोल्ड फ़ेलओवर का सच्चा रूप है। क्लाइंट एक एंडपॉइंट फिर चुनता है और नया संबंध बनाता है, जिससे पुराने सत्र की क्रिप्टोग्राफ़िक स्थिति स्थानांतरित किए बिना पहुँच बहाल हो जाती है। क्रम पर चलने से साफ़ होता है कि डिज़ाइन कौन-से वादे निभा सकता है।

दृश्य तैयार करें: दो पते, कोई फ़्लोटिंग IP नहीं

गेटवे A एक पहुँचने योग्य पते पर जवाब देता है और गेटवे B दूसरे पर। क्लाइंट के पास A के जाने पर B चुनने का मंज़ूर तरीका है, और ऐसा कोई साझा बाहरी पता नहीं है जिस पर दोनों गेटवे दावा करें। इस डिज़ाइन में वर्चुअल IP का अर्थ वही साझा प्रवेश बिंदु है, रिमोट-एक्सेस क्लाइंट को दिया गया आंतरिक पता नहीं।

यह परिभाषा मायने रखती है क्योंकि दोनों विचार टिकटों में मिल जाते हैं, और एक का हल दूसरे का हल नहीं है। यह रिपोर्ट कि साझा प्रवेश गेटवे का पीछा नहीं कर पाया, एक डिज़ाइन बताती है। यह रिपोर्ट कि लैपटॉप ने अपना आंतरिक पता खो दिया, क्लाइंट की लीज़ बताती है। अलग मालिक, अलग लॉग, अलग मरम्मत।

विफलता पर चलें: पहचानें, फिर दोबारा चुनें

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

फिर क्लाइंट उस तंत्र से B चुनता है जो तैनाती समर्थित करती है: दूसरा कॉन्फ़िगर किया गया रिमोट, स्वस्थ पते पर हल होने वाला DNS नाम, या ऐसा रूटिंग जो अब दूसरा मार्ग पसंद करता है। चयन एक नीति कदम है, और उसे विफलता से पहले मौजूद होना चाहिए वरना वह संयोग से होगा।

B क्या विरासत में ले सकता है और क्या नहीं

B, A के साथ कॉन्फ़िगरेशन टेम्पलेट, प्रमाणपत्र प्राधिकरण और प्रमाणीकरण नीति साझा कर सकता है। वह जीवित सुरक्षा संबंधों को विरासत में नहीं ले सकता। सत्र कुंजियाँ, सुरक्षा पैरामीटर सूचकांक और अनुक्रम स्थिति उस संबंध की हैं जो A और क्लाइंट ने बनाया, और B के पास इनमें से कोई नहीं है।

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

नया संबंध स्थापित करना

B चुने जाने पर क्लाइंट नया IKE आदान-प्रदान करता है: नए nonce मान, नए Diffie-Hellman मान, बनने वाले संबंधों के लिए नए पहचानकर्ता। B पर फिर से प्रमाणीकरण होता है। अगर डिज़ाइन मशीन क्रेडेंशियल पर निर्भर है, तो पुनः कनेक्शन बिना निगरानी के हो सकता है; अगर उसे मानवीय कारक चाहिए, तो फ़ेलओवर पूरा करने के लिए किसी को मौजूद रहना होगा।

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

एक ही आंतरिक पता बनाए रखना उन एप्लिकेशन की मदद करता है जो स्थिर स्थानीय पहचान की अपेक्षा करते हैं, और यह उनके सत्र नहीं बचाता। NAT बाइंडिंग समाप्त होती हैं, TCP कनेक्शन रीसेट होते हैं और जिसका अपना टाइमआउट है वह स्वतंत्र रूप से तय करता है कि दोबारा कोशिश करनी है या नहीं।

समानांतर में दो टनल अलग डिज़ाइन हैं

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

अतिव्यापी टनल नीतियाँ अपने आप व्यवस्थित फ़ेलओवर नहीं बनातीं। वे दो उम्मीदवार बनाती हैं, और उनके बीच किसी को निर्णायक रूप से फ़ैसला करना होता है, चाहे वह रूटिंग मीट्रिक हो, नीति प्राथमिकता हो या क्लाइंट में स्पष्ट वरीयता।

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