दुई IPsec गेटवे, साझा IP छैन: फेलओभरले वास्तवमा के गर्छ

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

दृश्य तयार पार्नुहोस्: दुई ठेगाना, कुनै फ्लोटिङ IP छैन

गेटवे A एउटा पहुँचयोग्य ठेगानामा जवाफ दिन्छ र गेटवे B अर्कोमा। A गएपछि B छनोट गर्ने स्वीकृत तरिका क्लाइन्टसँग छ, र दुवै गेटवेले दाबी गर्ने साझा बाह्य ठेगाना छैन। यो डिजाइनमा भर्चुअल IP भन्नाले त्यही साझा प्रवेश बिन्दु बुझिन्छ, रिमोट-पहुँच क्लाइन्टलाई दिइने आन्तरिक ठेगाना होइन।

यो परिभाषा महत्त्वपूर्ण छ किनभने दुई विचार टिकटमा मिसिन्छन्, र एउटाको सुधार अर्कोको सुधार होइन। साझा प्रवेश गेटवेको पछि लागेन भन्ने रिपोर्टले एउटा डिजाइन वर्णन गर्छ। ल्यापटपले आफ्नो आन्तरिक ठेगाना गुमायो भन्ने रिपोर्टले क्लाइन्टको भाडा वर्णन गर्छ। फरक मालिक, फरक लग, फरक मर्मत।

विफलताबाट जानुहोस्: पहिचान गर्नुहोस्, त्यसपछि फेरि छनोट गर्नुहोस्

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

त्यसपछि क्लाइन्टले तैनातीले समर्थन गर्ने कुनै पनि संयन्त्रबाट B छनोट गर्छ: दोस्रो कन्फिगर गरिएको रिमोट, स्वस्थ ठेगानामा समाधान गरिएको DNS नाम, वा अब फरक मार्ग रुचाउने राउटिङ। छनोट नीतिको कदम हो, र त्यो विफलताअघि हुनैपर्छ नत्र संयोगवश हुनेछ।

B ले के मिरासा पाउन सक्छ र के पाउँदैन

B ले A सँग कन्फिगरेसन टेम्प्लेट, प्रमाणपत्र प्राधिकरण र प्रमाणीकरण नीति साझा गर्न सक्छ। यसले सक्रिय सुरक्षा संघहरू मिरासा पाउन सक्दैन। सत्र कुञ्जी, सुरक्षा प्यारामिटर सूचकांक र क्रम अवस्था A र क्लाइन्टले स्थापना गरेको सम्बन्धको हो, र B सँग तीमध्ये एउटा पनि छैन।

यो अवस्था गेटवेबीच सार्नु वास्तविक इन्जिनियरिङ समस्या हो, त्यसैले strongSwan को उच्च उपलब्धता दस्तावेजले यसलाई कन्फिगरेसन झन्डा होइन, क्लस्टर डिजाइन मान्छ। कुनै विशेष क्लस्टर विधि क्लाउड सञ्जालका लागि सामान्य उत्तर होइन, र सहयोगी पूर्वाधारबिना त्यसको प्रतिलिपि गर्नु निरन्तरताको सट्टा जटिलता किन्नु हो।

नयाँ सम्बन्ध स्थापना गर्नु

B छनोट भएपछि क्लाइन्टले नयाँ IKE आदानप्रदान गर्छ: नयाँ nonce मान, नयाँ Diffie-Hellman मान, परिणामस्वरूप बन्ने संघहरूका लागि नयाँ पहिचानकर्ता। B मा फेरि प्रमाणीकरण हुन्छ। यदि डिजाइन मेसिन प्रमाणहरूमा निर्भर छ भने, पुनः जडान निगरानीबिना हुन सक्छ; यदि मानवीय तत्व चाहिन्छ भने, फेलओभर पूरा गर्न कसैको उपस्थिति आवश्यक हुन्छ।

त्यो प्रयोगकर्ता अनुभव अवरोधअघि परिभाषित गर्नुहोस्, अवरोधका बेला होइन। क्लाइन्टले के गर्ने, कति प्रयास गर्ने र हार मान्दा के देखाउने स्पष्ट भन्नुहोस्, किनभने एक मिनेटको पुनः जडान र सहयोग कलबीचको फरक सामान्यतया कागजात र परीक्षण गरिएको प्रोफाइल हो।

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

समानान्तरमा दुई टनेल फरक डिजाइन हो

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

ओभरल्यापिङ टनेल नीतिले आफैं व्यवस्थित फेलओभर बनाउँदैनन्। तिनले दुई उम्मेदवार बनाउँछन्, र तिनीहरूबीच केही कुराले निर्णायक रूपमा निर्णय गर्नुपर्छ, त्यो राउटिङ मेट्रिक, नीति प्राथमिकता वा क्लाइन्टमा स्पष्ट प्राथमिकता हुन सक्छ।

तपाईंले जुनसुकै स्वरूप छनोट गर्नुभए पनि सम्झौता लेख्नुहोस्: विफलता कसरी पहिचान गरिन्छ, विकल्प कसरी छनोट गरिन्छ, विकल्पलाई कुन प्रमाणीकरण चाहिन्छ र पुनः जडानमा कति समय लाग्ने अपेक्षा छ। साझा IP ले पत्ता लगाउन सजिलो बनाउन सक्छ, तर त्यो निरन्तर अवस्थाको पर्यायवाची होइन, र उपलब्धता जुनसुकै हालतमा एक डिजाइन हो।