कनेक्शन नाकारणे ही प्रमाणपत्राची समस्या नाही: 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, क्लायंटच्या स्वतःच्या प्रमाणपत्राशी काहीही संबंध नसलेल्या पडताळणी त्रुटी निर्माण करते.

पुढच्या वेळेसाठी छोटी रनबुक

प्रथम वाहतूक निश्चित करा: श्रोता उपस्थित, योग्य पत्ता कुटुंब, फायरवॉल नाकारत नाही. नंतर स्टार्टअप लॉग वाचून सेवा ऐकण्याच्या स्थितीत पोहोचली याची खात्री करा. आणि त्यानंतरच पडताळणी संदेशांसाठी हँडशेक त्रुटी पहा. हा क्रम स्थिर ठेवा, कारण प्रत्येक पायरी कारणांचा एक संपूर्ण वर्ग दूर करते.

वाहतूक, रिझोल्व्ह झालेले गंतव्य, पोर्ट आणि त्रुटीचा नेमका मजकूर लिहून ठेवा. क्लायंट पुन्हा इन्स्टॉल केल्यास तो पुरावा नष्ट होतो आणि सहसा काहीही बदलत नाही.