भागीदारांना एकत्र न आणता भागीदार VPN प्रवेश केंद्रित करा

हा प्रस्ताव रास्त आहे: डझनभर लॅपटॉपवर पसरलेल्या पाच भागीदार टनेली, पाच क्लायंट आवृत्त्यांचे संच, पाच हेल्प-डेस्क स्क्रिप्ट्स आणि त्या कशा जुळतात हे जाणणारा एक अभियंता. त्यांना नियंत्रित प्रवेश स्तरावर हलवल्याने एंडपॉइंटची विखुरलेली अवस्था सुटते. त्याचबरोबर तुमच्या आर्किटेक्चरमध्ये नवीन घटक तयार होतो — आता स्वतःचे अधिकृती मॉडेल लागणारी सामायिक प्रवेश सेवा; आणि सर्वांनी कमी लेखलेली अयशस्वीता म्हणजे सर्व टनेली सुरू असलेले केंद्रीय उपकरण शांतपणे अशा संस्थांमधील ट्रान्झिट नेटवर्क बनणे, ज्यांनी कधीही शेजारी होण्यास संमती दिली नाही. तो धोका हा रचनेचा निर्णय आहे, हार्डवेअर स्वतः करत असलेली गोष्ट नाही. खालील काम म्हणजे अनपेक्षित दुष्परिणाम स्वीकारल्याशिवाय सोय टिकवण्याचा मार्ग.

प्रत्येक भागीदाराने आधीच स्वाक्षरी केलेल्या करारापासून सुरुवात करा

कोणत्याही संरचनेपूर्वी, तो भागीदार सामायिक गेटवे किंवा साइट कनेक्शनला अजिबात परवानगी देतो का याची खात्री करा. वैयक्तिक रिमोट-प्रवेश खाते, डिव्हाइस-पोस्चर अट किंवा परस्परसंवादी MFA प्रवाह माणसाशिवाय चालणाऱ्या सामायिक टनेलवर हस्तांतरित होऊ शकत नाही; आणि एकाच कॉपी केलेल्या क्लायंट ओळखीमागे कर्मचाऱ्यांना एकत्र करणे हा असा शॉर्टकट आहे जो भागीदाराने त्यांचे लॉग तपासल्याशिवाय टिकतो. परवानगी दिलेल्या प्रत्येक कनेक्शनसाठी लक्ष्य श्रेणी, खाजगी DNS डोमेन, अधिकृत अंतर्गत स्रोत, प्रमाणीकरणाचा मालक आणि टनेल अयशस्वी झाल्यास काय व्हावे हे नोंदवा. भागीदाराला सामायिक कनेक्शन लिखित स्वरूपात पुष्टी करण्यास सांगा, ते स्वीकारणार असलेल्या स्रोत श्रेणींसह. तोंडी मान्यता सहसा त्यांची सुरक्षा टीम बदलणाऱ्या आठवड्यात अर्थ बदलते.

ती नोंद हेच अंतिम उत्पादन आहे. एखाद्या भागीदारासाठी ती लिहू शकत नसाल, तर तो भागीदार केंद्रीकरणासाठी तयार नाही.

फक्त लक्ष्याने नाही, संदर्भाने मार्गनिर्देशन करा

प्रत्येक संस्था एकाच RFC 1918 जागेतून निवडते, त्यामुळे दोन भागीदार शेवटी एकच खाजगी श्रेणी वापरतील. एक साधे मार्गनिर्देशन तक्ते केवळ लक्ष्य पत्त्यावरून योग्य भागीदार निवडू शकत नाही, म्हणून एकमेकांवर चढणाऱ्या श्रेणींना वेगळे मार्गनिर्देशन संदर्भ किंवा दुसरी ठरलेली रचना लागते. RFC 4364 मधील फॉरवर्डिंग-डोमेन प्रतिमान हे विभाजन का महत्त्वाचे आहे ते स्पष्ट करते, आणि तैनातीला आपल्या गेटवे प्लॅटफॉर्मकडून तोच गुणधर्म मागण्यासाठी MPLS चालवण्याची गरज नाही.

प्लॅटफॉर्मला सरळ प्रश्न विचारा: दोन भागीदार एकच लक्ष्य प्रीफिक्स सामायिक करूनही सत्र कोणत्या कर्मचाऱ्याच्या संदर्भातून आले यावरून वेगळे ओळखले जाऊ शकतात का? उत्तर नाही असल्यास, ती मर्यादा कोणत्याही विक्रेत्याच्या वैशिष्ट्य-यादीपेक्षा जास्त रचना घडवते.

