VPN फेलओभर: जब फर्किने बाटो पुरानै टनेलमा रहन्छ

ब्याकअप टनेल माथि आउँछ, प्राथमिक टनेल तल जान्छ, र अनुप्रयोग अझै समयसीमा नाघ्छ। दुवै साइटमा टनेलको अवस्था स्वस्थ देखिन्छ, र यसैले अन्योल उत्पन्न गर्छ। जुन फेलओभरले अनुरोधहरू ब्याकअपमा सार्छ तर जवाफहरू पुरानो बाटोमा छोड्छ, त्यो फेलओभर होइन। तलको मार्गदर्शनले ह्यान्डशेक मात्र नभई फर्किने बाटो पनि परीक्षण गर्छ।

पहिले दुवै छेउका रुटहरू अभिलेख गर्नुहोस्; एउटै साइटको दृश्यले असममित बाटो देखाउन सक्दैन। समयको दबाबमा सबैभन्दा धेरै छोडिने चरण पनि यही हो।

परीक्षण अघि दुवै साइटका रुटहरू अभिलेख गर्नुहोस्

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

स्थिर मेट्रिक, ट्र्याक गरिएका रुट र गतिशील राउटिङले योग्यता फरक तरिकाले व्यक्त गर्छन्। तपाईंको डिजाइनले कुन प्रयोग गर्छ र विकल्प सक्रिय हुन के चाहिन्छ जान्नुहोस्। रुटको छेउमा सर्त लेख्नुहोस्, जस्तै परीक्षण असफल नहुँदासम्म कम मेट्रिक।

यो दुवै साइटमा गर्नुहोस्। एकातिर प्राथमिकता पाउने र अर्कोतिर उपेक्षित हुने ब्याकअपले ठ्याक्कै त्यही असममिति उत्पन्न गर्छ जुन तपाईं बच्न खोज्नुहुन्छ।

हरेक चरणमा अनुरोध र जवाफ हेर्नुहोस्

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

यदि अनुरोध सर्छ तर जवाफ सर्दैन भने, टाढाको साइटको क्लाइन्ट प्रिफिक्ससम्मको रुट र ब्याकअपप्रति त्यसको प्राथमिकता जाँच्नुहोस्। यो राउटिङ निर्णय हो, टनेल असफलता होइन।

परीक्षणपछि मूल अवस्था पुनर्स्थापित गर्नुहोस् र प्राथमिक फेरि प्राथमिकता पाउँछ भन्ने पुष्टि गर्नुहोस्। पुनर्स्थापित प्राथमिकले प्राथमिकता नपाए त्यो अपूर्ण फेलओभर डिजाइन हो।

गेटवे बदलिँदा सत्र अवस्था व्यवस्थापन गर्नुहोस्

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

अनुप्रयोगले माग्ने ठाउँमा स्थिर ठेगाना राख्नुहोस्। प्रत्येक सत्रका लागि स्रोत ठेगाना बदल्ने फेलओभर डिजाइन एक डिजाइन छनोट हो, र त्यो लेखिनुपर्छ। त्यही छनोटले प्रयोगकर्ताले अवरोध कति महसुस गर्छन् भन्ने निर्धारण गर्छ।

केवल नयाँ अनुरोध नभई लामो सत्र राख्ने अनुप्रयोग पनि परीक्षण गर्नुहोस्।

प्राथमिक पुनर्स्थापित गर्नुहोस् र फ्ल्यापिङ जाँच्नुहोस्

रुट घोषणा वा प्राथमिकता दोलन बिना स्थिर हुन्छन् भन्ने पुष्टि गर्नुहोस्। फ्ल्यापिङ प्राथमिक स्पष्ट अवरोधभन्दा बढी उपद्रवी हुन सक्छ, किनकि हरेक संक्रमणले अवस्था रिसेट गर्छ।

गेटवे प्रशासन पुनःप्राप्ति बाटोबाट पुग्न सकिने राख्नुहोस्, ताकि परीक्षणले आफै तपाईंलाई बाहिर नराखोस्। चरणहरू, अवलोकन गरिएका बाटाहरू र पुनःप्राप्ति समय अभिलेख गर्नुहोस्; त्यही अभिलेखले अर्को फेलओभरलाई अनुमानयोग्य बनाउँछ। strongSwan का फर्वार्डिङसम्बन्धी टिप्पणीहरू इन्डपोइन्टहरू Linux होस्ट हुँदा उपयोगी हुन्छन्।