घरायो VPN को सहयोग अनुरोधलाई एउटा प्रवाह चाहिन्छ, कन्फिगरेसनको थुप्रो होइन

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

अनुरोधले किन काम नलाग्ने उत्तर पाउँछ

कन्फिगरेसनले के कन्फिगर गरिएको छ भन्ने बताउँछ। तपाईंले के प्रयास गर्नुभयो, के भयो, वा धेरै मेसिनमध्ये कुनले कुन काम गर्ने हो भन्ने बताउँदैन। त्यो बिना हरेक पाठकले फरक चरण अनुमान गर्छ।

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

पोस्ट गर्नु अघि यो अभिलेख भर्नुहोस्

Goal: the one resource or operation that should work
Path: client -> access network -> VPN endpoint -> resource
Owners: who controls the client, the gateway and the resource
Software: product, version and protocol in use
Expected: what success would look like
Observed: exact non-secret error or response
Time and change: when it started and what changed
Control: one comparable operation that still works

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

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

असफल चरणको नाम दिनुहोस्, पूरै लग होइन

पाँच चरण छुट्याउन लायक छन्: नाम समाधान, जडान प्रयास, प्रमाणीकरण, सुरुङ स्थापना र स्रोतमा पहुँच। तपाईंको विचारमा कुन असफल भयो र त्यहाँ के देख्नुभयो भन्नुहोस्।

क्लाइन्टले बनाउन सक्ने हरेक डिबग फाइलको सट्टा घटनाको वरपरको सानो अंश टाँस्नुहोस्। सय लाइन ह्यान्डशेक हल्लाको कारण प्रमाणपत्रको नाम मिलेन भन्ने त्यो एउटा लाइन लुक्छ।

अवलोकन र व्याख्या छुट्टै राख्नुहोस्। “क्लाइन्टले 30 सेकेन्डपछि ह्यान्डशेक समय सकिएको जनाउँछ” यो अवलोकन हो; “प्रदायकले UDP अवरुद्ध गर्छ भन्ने मलाई लाग्छ” यो सिद्धान्त हो। दुवै उपयोगी छन्, र तिनलाई मिसाउँदा सहयोग गर्नेले कुनलाई विश्वास गर्ने थाहा पाउँदैन। तिनलाई लेबल गर्नुहोस्, र पाइने उत्तर सहीसँग जान्छ।

कार्य गर्न सक्ने मालिककहाँ पठाउनुहोस्

रोजगारदाताले व्यवस्थापन गरेको ल्यापटपका लागि रोजगारदाताको समर्थित च्यानलबाट सुरु गर्नुहोस्, किनकि सामुदायिक फोरमले उनीहरूको नीति बदल्न सक्दैन। व्यावसायिक VPN सेवाका लागि उत्पादन र खाता सार्वजनिक होइन, निजी रूपमा भन्नुहोस्। आफ्नै गेटवेका लागि तपाईंले नियन्त्रण गर्ने राउटर र सर्भर भूमिका समावेश गर्नुहोस्।

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

टोपोलोजी समतल नबनाई गोप्य कुरा लुकाउनुहोस्

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

त्यसपछि प्रवाह बुझिने बनाउने सम्बन्ध जोगाउनुहोस्। RFC 6973 ले अनावश्यक संकलन र सहसम्बन्धलाई गोपनीयताको विषय मान्छ, र त्यही सिद्धान्त यहाँ पनि लागू हुन्छ: प्राप्तकर्तालाई चाहिने प्रमाण साझा गर्नुहोस्, पूरै मेसिन होइन।

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