हाफ़-मैनेज्ड VPN: लेबल यह नहीं बताता कि ड्यूटी पर कौन है

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

उस कनेक्शन से शुरू करें जो फ़ेल हुआ

जिस एंडपॉइंट ने जवाब देना बंद कर दिया, समय, और जब वह टूटा तब उपयोगकर्ता क्या कर रहा था, इनके नाम बताइए। फिर उस रास्ते के घटकों की सूची बनाइए: लैपटॉप, स्थानीय सर्किट, ग्राहक पक्ष का गेटवे, प्रदाता का गेटवे और उसके पीछे का संसाधन। हर एक के पास या तो समझौते में मालिक है या फिर एक खाली जगह है। इन्हें छाँटने में दस मिनट लगते हैं और अगले तीन घंटे तय होते हैं।

कई उपयोगकर्ताओं में साझा लक्षण किसी साझा घटक की ओर इशारा करता है, जबकि एक ही लैपटॉप के पीछे चलने वाला लक्षण क्लाइंट की ओर इशारा करता है। यह अंतर किसी के कॉन्फ़िगरेशन खोलने से पहले ही टिकट को सही कतार में डाल देता है।

सेटिंग से पहले दोनों एंडपॉइंट तय करें

तय कीजिए कि ग्राहक पक्ष के गेटवे का मालिक कौन है और दूर के एंडपॉइंट का मालिक कौन है। ये दोनों तय होने के बाद हर पक्ष जानता है कि वह क्या जाँच सकता है और उसे क्या माँगना होगा। बाकी सब कुछ वहाँ से आसान हो जाता है।

प्रदाता अपने गेटवे की निगरानी कर सकता है, जबकि ग्राहक स्थानीय इंटरनेट सर्किट, डायरेक्टरी सेवा या गंतव्य एप्लिकेशन के लिए ज़िम्मेदार रहता है। ग्राहक के स्वामित्व वाला उपकरण फिर भी प्रदाता के रखरखाव समझौते के अंतर्गत हो सकता है, इसलिए स्वामित्व और बॉक्स की देखभाल कौन करता है, ये दो अलग सवाल हैं। हर एंडपॉइंट के लिए दोनों जवाब लिखिए, क्योंकि दूसरे पर ही नवीनीकरण आमतौर पर असहमत होते हैं।

साझा वस्तुओं का मालिक ठीक एक होना चाहिए

पहचान, क्रेडेंशियल, संरक्षित प्रीफ़िक्स, प्रस्ताव और वापसी-रूटिंग समझौता साझा वस्तुएँ हैं, और साझा वस्तुएँ सबसे तेज़ी से सड़ती हैं। अगर दोनों पक्ष एक को बदल सकते हैं, तो दोनों बदलेंगे, और हर बदलाव स्थानीय रूप से सही दिखता है जबकि सहमत प्रवाह टूट जाता है। हर वस्तु को एक मालिक और एक बदलाव प्रक्रिया दीजिए, और माँग कीजिए कि बदलाव लागू होने से पहले दूसरे पक्ष को बताया जाए। विकल्प यह है कि बदलाव लॉग ऐसा पढ़ा जाए जैसे दो लोग एक ही मशीन के अलग-अलग आधे हिस्से ठीक कर रहे हों।

क्लासिक विफलता यह है कि एक ही हफ़्ते में एक तरफ़ सिलेक्टर बदले और दूसरी तरफ़ NAT बदले। किसी भी इंजीनियर ने कुछ ग़लत नहीं किया, और टनल फिर भी एप्लिकेशन ढोना बंद कर गया।

पहली रिपोर्ट कौन लेता है

पहले से तय कीजिए कि सबसे पहले किसे बुलाया जाएगा, किस पक्ष को क्या पढ़ने की अनुमति है, और किस मोड़ पर मामला हाथ बदलता है। एंडपॉइंट, प्रयास का समय और अनुमत प्रवाह दीजिए ताकि दोनों पक्ष एक ही घटना का मिलान कर सकें।

सीमित स्थिति-सारांश आमतौर पर बिना संपादित कॉन्फ़िगरेशन से ज़्यादा उपयोगी होता है, और वह रहस्य नहीं लीक करता। निगरानी घटक के मालिक की होती है, लोगो के मालिक की नहीं, इसलिए पूछिए कि कौन पक्ष टनल की स्थिति देखता है, कौन एप्लिकेशन देखता है, और हर चेतावनी किसे जगाती है। हर चेतावनी के पास ड्यूटी के बाहर का रास्ता रखिए, क्योंकि जिस डैशबोर्ड पर कोई ड्यूटी पर नहीं है वह सिर्फ़ दस्तावेज़ है।

बदलाव का अधिकार उसी सावधानी से तय कीजिए। प्रदाता सिलेक्टर संपादित करे और ग्राहक NAT संपादित करे, तो दोनों स्थानीय कॉन्फ़िगरेशन विश्वसनीय दिखते हैं और टनल फिर भी फ़ेल होती है।

लेबल जो कभी नहीं बताता

सॉफ़्टवेयर रखरखाव, क्रेडेंशियल का घुमाव, कॉन्फ़िगरेशन के स्वीकृत बैकअप और रिकवरी का रास्ता असली समझौते में डालिए। साझा ज़िम्मेदारी का मॉडल जैसे वह मॉडल जो AWS प्रकाशित करती है दिखाता है कि सेवाओं के बीच बँटवारा कितना खिसक सकता है, और यह एक उदाहरण है, आपके आपूर्तिकर्ता की शर्तों की परिभाषा नहीं। हाफ़-मैनेज्ड वाक्यांश से कुछ भी निकालना यही है कि नवीनीकरण की बातचीत एक खाली जगह कैसे खोजती है।

दायरे में सामान्य ऑपरेटर और हर निर्भरता के लिए एस्केलेशन का रास्ता नामित होना चाहिए। कोटेशन सेवा को जो भी नाम दे, व्यवहार में उसका मतलब यही सूची है।