दो सक्रिय IPsec सुरंगों को अभी भी वापसी मार्ग की योजना चाहिए

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

मार्ग खींचने से पहले चार गेटवे खींचें

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

वही तालिका डिज़ाइन है। उसके बाद सब कुछ यह प्रश्न है कि क्या उपकरण तालिका से सहमत हैं।

आगे का मार्ग कैसे चुना जाता है

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

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

वापसी मार्ग को वास्तव में क्या चाहिए

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

लागू किए गए द्विदिश व्यवहार की पुष्टि करें, या ऐसी स्पष्ट नीति लिखें जो आवश्यक सीमाओं को सुसंगत रखे। यहाँ का अनुमान किसी रुकावट के दौरान पकड़ा जाता है, ऐसे लोगों द्वारा जिन्हें इसमें आनंद नहीं आ रहा।

जहाँ अनुवाद आपके लिए तय करता है

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

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

स्वीकृति क्रम से पूरी करें

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

डिज़ाइन तब पूरा होता है जब आपकी लिखी तालिका कैप्चर में दिखने वाली बात से मेल खाती है, तब नहीं जब दोनों सुरंगें चालू हों।