दोन 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 शोध सोपा करू शकतो, पण तो सतत स्थितीचा समानार्थी नाही, आणि उपलब्धता कोणत्याही परिस्थितीत एक डिझाइन आहे।