VPN फ़ेलओवर: जब वापसी का रास्ता पुराने टनल पर ही रहे

बैकअप टनल ऊपर आता है, प्राथमिक टनल नीचे जाता है, और ऐप फिर भी समय-सीमा पार कर जाता है। दोनों साइटों पर टनल की स्थिति स्वस्थ दिखती है, और यही उलझन पैदा करता है। जो फ़ेलओवर अनुरोध बैकअप पर भेजता है पर जवाब पुराने रास्ते पर छोड़ देता है, वह फ़ेलओवर नहीं है। नीचे की मार्गदर्शिका सिर्फ़ हैंडशेक नहीं, वापसी का रास्ता भी जाँचती है।

पहले दोनों सिरों पर रूट दर्ज करें; एक ही साइट का दृश्य असममित रास्ता नहीं दिखा सकता। समय के दबाव में सबसे ज़्यादा छोड़ा जाने वाला कदम भी यही है।

जाँच से पहले दोनों साइटों के रूट दर्ज करें

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

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

यह दोनों साइटों पर करें। एक तरफ़ पसंद किया जाने वाला और दूसरी तरफ़ अनदेखा किया जाने वाला बैकअप ठीक वही असममिति पैदा करता है जिससे आप बचना चाहते हैं।

हर चरण में अनुरोध और जवाब देखें

एक हानिरहित अनुमत ऐप इस्तेमाल करें और तीन चरण देखें: सामान्य, प्राथमिक विफलता और बहाली। हर चरण में दर्ज करें कि कौन-सा टनल अनुरोध ले जाता है और कौन-सा जवाब। पहुँचने योग्य पीयर पता यह साबित नहीं करता कि सुरक्षित ऐप रास्ता काम करता है। एकतरफ़ा प्रवाह दिखे इसके लिए दोनों साइटों पर दर्ज करें।

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

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

गेटवे बदलने पर सत्र स्थिति संभालें

फ़ायरवॉल और NAT एक गेटवे पर कनेक्शन स्थिति रख सकते हैं, और दूसरे गेटवे पर रास्ता बदलने पर वह साथ नहीं जाती। कुछ ऐप खुद दोबारा जुड़ते हैं; दूसरे सत्र बहाल होने तक विफल रहते हैं। अगर बैकअप सार्वजनिक स्रोत या अनूदित निजी पता बदलता है, तो दूरस्थ पहुँच नियम भी प्रतिक्रिया दे सकते हैं। किसी भी अपेक्षित सत्र पुनःआरंभ को दर्ज करें, बजाय निर्बाध फ़ेलओवर का वादा करने के।

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

सिर्फ़ नया अनुरोध नहीं, लंबा सत्र रखने वाला ऐप भी जाँचें।

प्राथमिक बहाल करें और फ़्लैपिंग जाँचें

पुष्टि करें कि रूट घोषणाएँ या प्राथमिकताएँ बिना दोलन के स्थिर होती हैं। फ़्लैपिंग प्राथमिक स्पष्ट रुकावट से अधिक परेशान कर सकता है, क्योंकि हर बदलाव स्थिति रीसेट करता है।

गेटवे प्रशासन को रिकवरी रास्ते से पहुँच योग्य रखें ताकि जाँच खुद आपको बाहर न कर दे। चरण, देखे गए रास्ते और रिकवरी समय दर्ज करें; वही रिकॉर्ड अगले फ़ेलओवर को अनुमानित बनाता है। strongSwan की फ़ॉरवर्डिंग टिप्पणियाँ उपयोगी हैं जब एंडपॉइंट Linux होस्ट हों।