L2TP प्रोफ़ाइल की कौन-सी परत वास्तव में टूटी

सेटिंग्स पृष्ठ पर आड़े नहीं, स्टैक में नीचे उतरें: IPsec बातचीत, फिर L2TP नियंत्रण, फिर PPP प्रमाणीकरण, फिर पता और DNS आवंटन। हर परत का अपना त्रुटि-हस्ताक्षर और अपना संभावित कारण है। उपयोगकर्ता प्रमाणीकरण में विफल होने वाली प्रोफ़ाइल पहले ही तीन जाँचों से गुज़र चुकी है, जहाँ समय-सीमा पहले ख़त्म होने वाली प्रोफ़ाइल कभी नहीं पहुँची। इसी क्रम को पहले तय करना है।

एक ही प्रोटोकॉल नाम चार अलग बातचीतें छिपाता है।

सेटिंग्स बदलने से पहले परत को नाम दें

IPsec सेटअप विफल होना साझा रहस्य, एल्गोरिदम या साथी की पहचान की ओर इशारा करता है। इसके बाद L2TP नियंत्रण विफल होना स्वयं सुरंग परत को इंगित करता है, जो अधिक संकीर्ण समस्या है। PPP प्रमाणीकरण की विफलता खाते या प्रमाणीकरण विधि का नाम लेती है। प्रमाणीकरण के बाद पता या DNS की विफलता का अर्थ है कि परिवहन काम कर गया और कॉन्फ़िगरेशन का आदान-प्रदान नहीं।

क्लाइंट संस्करण, ऑपरेटिंग सिस्टम संस्करण और ऑपरेटर की प्रलेखित व्यवस्था लिख लें। इन तीनों के बिना हर बदलाव एक अनुमान है जो ग़लती से कुछ और ठीक कर सकता है।

प्रोफ़ाइल की वर्तमान क्लाइंट से तुलना करें

सहेजी गई प्रोफ़ाइल में ऐसा साझा रहस्य, प्रमाणीकरण विकल्प या एंडपॉइंट हो सकता है जिसे वर्तमान क्लाइंट अब स्वीकार नहीं करता। कुछ प्लेटफ़ॉर्म ने L2TP/IPsec समर्थन पूरी तरह वापस ले लिया या हटा दिया है, और अद्यतन क्लाइंट सर्वर पर बिना किसी बदलाव के पुराने IKE व्यवहार को छोड़ सकता है। अपने सहेजे गए मानों की तुलना ऑपरेटर की वर्तमान प्रलेखित आवश्यकताओं से करें, एक वर्ष पहले जो काम करता था उससे नहीं। इन दो दस्तावेज़ों के बीच का अंतर ही आम तौर पर वह जगह होती है जहाँ उत्तर होता है।

कैश में रखा रहस्य या नाम बदला हुआ खाता आम तौर पर सामान्य प्रोफ़ाइल अद्यतन से अधिक नहीं माँगता, और कुछ भी फिर से डिज़ाइन करने से पहले दोनों की जाँच करनी चाहिए। ये सस्ते सुधार हैं और किसी भी संरचनात्मक काम से पहले इन्हें बाहर रखना चाहिए।

पुराने विकल्प सक्षम करने से वापस नहीं आते

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

सब कुछ सक्षम करने वाला सुधार वास्तविक विफलता से कहीं अधिक बदल देता है और आपको यह बताने में असमर्थ छोड़ देता है कि उसे किसने ठीक किया।

माइग्रेशन को परियोजना के रूप में प्रस्तुत करें

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

माइग्रेशन वह क्षण भी है जब लिखा जाए कि प्रोफ़ाइल किसलिए थी। अन्यथा अगला व्यक्ति बिना किसी व्याख्या के एक काम करने वाला कनेक्शन विरासत में पाता है।

परत, क्लाइंट संस्करण और ऑपरेटर की वर्तमान आवश्यकताएँ जाँचें। फिर तय करें कि यह सुधार है या प्रतिस्थापन।