दोन सक्रिय IPsec बोगद्यांना अजूनही परतीच्या मार्गाची योजना हवी आहे
दोन बोगदे ही योजना नाहीत. एक TCP संभाषण एका गेटवे जोडीतून बाहेर आणि दुसऱ्यातून परत जाताना पाहा, मग स्थिती कोण ठेवतो ते ठरवा.
एका साइटवरील वर्कस्टेशनवर टर्मिनल उघडा आणि दुसऱ्या साइटवरील सर्व्हरशी जोडा। त्या एकाच TCP संभाषणाला आता दोनऐवजी चार गेटवे ओलांडावे लागतात, आणि मनोरंजक गोष्ट ही नाही की ते चांगल्या दिवशी चालते का। मनोरंजक गोष्ट ही आहे की पुढच्या दिशेने कोणती गेटवे जोडी निवडली, उत्तर कोणती जोडी निवडते, आणि ते होत असताना प्रवाहाची स्थिती कोण ठेवतो। राउटिंग तक्त्यातील काहीही हे तुमच्यासाठी ठरवत नाही।
मार्ग काढण्यापूर्वी चार गेटवे काढा
प्रत्येक साइटवर दोन स्वतंत्र VPN फायरवॉल असलेली दुहेरी-सक्रिय रचना, प्रत्येक प्रदात्यासाठी एक जोडी, तुम्हाला दोन वापरण्यायोग्य मार्ग आणि ते तोडण्याचे तीन मार्ग देते। काहीही कॉन्फिगर करण्यापूर्वी पत्ते लिहा: प्रत्येक गेटवेच्या आधी आणि नंतर दिसणारा क्लायंट, सर्व्हरही तसाच, पुढचा पुढील हॉप आणि परतीचा पुढील हॉप।
तेच तक्ते ही रचना आहे। त्यानंतरचे सर्व काही हा प्रश्न आहे की उपकरणे तक्त्याशी सहमत आहेत का।
पुढचा मार्ग कसा निवडला जातो
समान खर्चाचा बहुमार्ग राउटिंग स्तर हेडर फील्ड हॅश करून प्रवाह पुढील हॉपवर वाटतो, ज्याचे RFC 2992 सविस्तर वर्णन करते। ती निवड पूर्णपणे स्थिती-रहित असू शकते: तिला कनेक्शन-ट्रॅकिंग नोंदीची गरज नाही, केवळ अपरिवर्तित फील्डवर स्थिर हॅश पुरेसा आहे। मार्ग संच आणि हॅश इनपुट स्थिर ठेवा, आणि प्रवाहातील प्रत्येक पॅकेट तोच पुढील हॉप निवडेल।
प्रति-प्रवाह निवड वेगवेगळ्या विलंबाच्या दुव्यांवर पॅकेट-दर-पॅकेट समतोलामुळे होणारे पुनर्रचना टाळते। समान राउटिंग खर्च म्हणजे समान मोजलेला विलंब असे ते वचन देत नाही, कारण तसे नाही। आणि मार्गांची रचना बदलल्यास प्रवाह पुन्हा मॅप होतात, म्हणून अपयशाच्या वेळी कनेक्शन टिकून राहणे ही मार्ग-निवडीपेक्षा वेगळी आवश्यकता आहे।
परतीच्या मार्गाला खरोखर काय हवे आहे
येथे फेरी सममितीय राहत नाही। स्थिर पुढचा हॅश दूरची साइट उत्तराचे काय करेल याबद्दल तुम्हाला काहीच सांगत नाही। स्वतंत्र फायरवॉलला उपयुक्त स्थिती राखण्यासाठी कनेक्शनच्या दोन्ही दिशा पाहाव्या लागत असतील, तर त्याला बगल देणारा परतीचा मार्ग कोणाशीही जुळणारा रहदारी सोडतो। सारखे नियम संच असलेले दोन खोके सामायिक स्थिती नाहीत।
अंमलात आणलेल्या द्विदिश वर्तनाची पुष्टी करा, किंवा आवश्यक सीमा सुसंगत ठेवणारे स्पष्ट धोरण लिहा। येथील अंदाज खंडाच्या वेळी उघड होतो, ज्यांना त्याचा आनंद होत नाही अशा लोकांकडून।
जिथे अनुवाद तुमच्या वतीने ठरवतो
NAT हा दुसरा लीव्हर आहे, आणि तो अनिवार्य नसून ऐच्छिक आहे। मार्ग-विशिष्ट अनुवादित ओळखी उत्तरे स्थिती ठेवणाऱ्या गेटवेकडे परत वळवू शकतात, ही वैध रचना आहे। त्या मॅपिंग, परतीचे मार्ग आणि त्या स्थितीचा मालकही जोडतात, म्हणून ओढ मोठ्याने सांगू शकता अशा आवश्यकतेसाठीच स्वीकारा।
आवश्यकता फक्त एवढी असेल की दोन्ही मार्ग रहदारी वाहून नेतील आणि यापैकी कोणताही प्रदात्याच्या हानीतून टिकेल, तर सुसंगत परतीच्या राउटिंगसह साधा प्रति-प्रवाह बहुमार्ग सामान्यतः लहान रचना असतो।
स्वीकृती क्रमाने पार पाडा
या क्रमाने चाचणी करा आणि प्रत्येक टप्प्यावर पत्ते नोंदवा: मार्ग A वर नवीन कनेक्शन आणि त्याचा उत्तर मार्ग, मार्ग B वर तेच, मग एका प्रदात्याची हानी, मग पुनर्संचयित। प्रत्येक निकालासाठी कोणते प्रस्थापित प्रवाह हलले, कोणाला पुन्हा जोडावे लागले आणि नवीन प्रवाह नंतर कुठे गेले ते नोंदवा। आधी अपेक्षित मूल्य लिहा, मग त्याची कॅप्चरशी तुलना करा। दोन प्रस्थापित बोगदे यातील काहीही सिद्ध करत नाहीत।
तुम्ही लिहिलेले तक्ते कॅप्चर दाखवते त्याशी जुळल्यावर रचना पूर्ण होते, दोन्ही बोगदे वर असताना नाही।