साझेदारहरूलाई गाभ्नु नै नगरी साझेदार VPN पहुँच केन्द्रीकृत गर्नुहोस्

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

प्रत्येक साझेदारले पहिले नै हस्ताक्षर गरेको सम्झौताबाट सुरु गर्नुहोस्

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

त्यो अभिलेख नै अन्तिम उत्पादन हो। एउटा साझेदारका लागि यो लेख्न सक्नुहुन्न भने त्यो साझेदार केन्द्रीकरणका लागि तयार छैन।

गन्तव्यले मात्र होइन, सन्दर्भले रुट गर्नुहोस्

प्रत्येक संस्था एउटै RFC 1918 ठाउँबाट छान्ने भएकाले दुई साझेदारले अन्ततः एउटै निजी दायरा प्रयोग गर्नेछन्। एउटा साधारण रुटिङ तालिकाले गन्तव्य ठेगानाका आधारमा मात्र सही साझेदार छान्न सक्दैन, त्यसैले एकअर्कामा पर्ने दायराका लागि छुट्टै रुटिङ सन्दर्भ वा अर्को सहमत नक्सा चाहिन्छ। RFC 4364 मा वर्णन गरिएको फर्वार्डिङ-डोमेन मोडेलले यो अलगाव किन महत्त्वपूर्ण छ भन्ने बताउँछ, र कुनै परिनियोजनले आफ्नो गेटवे प्लेटफर्मबाट त्यही गुण माग्न MPLS चलाउनु पर्दैन।

प्लेटफर्मलाई सीधा प्रश्न सोध्नुहोस्: दुई साझेदारले एउटै गन्तव्य प्रिफिक्स साझा गर्दै पनि सत्र कुन कर्मचारीको सन्दर्भबाट आयो भन्ने आधारमा छुट्याउन सकिन्छ? उत्तर होइन भए, त्यो सीमाले कुनै पनि विक्रेताको सुविधा सूचीभन्दा बढी नक्सा निर्धारण गर्छ।

उत्तर हो भए, रुटिङ सन्दर्भ नै तपाईंले अभिलेख र परीक्षण गर्ने कुरा बन्छ, किनभने traceroute मा त्यो देखिँदैन।

कर्मचारीले के टाइप गर्छ र साझेदारले के लग गर्छ भन्ने तय गर्नुहोस्

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

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

साझेदार-देखि-साझेदार ट्रान्जिट स्पष्ट रूपमा अस्वीकार गर्नुहोस्

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

अनुमतिहरूको छेउमै साझेदारको अभिलेखमा अस्वीकार लेख्नुहोस्, ताकि मनसाय कर्मचारी परिवर्तनपछि पनि टिकिरहोस्।

यसलाई ठूलो ल्यापटप होइन, साझा सेवाका रूपमा चलाउनुहोस्

टनेल नवीकरण, प्रमाण-पत्र परिक्रमा, क्षमता र गेटवे प्रतिस्थापन अब सबै साझा सेवाका परिवर्तन बन्छन्, जसको अर्थ व्यक्तिगत ल्यापटपलाई कहिल्यै नचाहिएको तालिका र सञ्चार मार्ग चाहिन्छ। शनिबार साझेदारको प्रमाणपत्र सकिनु अब एक प्रयोगकर्ताको अवरोध होइन; त्यो एकैचोटि त्यो साझेदारका सबै सत्रको अवरोध हो।

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

साझेदार, सन्दर्भ, अनुमति दिइएका दायरा र जिम्मेवार व्यक्तिको सानो तालिका राख्नुहोस्। घटना हुँदा सबैले पहिले यही माग्नेछन्।