कनेक्शन अस्वीकार होना प्रमाणपत्र की समस्या नहीं है: VPN रनबुक

क्लाइंट कहता है कि CRL फिर से बनाने के ठीक बाद कनेक्शन अस्वीकार हुआ, इसलिए CRL दोषी लगता है। ऐसा नहीं है। इनकार परिवहन परत का उत्तर है, और प्रमाणपत्र का सत्यापन बाद में, टनल हैंडशेक के भीतर होता है। समय का मेल संदर्भ है, प्रमाण नहीं।

दो जाँचें एक मिनट से कम में मामलों को अलग कर देती हैं, और उनमें से कोई भी ट्रस्ट सेटिंग्स को नहीं छूती।

त्रुटि को उसी परत पर पढ़ें जिसने उसे बनाया

connect से ECONNREFUSED का अर्थ है कि परिवहन का प्रयास अस्वीकार हुआ: किसी ने reset से उत्तर दिया, या स्टैक ने अगम्य पोर्ट की सूचना दी। प्रमाणपत्र की समस्या यह त्रुटि नहीं बना सकती, क्योंकि परिवहन कनेक्शन के बिना TLS हैंडशेक कभी शुरू नहीं होता। अगर आपको इनकार दिखता है, तो क्लाइंट कभी प्रमाणपत्र प्रस्तुत करने तक नहीं पहुँचा। यही एक तथ्य निरसन को कारण के रूप में बाहर कर देता है।

इसका उल्टा भी सत्य है। निरस्त प्रमाणपत्र पूरा TCP कनेक्शन और विफल हैंडशेक बनाता है, जो सर्वर पर सत्यापन त्रुटि के रूप में दर्ज होता है।

TCP इनकार: कोई सुन नहीं रहा

TCP के लिए, जाँचें कि इच्छित इंस्टेंस चल रहा है और प्रोफ़ाइल में दिए पते और पोर्ट से बँधा है। ss -lntp श्रोताओं को दिखाता है, और उनमें से एक का न होना सामान्य व्याख्या है। जो फ़ायरवॉल छोड़ने के बजाय इनकार करता है वह क्लाइंट की ओर वही संदेश बनाता है, इसलिए आप दोनों जाँचते हैं।

पता परिवार भी जाँचें। 127.0.0.1 या केवल IPv6 से बँधी सेवा उस क्लाइंट को इनकार कर देगी जो दूसरे पर रिज़ॉल्व होता है।

फिर अनुमान लगाने के बजाय सेवा लॉग पढ़ें। CA रखरखाव के बाद पुनः आरंभ अ-पठनीय या अनुपस्थित फ़ाइल पर विफल हो सकता है और कभी सुनने की स्थिति तक नहीं पहुँचता, और लॉग फ़ाइल का नाम बताता है। यह स्टार्टअप विफलता है, अस्वीकृत प्रमाणपत्र से भिन्न बग।

UDP के पास अस्वीकार करने के लिए हैंडशेक नहीं है

UDP पर OpenVPN TCP के अर्थ में कनेक्शन स्थापित नहीं करता, इसलिए connect के समय अस्वीकार करने को कुछ नहीं है। Linux में, UDP सॉकेट द्वारा दिखाई गई त्रुटि पहले के डेटाग्राम से उत्पन्न ICMP port-unreachable से आ सकती है। udp(7) मैन पेज उस अतुल्यकालिक व्यवहार का वर्णन करता है।

इसीलिए UDP क्लाइंट इनकार छाप सकता है जबकि सर्वर प्रक्रिया चल रही है पर अपेक्षित पते से बँधी नहीं है।

CRL वास्तव में कहाँ जाँचा जाता है

CRL से परामर्श TLS हैंडशेक के दौरान होता है, सामने वाले पक्ष द्वारा अपना प्रमाणपत्र प्रस्तुत करने के बाद, और केवल तभी जब सर्वर कॉन्फ़िगरेशन इसे सक्षम करता है। OpenVPN का crl-verify विकल्प फ़ाइल की ओर इंगित करता है, और विफलता सर्वर लॉग में प्रमाणपत्र का नाम लेने वाली सत्यापन त्रुटि के रूप में दिखती है।

इसलिए निरस्त क्लाइंट परिवहन परत पर जुड़ता है और फिर प्रमाणीकरण में विफल होता है। वही सर्वर, वही पोर्ट, बिल्कुल अलग संदेश।

जब आप उस चरण तक पहुँचें तो CRL का जारीकर्ता और वैधता तिथियाँ जाँचें। गलत CA द्वारा हस्ताक्षरित CRL, या वह जो क्लाइंट के जुड़ने से पहले समाप्त हो गया, ऐसी सत्यापन त्रुटियाँ बनाता है जिनका क्लाइंट के अपने प्रमाणपत्र से कोई संबंध नहीं है।

अगली बार के लिए एक छोटी रनबुक

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

परिवहन, रिज़ॉल्व किया गया गंतव्य, पोर्ट और त्रुटि का सटीक पाठ लिख लें। क्लाइंट को फिर से इंस्टॉल करने से वह साक्ष्य नष्ट हो जाता है और आम तौर पर कुछ नहीं बदलता।