OpenVPN TLS हैंडशेक विफल: आप किस शाखा पर हैं?

जो पंक्ति कहती है कि TLS हैंडशेक विफल हुआ, वह किसी कहानी का अंत है, शुरुआत नहीं। असली महत्व उसके ठीक पहले की घटना का है, क्योंकि वही घटना बताती है कि आपके पास चार बिल्कुल अलग खराबियों में से कौन-सी है। समय-समाप्ति, नियंत्रण चैनल का बेमेल होना, प्रमाणपत्र का अस्वीकार होना और बातचीत के बाद की विफलता सब एक ही शीर्षक पैदा करते हैं। साक्ष्यों से शाखा चुनें, फिर सुधार अनुमान नहीं रहेगा।

विफलता से पहले की अंतिम घटना पढ़ें

अंतिम पंक्ति पढ़ने के बजाय ऊपर स्क्रॉल करें। डिस्कनेक्ट से पहले की घटना आम तौर पर चरण का नाम बताती है: कोई जवाब नहीं, नियंत्रण पैकेटों के आदान-प्रदान में त्रुटि, सत्यापन का परिणाम, या सफल बातचीत जिसके बाद प्रमाणीकरण का परिणाम आता है। इनमें से हर एक अलग मालिक का है। वही एक पंक्ति तय करती है कि नीचे का कौन-सा खंड लागू होता है।

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

एक सटीक पहली त्रुटि लंबे लॉग अंश से अधिक मूल्यवान है। वह चरण का नाम बताती है, और चरण मालिक का नाम बताता है।

शाखा एक: कुछ भी वापस नहीं आया

अगर क्लाइंट ने अपना पहला पैकेट भेजा और कुछ भी उपयोगी नहीं मिला, तो समस्या मार्ग पर या श्रोता के पास है। पुष्टि करें कि प्रोफ़ाइल उस विकल्प से मेल खाती है जो ऑपरेटर वास्तव में देता है: पता, पोर्ट और UDP या TCP। फिर जाँचें कि इस नेटवर्क से अंतिम बिंदु तक पहुँचना संभव है या नहीं। आगे बढ़ने से पहले लिखें कि इन दो जाँचों में से कौन-सी विफल हुई।

एक ही होस्टनाम पर पृष्ठ लोड करने वाला ब्राउज़र केवल यह साबित करता है कि कोई वेब सेवा उत्तर दी। स्वीकृत TCP कनेक्शन भी इस बारे में कुछ नहीं कहता कि OpenVPN ने बातचीत पूरी की या नहीं।

अगर प्रोफ़ाइल किसी अन्य विश्वसनीय नेटवर्क पर काम करती है, तो वह तुलना रखें। यह प्रतिबंध को मार्ग या मध्यस्थ तक सीमित करता है।

शाखा दो: नियंत्रण चैनल मेल नहीं खाता

जब आदान-प्रदान शुरू होकर फिर अटक जाता है, तो नियंत्रण चैनल की सेटिंग्स पहला संदिग्ध हैं। tls-auth और tls-crypt को परिनियोजन से मेल खाना चाहिए, और दूसरे सर्वर की सामग्री उपयोगी आदान-प्रदान नहीं देगी। यह विफलता किसी भी खाता लॉगिन से पहले होती है। पुराने सर्वर से नकल की गई प्रोफ़ाइल आम स्रोत है।

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

यह देखने के लिए कि क्या टिकता है, ढेर सारे पुराने एल्गोरिदम चालू करने के बजाय विशिष्ट बातचीत त्रुटि दर्ज करें। कैप्चर किया गया त्रुटि पाठ ही ऑपरेटर को अपना पक्ष जाँचने देता है।

शाखा तीन: एक प्रमाणपत्र अस्वीकार हुआ

स्पष्ट सत्यापन विफलता उस प्रमाणपत्र का नाम लेती है जो उसे पसंद नहीं। पहले डिवाइस की घड़ी जाँचें, फिर पढ़ें कि कौन-सी वस्तु विफल हुई: सर्वर प्रमाणपत्र, क्लाइंट प्रमाणपत्र, या श्रृंखला में कोई जारीकर्ता। समाप्ति, अविश्वसनीय जारीकर्ता और अप्रत्याशित पहचान तीन अलग संदेश हैं।

सुधरी सामग्री प्राप्त करते समय सत्यापन चालू रखें। असंबंधित प्रमाणपत्र स्वीकार करने से त्रुटि हट जाती है, पर यह साबित नहीं होता कि आप इच्छित सर्वर तक पहुँचे।

लिखें कि विफलता नेटवर्क का पीछा करती है या प्रोफ़ाइल का। हर जगह दिखने वाली प्रमाणपत्र त्रुटि मार्ग की समस्या नहीं है।

शाखा चार: बातचीत पूरी हुई और कुछ और विफल हुआ

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

समस्या बताते समय कहें कि क्या हर नेटवर्क विफल होता है, क्या कोई अन्य प्रोफ़ाइल काम करती है, और क्या सर्वर ने प्रयास दर्ज किया। सर्वर की ओर से चुप्पी और उसकी ओर से अस्वीकार अलग-अलग सीमाओं पर खड़े हैं।