घरेलू 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 अनावश्यक संग्रह और सहसंबंध को गोपनीयता के मुद्दे मानता है, और वही सिद्धांत यहाँ लागू होता है: वह प्रमाण साझा करें जो प्राप्तकर्ता को चाहिए, पूरी मशीन नहीं।

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