अर्ध-व्यवस्थापित VPN: लेबल सांगत नाही की ड्युटीवर कोण आहे
लेबल हा प्रोटोकॉल नाही आणि विभाजनाची टक्केवारीही नाही. त्याला एंडपॉईंट, सामायिक सेटिंग्ज, देखरेख आणि घटनेच्या हस्तांतरणासाठी जबाबदारांमध्ये बदला, एका मागून एक काम.
सकाळी आठ वाजता एक कनेक्शन अयशस्वी होते, आणि पहिला प्रश्न असतो की ते कोणी दुरुस्त करायचे. अर्ध-व्यवस्थापित VPN हा शब्दप्रयोग त्याचे उत्तर देत नाही, कारण तो कामाच्या विभाजनाऐवजी व्यापारी कराराला नाव देतो. दोन पुरवठादार एकच शब्दप्रयोग विरुद्ध विभाजनासह वापरू शकतात: एक ग्राहकाच्या बाजूचे उपकरण सांभाळतो, दुसरा फक्त स्वतःचे गेटवे पाहतो. कामे लिहून ठेवेपर्यंत लेबल म्हणजे वर्णनाचा सोस पांघरलेला अंदाज.
अयशस्वी झालेल्या कनेक्शनपासून सुरुवात करा
उत्तर देणे थांबवलेला एंडपॉईंट, वेळ आणि तुटल्यावर वापरकर्ता काय करत होता ते नावाने सांगा. मग त्या मार्गातील घटकांची यादी करा: लॅपटॉप, स्थानिक सर्किट, ग्राहकाच्या बाजूचे गेटवे, पुरवठादाराचे गेटवे आणि त्यामागील संसाधन. प्रत्येकाकडे करारात मालक आहे किंवा एक पोकळी आहे. ते लावण्यास दहा मिनिटे लागतात आणि पुढील तीन तास ठरवते.
अनेक वापरकर्त्यांमध्ये सामायिक लक्षण सामायिक घटकाकडे निर्देश करते, तर एका लॅपटॉपच्या मागे जाणारे लक्षण क्लायंटकडे निर्देश करते. हा फरक कोणीही कॉन्फिगरेशन उघडण्यापूर्वी तिकिटाला योग्य रांगेत ठेवतो.
सेटिंग्जपूर्वी दोन्ही एंडपॉईंट निकाली काढा
ग्राहकाच्या बाजूच्या गेटवेचा मालक कोण आहे आणि दूरच्या एंडपॉईंटचा मालक कोण आहे ते ठरवा. हे दोन्ही निकाली निघाल्यावर प्रत्येक बाजूला काय तपासता येते आणि काय मागावे लागते हे कळते. करारातील बाकी सर्व तिथून सोपे होते.
पुरवठादार स्वतःच्या गेटवेची देखरेख करू शकतो, तर ग्राहक स्थानिक इंटरनेट सर्किट, डिरेक्टरी सेवा किंवा लक्ष्य अॅप्लिकेशनसाठी जबाबदार राहतो. ग्राहकाच्या मालकीचे उपकरण अजूनही पुरवठादाराच्या देखभाल कराराखाली असू शकते, म्हणून मालकी आणि बॉक्सची देखभाल कोण करतो हे दोन वेगळे प्रश्न आहेत. प्रत्येक एंडपॉईंटसाठी दोन्ही उत्तरे लिहा, कारण दुसऱ्यावरच नूतनीकरण सहसा वेगळे मत देते.
सामायिक वस्तूंना नेमका एकच मालक हवा
ओळख, क्रेडेन्शियल्स, संरक्षित उपसर्ग, प्रस्ताव आणि परतावा-मार्गनिर्देश करार या सामायिक वस्तू आहेत, आणि सामायिक वस्तू सर्वात वेगाने सडतात. दोन्ही पक्ष एक बदलू शकत असतील तर दोन्ही बदलतील, आणि मान्य प्रवाह तुटत असताना प्रत्येक बदल स्थानिक पातळीवर बरोबर दिसतो. प्रत्येक वस्तूला एक मालक आणि एक बदल प्रक्रिया द्या, आणि बदल लागू होण्यापूर्वी दुसऱ्या पक्षाला कळवणे बंधनकारक करा. पर्याय म्हणजे एकाच यंत्राचे वेगवेगळे अर्धे दुरुस्त करणाऱ्या दोन माणसांसारखा वाचला जाणारा बदल नोंदवही.
पारंपरिक बिघाड म्हणजे त्याच आठवड्यात एका बाजूला सिलेक्टर बदल आणि दुसऱ्या बाजूला NAT बदल. कोणत्याही अभियंत्याने चूक केली नाही, तरीही टनेलने अॅप्लिकेशन वाहून नेणे थांबवले.
पहिला अहवाल कोण घेतो
आधी कोणाला बोलावले जाईल, प्रत्येक पक्षाला काय वाचण्याची परवानगी आहे आणि प्रकरण कोणत्या टप्प्यावर हात बदलते हे आधीच ठरवा. एंडपॉईंट, प्रयत्नाची वेळ आणि परवानगी दिलेला प्रवाह द्या, जेणेकरून दोन्ही पक्ष एकाच घटनेची जुळवणी करू शकतील.
संकुचित स्थिती सारांश सहसा न संपादित केलेल्या कॉन्फिगरेशनपेक्षा उपयुक्त असतो, आणि तो गुपिते उघड करत नाही. देखरेख घटकाच्या मालकाची असते, लोगोच्या मालकाची नाही, म्हणून विचारा की कोणता पक्ष टनेलची स्थिती पाहतो, कोणता अॅप्लिकेशन पाहतो आणि प्रत्येक इशारा कोणाला जागवतो. प्रत्येक इशाऱ्याच्या शेजारी कामाच्या वेळेबाहेरचा मार्ग ठेवा, कारण ज्या डॅशबोर्डवर कोणी ड्युटीवर नाही तो केवळ दस्तऐवज आहे.
बदलाचा अधिकार त्याच काळजीने ठरवा. पुरवठादार सिलेक्टर संपादित करत असताना ग्राहक NAT संपादित करत असेल, तर दोन्ही स्थानिक कॉन्फिगरेशन विश्वासार्ह दिसतात आणि टनेल तरीही अयशस्वी होते.
लेबल कधीही न सांगणारी गोष्ट
सॉफ्टवेअर देखभाल, क्रेडेन्शियल्सची उलथापालथ, कॉन्फिगरेशनचे मंजूर बॅकअप आणि पुनर्प्राप्तीचा मार्ग खऱ्या करारात घाला. सामायिक जबाबदारीचा नमुना, जसा AWS प्रकाशित करते तो नमुना सेवांमधील विभाजन किती दूर सरकू शकते हे दाखवतो, आणि हे उदाहरण आहे, तुमच्या पुरवठादाराच्या अटींची व्याख्या नाही. अर्ध-व्यवस्थापित शब्दातून काहीही अनुमान काढणे म्हणजे नूतनीकरणाची चर्चा पोकळी कशी शोधते ते.
व्याप्तीने नेहमीचा ऑपरेटर आणि प्रत्येक अवलंबनासाठी एस्कलेशन मार्ग नावाने सांगावा. कोटेशन सेवेला काय नाव देत असो, प्रत्यक्षात त्या यादीचा अर्थ तोच आहे.