जिथे उत्तर होय आहे, तिथे मार्गनिर्देशन संदर्भ हीच अशी गोष्ट आहे जी तुम्ही नोंदवता आणि तपासता, कारण ती traceroute मध्ये दिसत नाही.

कर्मचारी काय टाइप करतो आणि भागीदार काय लॉग करतो हे ठरवा

भागीदाराचे काही काम अनुप्रयोग प्रॉक्सी किंवा त्या भागीदाराच्या संदर्भात उघडणाऱ्या दूरस्थ कार्यक्षेत्रात बसते. इतर कामांना मंजूर कर्मचारी विभागातून मार्गित नेटवर्क प्रवेश लागतो, आणि दोन्ही पलीकडे वेगळे स्रोत पत्ते व वेगळे लेखापरीक्षण ठसे निर्माण करतात. सामायिक भाषांतरित स्रोत पत्ता परवानगी-यादी पूर्ण करताना कोणत्या उपकरणाने काय केले हे लपवतो, म्हणून कर्मचारी व सत्र यांची विश्वासार्ह नोंद ठेवा आणि गेटवे पत्त्याला ओळख मानण्याऐवजी अनुप्रयोग प्रमाणीकरण कायम ठेवा — जे भागीदाराने हे कोणी केले असे विचारेपर्यंत सोयीचे वाटते.

मग कर्मचाऱ्याच्या बाजूने एक खरे काम चालून पहा: ते काय क्लिक करतात, काय विचारले जाते आणि भागीदाराने लॉग नोंद मागितल्यास काय दिसेल. ती चाल पुनरुत्पादनीय नसेल, तर रचना पूर्ण झालेली नाही.

भागीदार-ते-भागीदार ट्रान्झिट स्पष्टपणे नाकारा

सामायिक हार्डवेअरने कधीही सामायिक विश्वास सूचित करू नये. नकार हा गहाळ संरचनेचा अपघात म्हणून नाही, तर नामनिर्देशित मालकासह जाणीवपूर्वक नियम म्हणून जोडा, आणि अन्यथा यशस्वी ठरणाऱ्या विनंतीने दोन्ही बाजूंनी तपासा. तपास महत्त्वाचा आहे कारण केवळ अनुपस्थित परवानगी, असंबंधित तक्रार दुरुस्त करण्यासाठी मार्ग जोडणारा पुढील अभियंता पुन्हा बसवू शकतो.

परवानग्यांच्या शेजारी भागीदाराच्या नोंदीत नकार लिहा, जेणेकरून हेतू कर्मचारीबदलालाही टिकेल.

ती मोठा लॅपटॉप नाही, सामायिक सेवा म्हणून चालवा

टनेल नूतनीकरण, क्रेडेन्शियल फिरती, क्षमता आणि गेटवे बदली हे सर्व आता सामायिक सेवेचे बदल आहेत, म्हणजे त्यांना असे वेळापत्रक व संवादमार्ग लागतो जो वैयक्तिक लॅपटॉपना कधीही लागला नव्हता. शनिवारी भागीदाराचे प्रमाणपत्र संपणे आता एका वापरकर्त्याचा खंड नाही; तो त्या भागीदाराच्या सर्व सत्रांचा एकाच वेळी खंड आहे.

नाकारलेली आंतर-भागीदार विनंती जशी अपेक्षित आहे तशीच अयशस्वी होते आणि मंजूर कर्मचारी विनंती योग्य स्रोतासह योग्य लक्ष्यापर्यंत पोहोचते, तेव्हाच स्तर स्वीकारा. लॅपटॉपचा संघर्ष दूर करताना प्रत्येक भागीदाराची सीमा अभंग ठेवणे हाच संपूर्ण हेतू आहे; प्रत्येक डेस्कवरून प्रत्येक दूरस्थ प्रीफिक्स गाठता येणारी रचना म्हणजे समस्या फक्त हलवणे.

भागीदार, संदर्भ, परवानगी असलेल्या श्रेणी आणि मालक यांचा छोटा तक्ता ठेवा. घटनेच्या वेळी सर्वात आधी हाच मागितला जाईल.