साझेदारों को जोड़े बिना भागीदार VPN पहुँच को केंद्रीकृत करें

प्रस्ताव उचित है: एक दर्जन लैपटॉप पर फैले पाँच साझेदार टनल, पाँच क्लाइंट संस्करण सेट, पाँच हेल्प डेस्क स्क्रिप्ट, और एक इंजीनियर जो जानता है कि ये सब कैसे जुड़ते हैं. इन्हें नियंत्रित पहुँच स्तर पर ले जाने से एंडपॉइंट का फैलाव ठीक होता है. यह आपकी आर्किटेक्चर में एक नई वस्तु भी बनाता है, एक साझा पहुँच सेवा जिसे अब अपना प्राधिकरण मॉडल चाहिए, और जिस विफलता को सब कम आँकते हैं वह है एक केंद्रीय उपकरण जिसमें सभी टनल सक्षम हैं और जो चुपचाप उन संगठनों के बीच पारगमन नेटवर्क बन जाता है जिन्होंने कभी पड़ोसी होने पर सहमति नहीं दी. वह जोखिम एक डिज़ाइन निर्णय है, ऐसा कुछ नहीं जो हार्डवेयर अपने आप करता हो. नीचे का काम यह है कि मैं आकस्मिक दुष्प्रभाव स्वीकार किए बिना सुविधा कैसे बनाए रखता हूँ.

उस अनुबंध से शुरू करें जिस पर हर साझेदार पहले ही हस्ताक्षर कर चुका है

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

वही रिकॉर्ड परिणाम है. यदि आप एक साझेदार के लिए इसे नहीं लिख सकते, तो वह साझेदार केंद्रीकरण के लिए तैयार नहीं है.

केवल गंतव्य से नहीं, संदर्भ से रूट करें

दो साझेदार अंततः एक ही निजी श्रेणी का उपयोग करेंगे, क्योंकि हर संगठन एक ही RFC 1918 स्थान से चुनता है. एक साधारण रूटिंग तालिका केवल गंतव्य पते से सही साझेदार नहीं चुन सकती, इसलिए अतिव्यापी श्रेणियों को अलग रूटिंग संदर्भ या दूसरा सहमत डिज़ाइन चाहिए. RFC 4364 में फ़ॉरवर्डिंग-डोमेन मॉडल बताता है कि यह अलगाव क्यों मायने रखता है, और परिनियोजन को अपने गेटवे प्लेटफ़ॉर्म से वही गुण माँगने के लिए MPLS चलाने की ज़रूरत नहीं है.

प्लेटफ़ॉर्म से सीधा प्रश्न पूछें: क्या दो साझेदार एक ही गंतव्य उपसर्ग साझा कर सकते हैं और फिर भी इस बात से अलग पहचाने जा सकते हैं कि सत्र किस कर्मचारी संदर्भ से आया? यदि उत्तर नहीं है, तो वह बाधा किसी भी विक्रेता की सुविधा सूची से अधिक डिज़ाइन गढ़ती है.

जहाँ उत्तर हाँ है, रूटिंग संदर्भ वही बन जाता है जिसे आप प्रलेखित और परखते हैं, क्योंकि वह traceroute में अदृश्य है.

तय करें कि कर्मचारी क्या लिखता है और साझेदार क्या दर्ज करता है

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

फिर कर्मचारी की ओर से एक वास्तविक कार्य चलिए: वे क्या क्लिक करते हैं, उनसे क्या माँगा जाता है, और यदि साझेदार लॉग प्रविष्टि माँगे तो क्या देखेगा. यदि वह चाल दोहराई नहीं जा सकती, तो डिज़ाइन पूरा नहीं है.

साझेदार-से-साझेदार पारगमन स्पष्ट रूप से अस्वीकार करें

साझा हार्डवेयर को कभी साझा भरोसा नहीं दर्शाना चाहिए. अस्वीकृति को नामित स्वामी वाला जानबूझकर बनाया गया नियम जोड़ें, अनुपस्थित कॉन्फ़िगरेशन की दुर्घटना नहीं, और इसे दोनों दिशाओं से ऐसे अनुरोध से परखें जो अन्यथा सफल होता. परीक्षण मायने रखता है क्योंकि केवल अनुपस्थित अनुमति को अगला इंजीनियर बहाल कर सकता है जो असंबंधित शिकायत ठीक करने के लिए रूट जोड़ता है.

अस्वीकृति को अनुमतियों के बगल में साझेदार रिकॉर्ड में लिखें, ताकि इरादा कर्मचारी बदलावों के बाद भी बना रहे.

इसे बड़े लैपटॉप के रूप में नहीं, साझा सेवा के रूप में चलाएँ

टनल नवीनीकरण, क्रेडेंशियल रोटेशन, क्षमता और गेटवे प्रतिस्थापन अब सभी साझा-सेवा परिवर्तन बन जाते हैं, जिसका अर्थ है कि उन्हें एक समय-सारिणी और संचार मार्ग चाहिए जो व्यक्तिगत लैपटॉप को कभी नहीं चाहिए था. शनिवार को समाप्त होने वाला साझेदार प्रमाणपत्र अब एक उपयोगकर्ता का व्यवधान नहीं है; यह उस साझेदार के सभी सत्र एक साथ हैं.

स्तर तभी स्वीकार करें जब अस्वीकृत अंतर-साझेदार अनुरोध ठीक वैसे ही विफल हो जैसे इरादा था और अनुमत कर्मचारी अनुरोध सही स्रोत के साथ सही गंतव्य तक पहुँचे. लैपटॉप टकराव हटाना और हर साझेदार की सीमा अक्षुण्ण रखना ही पूरी बात है; ऐसा डिज़ाइन जिसमें हर दूरस्थ उपसर्ग हर डेस्क से पहुँच योग्य है, समस्या को केवल खिसका देता है.

साझेदार, संदर्भ, अनुमत श्रेणियों और स्वामी की एक छोटी तालिका रखें. किसी घटना के दौरान लोग सबसे पहले यही माँगेंगे.