दुई सक्रिय IPsec सुरुङहरूलाई अझै फर्कने मार्गको योजना चाहिन्छ

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

मार्ग कोर्नु अघि चार गेटवे कोर्नुहोस्

प्रत्येक साइटमा दुई स्वतन्त्र VPN फायरवाल भएको दोहोरो-सक्रिय डिजाइन, प्रत्येक प्रदायकका लागि एक जोडी, तपाईंलाई दुई प्रयोगयोग्य मार्ग र तिनीहरूलाई तोड्ने तीन तरिका दिन्छ। केही कन्फिगर गर्नु अघि ठेगानाहरू लेख्नुहोस्: प्रत्येक गेटवे अघि र पछि देखिने क्लाइन्ट, सर्भर पनि त्यस्तै, अगाडिको अर्को हप र फर्कने अर्को हप।

त्यही तालिका डिजाइन हो। त्यसपछिको सबै कुरा उपकरणहरू तालिकासँग सहमत छन् कि छैनन् भन्ने प्रश्न हो।

अगाडिको मार्ग कसरी छानिन्छ

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

प्रति-प्रवाह छनोटले फरक ढिलाइ भएका लिङ्कहरूमा प्याकेट-दर-प्याकेट सन्तुलनले निम्त्याउने पुनःक्रमबाट बच्छ। समान राउटिङ लागत भनेको समान मापिएको ढिलाइ हो भनी यसले वाचा गर्दैन, किनकि त्यस्तो हुँदैन। र मार्गहरूको संरचना बदलिएमा प्रवाहहरू पुनः म्याप हुन्छन्, त्यसैले विफलताका क्रममा कनेक्शन टिकिरहनु मार्ग-छनोटभन्दा छुट्टै आवश्यकता हो।

फर्कने मार्गलाई साँच्चै के चाहिन्छ

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

कार्यान्वित द्विदिश व्यवहार पुष्टि गर्नुहोस्, वा आवश्यक सीमाहरू सुसंगत राख्ने स्पष्ट नीति लेख्नुहोस्। यहाँको अनुमान अवरोधका क्रममा, यसबाट रमाइरहेका नभएका मानिसहरूबाट पत्ता लाग्छ।

जहाँ अनुवाद तपाईंका तर्फबाट निर्णय गर्छ

NAT अर्को लिभर हो, र यो अनिवार्य नभई वैकल्पिक छ। मार्ग-विशिष्ट अनुवादित पहिचानहरूले जवाफहरूलाई स्थिति राख्ने गेटवेतर्फ फर्काउन सक्छन्, जो वैध डिजाइन हो। तिनीहरूले म्यापिङ, फर्कने मार्ग र त्यो स्थितिको मालिक पनि थप्छन्, त्यसैले भार ठूलो स्वरमा भन्न सकिने आवश्यकताका लागि मात्र स्वीकार्नुहोस्।

यदि आवश्यकता केवल दुई मार्गले ट्राफिक बोक्ने र जुनसुकै एउटाले प्रदायकको हानिबाट बाँच्ने हो भने, सुसंगत फर्कने राउटिङसहितको साधारण प्रति-प्रवाह बहुमार्ग सामान्यतया सानो डिजाइन हो।

स्वीकृति क्रमैले पार गर्नुहोस्

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

तपाईंले लेखेको तालिका क्याप्चरले देखाएको कुरासँग मिल्दा डिजाइन पूरा हुन्छ, दुवै सुरुङ चालु हुँदा होइन।