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

एक खाता जो दो VPN नोड्स में से किसी में भी साइन इन कर सकता है, सॉफ़्टवेयर का प्रश्न बनने से बहुत पहले एक डिज़ाइन प्रश्न खड़ा करता है। खाते का दृश्य, हर नोड का अपना नेटवर्क और जुड़े क्लाइंट का सत्र तीन अलग तरह की स्थितियाँ हैं, और इन्हें एक जगह से दूसरी जगह कॉपी करने पर ये अलग-अलग तरीक़ों से विफल होती हैं। तीनों को एक ही सिस्टम में कॉपी करना उनमें से एक खोने का आम तरीक़ा है।

नीचे दी गई तीन बहियों को क्रम में देखें। हर एक पूछती है कि क्या सत्ताधारी है, क्या स्थानीय है, और दूसरा नोड न होने पर क्या होता है, और उत्तर एक-दूसरे से नहीं निकलते।

कौन जुड़ सकता है: एक सत्ता, कई नोड

प्रवेश बही से शुरू करें: कौन-सा पहचान स्रोत सत्ताधारी है, किन प्रमाणपत्र जारीकर्ताओं पर भरोसा है, कौन-से खाते पात्र हैं, कौन-सा दूसरा कारक लागू होता है, और हर खाता कहाँ तक पहुँच सकता है। फिर लिखें कि हर नोड बदलावों के बारे में कैसे जानता है, और कितनी तेज़ी से।

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

तय करें कि सत्ता तक न पहुँचने पर नोड क्या करता है। व्यवधान के दौरान कैश किए गए क्रेडेंशियल स्वीकार करना सुरक्षा लागत वाला नीति-निर्णय है, और उन्हें अस्वीकार करना उपलब्धता लागत वाला नीति-निर्णय है। दोनों ही उचित हैं; इसे बिना दस्तावेज़ छोड़ना नहीं।

जारीकर्ता की सत्ता को खाता डेटा से अलग रखें। कई गेटवे उसी CA पर भरोसा कर सकते हैं, उसकी हस्ताक्षर कुंजी रखे बिना, और हर नोड को अब भी अपना सर्वर प्रमाणपत्र और अपना क्लाइंट-पक्ष भरोसा संबंध चाहिए।

नोड क्या रखता है: पते और मार्ग

दूसरी बही हर नोड के लिए स्थानीय है: सुनने का पता, सर्वर पहचान, पता पूल, निजी संसाधनों के मार्ग, रिज़ॉल्वर नीति, और ट्रैफ़िक इंटरनेट की ओर कैसे निकलता है। वही खाता किसी भी नोड द्वारा सेवित हो सकता है जबकि ये वस्तुएँ अलग रहती हैं।

वापसी मार्ग वह हिस्सा है जो भुला दिया जाता है। अगर दोनों नोड एक ही पूल से पते देते हैं, तो निजी नेटवर्क यह नहीं बता सकता कि दिया गया क्लाइंट किस नोड का है, और उत्तर ग़लत जगह भेजा जा सकता है। अलग पूल को भी मार्ग और अनुमतियाँ चाहिए, इसलिए अलग संख्या श्रेणी पूरा डिज़ाइन नहीं है।

क्लाइंट को जानबूझकर एक नोड पर भेजें। DNS चयन, क्लाइंट एंडपॉइंट सूचियाँ और फ़्रंट-एंड सेवा अलग-अलग तंत्र हैं जिनका स्वास्थ्य और विफलता-स्विचिंग व्यवहार अलग है। एक चुनना ठीक है; “लोड बैलेंसिंग” को डिज़ाइन मानना वापसी मार्ग और विफलता व्यवहार को अपरिभाषित छोड़ देता है।

प्रलेखित उत्पाद उदाहरण यहाँ मदद करता है। Pritunl का प्रतिकृति दस्तावेज़ VPN नेटवर्क को प्रति-प्रतिकृति वस्तु मानता है, और अलग प्रतिकृतियों के क्लाइंट को एक-दूसरे तक पहुँचने के लिए अतिरिक्त मार्ग और कनेक्टिविटी चाहिए। यह उत्पाद-विशिष्ट व्यवस्था है, Community OpenVPN के लिए नुस्ख़ा नहीं, लेकिन यह दिखाती है कि प्रतिकृति जोड़ने से केवल खाता भंडार नहीं, नेटवर्क भी बदलता है।

सत्र क्या है: जीवंत स्थिति, पंक्ति नहीं

तीसरी बही जीवंत सत्र है। जुड़े क्लाइंट के पास जिस नोड ने उसे स्वीकार किया उस पर प्रोटोकॉल स्थिति और नेटवर्क आवंटन होता है। खाता दूसरे नोड पर ज्ञात होना उस नोड को सत्र, कुंजियाँ या पैकेट जारी रखने की क्षमता नहीं देता।

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

क्षमता नियमों को भी वही व्यवहार चाहिए। प्रति खाता दो समवर्ती सत्रों की सीमा नोड्स के बीच तभी लागू हो सकती है जब किसी सत्ता के पास भरे हुए स्लॉट का समन्वित दृश्य हो। नोड-स्थानीय सूचियाँ और ऐतिहासिक खाता रिकॉर्ड उस दृश्य तक नहीं जुड़ते।

तीनों बहियों की जाँच

हर एक को अलग-अलग जाँचें। नोड A से साइन इन करें, फिर नोड B से, और पुष्टि करें कि दोनों अपेक्षित पता श्रेणियों के साथ सफल होते हैं। एक पहचान वापस लें और दोनों नोड जाँचें, केवल वह नहीं जिसे संयोग से परखा। फिर एक नोड रोकें और देखें कि क्लाइंट और निजी एप्लिकेशन वास्तव में क्या करते हैं।

स्वीकृति परीक्षण में वापसी मार्ग शामिल करें। जो क्लाइंट B से जुड़ता है पर A के पीछे के संसाधन से उत्तर नहीं पा सकता, उसने प्रवेश जाँच पास की और नेटवर्क की विफल की, और यह भेद रिपोर्ट में आना चाहिए।

मल्टी-नोड खाता डिज़ाइन तभी पूरा है जब तीनों बहियों का स्पष्ट स्वामी, बदलाव का मार्ग और विफलता व्यवहार हो। नोड्स के बीच कॉन्फ़िगरेशन फ़ाइल कॉपी करना इनमें से किसी प्रश्न का उत्तर नहीं देता।