अर्ध-व्यवस्थित VPN: लेबलले भन्दैन कि ड्युटीमा को छ

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

असफल भएको जडानबाट सुरु गर्नुहोस्

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

धेरै प्रयोगकर्तामा साझा लक्षणले साझा कम्पोनेन्टतर्फ संकेत गर्छ, जबकि एउटै ल्यापटपको पछि लाग्ने लक्षणले क्लाइन्टतर्फ संकेत गर्छ। त्यो भिन्नताले कसैले कन्फिगरेसन खोल्नुअघि नै टिकटलाई सही लाइनमा राख्छ।

सेटिङअघि दुईवटै एन्डपोइन्ट टुंग्याउनुहोस्

ग्राहकतर्फको गेटवे कसको हो र टाढाको एन्डपोइन्ट कसको हो, त्यो निर्णय गर्नुहोस्। ती दुई टुंगिएपछि प्रत्येक पक्षलाई के जाँच्न सकिन्छ र के माग्नुपर्छ भन्ने थाहा हुन्छ। सम्झौताको बाँकी सबै त्यहाँबाट सजिलो हुन्छ।

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

साझा वस्तुको मालिक ठ्याक्कै एक हुनुपर्छ

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

चिरपरिचित खराबी भनेको एउटै हप्तामा एकतर्फ सिलेक्टर परिवर्तन र अर्कोतर्फ NAT परिवर्तन हो। कुनै पनि इन्जिनियरले गल्ती गरेनन्, तैपनि टनेलले अनुप्रयोग बोक्न छोड्यो।

पहिलो रिपोर्ट कसले लिन्छ

पहिले कसलाई बोलाइन्छ, प्रत्येक पक्षले के पढ्न पाउँछ र कुन बिन्दुमा मुद्दा हात सर्छ, त्यो अग्रिम निर्णय गर्नुहोस्। एन्डपोइन्ट, प्रयासको समय र अनुमति दिइएको प्रवाह दिनुहोस्, ताकि दुवै पक्षले एउटै घटना मिलाउन सकून्।

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

परिवर्तनको अधिकार त्यही सावधानीसँग परिभाषित गर्नुहोस्। प्रदायकले सिलेक्टर सम्पादन गर्दा ग्राहकले NAT सम्पादन गर्छ भने दुवै स्थानीय कन्फिगरेसन विश्वसनीय देखिन्छन् र टनेल तैपनि असफल हुन्छ।

लेबलले कहिल्यै नभन्ने कुरा

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

दायराले सामान्य अपरेटर र प्रत्येक निर्भरताका लागि एस्केलेसनको बाटो नाम दिनुपर्छ। कोटेशनले सेवालाई जे नाम दिए पनि, व्यवहारमा यसको अर्थ त्यही सूची हो।