दुई सर्भरमा एउटै VPN खाता: तीन स्थिति बही

दुई VPN नोडमध्ये जुनसुकैमा साइन इन गर्न सक्ने एउटा खाताले सफ्टवेयरको प्रश्न बन्नु धेरै अघि नै डिजाइनको प्रश्न उठाउँछ। खाताको दृश्य, प्रत्येक नोडको आफ्नै नेटवर्क र जोडिएको क्लाइन्टले राख्ने सत्र तीन फरक प्रकारका स्थिति हुन्, र तिनलाई एक ठाउँबाट अर्को ठाउँमा प्रतिलिपि गर्दा तिनी फरक तरिकाले असफल हुन्छन्। तीनैलाई एउटै प्रणालीमा प्रतिलिपि गर्नु तिनमध्ये एउटा गुमाउने सामान्य तरिका हो।

तलका तीन बही क्रममा हेर्नुहोस्। प्रत्येकले के अधिकारिक छ, के स्थानीय छ र अर्को नोड नहुँदा के हुन्छ भनी सोध्छ, र उत्तरहरू एकअर्काबाट आउँदैनन्।

कसले जोडिन सक्छ: एक अधिकार, धेरै नोड

प्रवेश बहीबाट सुरु गर्नुहोस्: कुन पहिचान स्रोत अधिकारिक छ, कुन प्रमाणपत्र जारीकर्तामा विश्वास छ, कुन खाता योग्य छन्, कुन दोस्रो कारक लागू हुन्छ र प्रत्येक खाता कहाँसम्म पुग्न सक्छ। त्यसपछि प्रत्येक नोडले परिवर्तनबारे कसरी र कति छिटो थाहा पाउँछ लेख्नुहोस्।

साझा डाटाबेस त्यो उत्तरको एउटा सम्भाव्य घटक हो। यो प्रमाण होइन कि प्रत्येक सम्बन्धित नीति त्यहीँ बस्छ वा प्रत्येक नोडले एउटै क्षणमा परिवर्तन लागू गर्छ। नोड A मा निष्क्रिय तर नोड B मा अझै स्वीकार गरिएको खाता भन्नुको अर्थ अफबोर्डिङ प्रक्रिया सकिएको छैन।

अधिकार पुग्न नसकेपछि नोडले के गर्ने निर्णय गर्नुहोस्। अवरोधका बेला क्यास गरिएका प्रमाणहरू स्वीकार गर्नु सुरक्षा लागत भएको नीति निर्णय हो, र तिनलाई अस्वीकार गर्नु उपलब्धता लागत भएको नीति निर्णय हो। दुवै तर्कसंगत छन्; कागजात नगरी छोड्नु होइन।

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

नोडसँग के छ: ठेगाना र मार्ग

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

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

क्लाइन्टहरूलाई जानाजानी एउटा नोडतर्फ पठाउनुहोस्। DNS छनोट, क्लाइन्ट एन्डपोइन्ट सूची र फ्रन्ट-एन्ड सेवा फरक स्वास्थ्य र असफलता-स्विचिङ व्यवहार भएका फरक संयन्त्र हुन्। एउटा छान्नु ठीक छ; “लोड ब्यालेन्सिङ” लाई डिजाइन मान्नुले फर्कने बाटो र असफलताको व्यवहारलाई अनिश्चित छोड्छ।

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

सत्र के हो: जीवित स्थिति, पंक्ति होइन

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

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

क्षमता नियमलाई पनि त्यही व्यवहार चाहिन्छ। खातामा दुई एकैसाथ सत्रको सीमा नोडहरूबीच लागू गर्न सकिन्छ मात्र यदि कुनै अधिकारसँग ओगटिएका स्थानहरूको समन्वित दृष्टि छ भने। नोड-स्थानीय सूची र ऐतिहासिक खाता अभिलेख त्यो दृष्टि बन्न जोडिँदैनन्।

तीन बहीको परीक्षण

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

स्वीकृति परीक्षणमा फर्कने बाटो समावेश गर्नुहोस्। जो क्लाइन्ट B मा जोडिन्छ तर A पछाडिको स्रोतबाट उत्तर पाउन सक्दैन, उसले प्रवेश जाँच उत्तीर्ण गर्‍यो र नेटवर्कको असफल भयो, र त्यो भिन्नता प्रतिवेदनमा देखिनुपर्छ।

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