जडान अस्वीकृत हुनु प्रमाणपत्रको समस्या होइन: 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, वा ग्राहक जोडिनुअघि नै म्याद सकिएको CRL ले ग्राहकको आफ्नै प्रमाणपत्रसँग कुनै सम्बन्ध नभएका प्रमाणीकरण त्रुटिहरू उत्पन्न गर्छ।

अर्को पटकका लागि छोटो रनबुक

पहिले यातायात पुष्टि गर्नुहोस्: सुन्ने उपस्थित, सही ठेगाना परिवार, फायरवाल अस्वीकार गर्दैन। त्यसपछि स्टार्टअप लग पढेर सेवा सुन्ने अवस्थामा पुगेको पुष्टि गर्नुहोस्। र त्यसपछि मात्र प्रमाणीकरण सन्देशका लागि ह्यान्डशेक त्रुटिहरू हेर्नुहोस्। यो क्रम स्थिर राख्नुहोस्, किनकि प्रत्येक चरणले कारणको एउटा पूरा वर्ग हटाउँछ।

यातायात, रिजोल्भ भएको गन्तव्य, पोर्ट र त्रुटिको ठ्याक्कै पाठ लेख्नुहोस्। ग्राहक पुनः स्थापना गर्दा त्यो प्रमाण नष्ट हुन्छ र सामान्यतया केही पनि बदलिँदैन।