दोन सर्व्हरवर एक VPN खाते: तीन स्थिती वह्या

दोन VPN नोडपैकी कोणत्याही नोडवर साइन इन करू शकणारे एक खाते, सॉफ्टवेअरचा प्रश्न होण्याच्या खूप आधी डिझाइनचा प्रश्न उपस्थित करते। खात्याचे दृश्य, प्रत्येक नोडचे स्वतःचे नेटवर्क आणि जोडलेल्या क्लायंटचे सत्र या तीन वेगळ्या प्रकारच्या स्थिती आहेत, आणि त्या एका ठिकाणाहून दुसऱ्या ठिकाणी कॉपी केल्यावर वेगवेगळ्या प्रकारे अपयशी होतात। तिन्ही एकाच प्रणालीत कॉपी करणे म्हणजे त्यातील एक गमावण्याचा नेहमीचा मार्ग।

खालील तीन वह्या क्रमाने पहा। प्रत्येक विचारते की काय अधिकृत आहे, काय स्थानिक आहे आणि दुसरा नोड नसताना काय होते, आणि उत्तरे एकमेकांतून येत नाहीत।

कोण जोडू शकतो: एक अधिकार, अनेक नोड

प्रवेश वहीपासून सुरुवात करा: कोणता ओळखीचा स्रोत अधिकृत आहे, कोणत्या प्रमाणपत्र जारीकर्त्यांवर विश्वास आहे, कोणती खाती पात्र आहेत, कोणता दुसरा घटक लागू होतो आणि प्रत्येक खाते कुठपर्यंत पोहोचू शकते। नंतर प्रत्येक नोड बदल कसा आणि किती लवकर जाणून घेतो ते लिहा।

सामायिक डेटाबेस हा त्या उत्तराचा एक संभाव्य घटक आहे। प्रत्येक संबंधित धोरण तिथेच राहते किंवा प्रत्येक नोड एकाच क्षणी बदल लागू करतो याचा तो पुरावा नाही। नोड A वर निष्क्रिय पण नोड B वर अजूनही स्वीकारले जाणारे खाते म्हणजे ऑफबोर्डिंग प्रक्रिया पूर्ण झाली नाही।

अधिकार उपलब्ध नसताना नोड काय करेल ते ठरवा। व्यत्ययाच्या वेळी कॅशे केलेली ओळखपत्रे स्वीकारणे ही सुरक्षा खर्च असलेली धोरण निवड आहे, आणि ती नाकारणे ही उपलब्धता खर्च असलेली धोरण निवड आहे। दोन्ही समर्थनीय आहेत; दस्तऐवज न करता सोडणे नाही।

जारीकर्त्याचा अधिकार खाते डेटापासून वेगळा ठेवा। अनेक गेटवे त्याच्या स्वाक्षरी किल्लीशिवाय एकाच CA वर विश्वास ठेवू शकतात, आणि प्रत्येक नोडला अजूनही स्वतःचे सर्व्हर प्रमाणपत्र आणि स्वतःचा क्लायंट-बाजूचा विश्वास संबंध आवश्यक आहे।

नोड काय ठेवतो: पत्ते आणि मार्ग

दुसरी वही प्रत्येक नोडसाठी स्थानिक आहे: ऐकण्याचा पत्ता, सर्व्हर ओळख, पत्ता पूल, खाजगी संसाधनांकडे मार्ग, रिझॉल्व्हर धोरण आणि रहदारी इंटरनेटकडे कशी जाते। तेच खाते कोणताही नोड सेवा देऊ शकतो, तर या वस्तू वेगळ्या राहतात।

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

क्लायंटना जाणीवपूर्वक एका नोडकडे पाठवा। DNS निवड, क्लायंट एंडपॉइंट याद्या आणि फ्रंट-एंड सेवा या वेगवेगळ्या यंत्रणा आहेत ज्यांचे आरोग्य आणि अपयश-स्विचिंग वर्तन वेगळे आहे। एक निवडणे ठीक आहे; “लोड बॅलन्सिंग” हे डिझाइन मानणे परतीचा मार्ग आणि अपयशाचे वर्तन अनिश्चित ठेवते।

दस्तऐवजीकृत उत्पाद उदाहरण येथे मदत करते। Pritunl चे प्रतिकृती दस्तऐवज VPN नेटवर्कला प्रति-प्रत म्हणून वस्तू मानते, आणि वेगळ्या प्रतींवरील क्लायंटना एकमेकांपर्यंत पोहोचण्यासाठी अतिरिक्त मार्ग आणि कनेक्टिव्हिटी लागते। ही उत्पाद-विशिष्ट व्यवस्था आहे, Community OpenVPN साठी कृती नाही, पण प्रत जोडल्याने केवळ खाते साठा नाही तर नेटवर्कही बदलते हे दाखवते।

सत्र काय आहे: जिवंत स्थिती, ओळ नाही

तिसरी वही जिवंत सत्र आहे। जोडलेल्या क्लायंटकडे ज्या नोडने तो स्वीकारला त्या नोडवर प्रोटोकॉल स्थिती आणि नेटवर्क वाटप असते। खाते दुसऱ्या नोडवर माहीत असणे त्या नोडला सत्र, किल्ल्या किंवा पॅकेट पुढे चालू ठेवण्याची क्षमता देत नाही।

नोड अपयशी झाल्यावर काय होते ते स्पष्ट सांगा। समर्थित परिणाम म्हणजे नवीन प्रमाणीकरण आणि नव्या पत्त्यासह दुसऱ्या नोडवर पुन्हा जोडणे असू शकते, त्यानंतर अनुप्रयोग स्वतःच्या पद्धतीने सावरतो। जर अखंड हस्तांतरण आवश्यक असेल, तर त्या गरजेला स्पष्ट अंमलबजावणी समर्थन लागते, डेटाबेस प्रतिकृतीतून काढलेला अंदाज नाही। उत्तर तिथे लिहा जिथे ऑन-कॉल अभियंत्याला ते सापडेल।

क्षमता नियमांनाही तोच दृष्टिकोन लागतो। खात्यामागे दोन एकाचवेळी सत्रांची मर्यादा नोड्समध्ये लागू करता येते फक्त तेव्हाच जेव्हा कोणत्या तरी अधिकाराकडे व्यापलेल्या जागांचे समन्वित दृश्य असेल। नोड-स्थानिक याद्या आणि ऐतिहासिक खाते नोंद त्या दृश्यात मिळून येत नाहीत।

तीन वह्यांची चाचणी

प्रत्येकाची वेगळी चाचणी करा। नोड A द्वारे साइन इन करा, नंतर नोड B द्वारे, आणि अपेक्षित पत्ता श्रेणींसह दोन्ही यशस्वी होतात याची खात्री करा। एक ओळख मागे घ्या आणि दोन्ही नोड तपासा, केवळ योगायोगाने तपासलेला नाही। नंतर एक नोड थांबवा आणि क्लायंट व खाजगी अनुप्रयोग प्रत्यक्षात काय करतात ते पहा।

स्वीकृती चाचणीत परतीचा मार्ग समाविष्ट करा। जो क्लायंट B ला जोडतो पण A मागील संसाधनाकडून उत्तरे मिळवू शकत नाही, त्याने प्रवेश तपासणी उत्तीर्ण केली आणि नेटवर्कची अपयशी झाली, आणि तो फरक अहवालात दिसला पाहिजे।

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