DD-WRT वरील OpenVPN 2.5 लिसनर मेला? त्याने तयार केलेली कॉन्फिग वाचा

DD-WRT वर मृत लिसनरचा अर्थ सहसा डेमन त्याची कॉन्फिग पार्स करत असतानाच बाहेर पडला, असे नाही की फायरवॉल नियमाने पोर्ट अडवला. OpenVPN 2.5 ने जुन्या कॉन्फिग अवलंबून असलेली अनेक डीफॉल्ट कडक केली, आणि जुन्या बिल्डवर चाललेली तयार केलेली कॉन्फिग सॉकेट उघडण्यापूर्वीच नाकारली जाऊ शकते. कारण राउटरच्याच लॉगमध्ये आहे, आणि इनपुट तयार केलेल्या फाइलमध्ये आहे. दोन्ही याच क्रमाने वाचणे कोणत्याही पॅकेट कॅप्चरपेक्षा वेगवान आहे.

डेमन म्हणजे फायरवॉल नाही

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

काहीही बदलण्यापूर्वी दोन तपासण्यांनी हे वेगळे करा, कारण मृत डेमनवर फायरवॉल संपादन फक्त दुसरे चल जोडते.

DD-WRT ने तयार केलेली कॉन्फिग वाचा

DD-WRT वेब इंटरफेसमध्ये टाइप केलेला मजकूर OpenVPN ला देत नाही. ते तयार केलेली कॉन्फिग /tmp/openvpn/openvpn.conf मध्ये लिहिते आणि त्या फाइलने डेमन सुरू करते, त्यामुळे इंटरफेसची फील्ड्स आणि Additional Config मधील कोणताही मजकूर OpenVPN ला दिसण्यापूर्वीच एकत्र होतो. तुम्ही तयार केलेल्या फाइलऐवजी फॉर्म डीबग करत असाल, तर तुम्ही हेतू वाचत आहात, प्रत्यक्ष इनपुट नाही. रीबूट /tmp पुसण्यापूर्वी ती फाइल कायमच्या जागी कॉपी करा.

तयार केलेल्या फाइलची तुम्ही इच्छित असलेल्या गोष्टीशी तुलना करा, विशेषतः जिथे इंटरफेस तुम्ही कधीही न निवडलेले निर्देश लिहिते. जुना पर्याय बाहेर काढणारा ड्रॉपडाउन फॉर्ममध्ये अदृश्य आणि डेमनसाठी घातक असतो.

तयार केलेली फाइल रिकामी असेल किंवा नसेल, तर डेमन सुरू होण्यापर्यंतही पोहोचला नाही, आणि समस्या OpenVPN च्या आधी आहे.

OpenVPN 2.5 ने काय स्वीकारणे थांबवले

OpenVPN 2.5 ने ncp-ciphers च्या जागी data-ciphers वापरले, आणि डीफॉल्ट किमान TLS आवृत्ती 1.2 केली. त्याने कॉम्प्रेशनची हाताळणीही बदलली, त्यामुळे कॉम्प्रेशन देणारा सहकारी नाकारला जातो, जोपर्यंत कॉन्फिग स्पष्टपणे परवानगी देत नाही, आणि ns-cert-type सारख्या जुन्या पर्याय नावांना remote-cert-tls च्या बाजूने अप्रचलित केले. यातील प्रत्येक बदल पूर्वी चालणाऱ्या कॉन्फिगचे पार्स किंवा वाटाघाटी अपयशात रूपांतर करतो.

अपयशाची पद्धत निर्देशावर अवलंबून आहे. अज्ञात किंवा काढून टाकलेला पर्याय सुरुवातीला डेमन थांबवतो, तोच तुमचा मृत लिसनर. वाटाघाटीत तफावत डेमन चालू ठेवते आणि क्लायंट नाकारते, जे क्लायंटच्या बाजूने फायरवॉल समस्येसारखे दिसते.

लॉगमधील पहिली त्रुटी वाचा, शेवटची नाही. पार्सिंग पहिल्या चुकीच्या निर्देशावर थांबते, आणि त्यानंतरचे सर्व बंद होण्याचा गोंगाट आहे.

Broadcom-विशिष्ट पूर्वअटी

Broadcom बिल्डवर डेमन वापरण्यापूर्वी टनेल उपकरण असणे आवश्यक आहे. tun मॉड्यूल लोड आहे का आणि /dev/net/tun आहे का ते तपासा, कारण उपकरण नसल्यास प्रमाणपत्रांशी काहीही संबंध नसलेले सुरुवातीचे अपयश होते. DD-WRT मार्ग आणि DNS साठी तयार करते त्या सहाय्यक स्क्रिप्टनाही हेच लागू आहे: त्या नसतील किंवा चालवता येणार नसतील, तर डेमन सुरू होऊ शकतो आणि तरीही त्याचे सेटअप पूर्ण करू शकत नाही.

खरा संदेश हवा असल्यास तयार केलेल्या कॉन्फिगवर अधिक तपशिलासह डेमन फोरग्राउंडमध्ये चालवा. फोरग्राउंड रन ती पार्स त्रुटी छापते जी init स्क्रिप्टने गिळली होती.

नंतर सामान्य सेवा पुनर्संचयित करा, कारण फोरग्राउंड डेमन आणि init स्क्रिप्ट पोर्टसाठी भांडतील.

क्लायंट डीबग करण्यापूर्वी लिसनर अस्तित्वात असल्याचे सिद्ध करा

प्रक्रिया आणि सॉकेट स्वतंत्रपणे तपासा: एक आदेश चालू असलेल्या डेमनसाठी, दुसरा अपेक्षित पत्त्यावर बांधलेल्या UDP पोर्टसाठी. सॉकेट नसलेल्या प्रक्रियेचा अर्थ ती अजून सेटअपमध्ये आहे किंवा चुकीच्या इंटरफेसला बांधली आहे. ही जोडी उपयुक्त चाचणी आहे कारण एक अर्धा दुसऱ्याशिवाय खरा असू शकत नाही.

क्लायंट बाजूची डीबगिंग लिसनर अस्तित्वात आल्यावरच अर्थपूर्ण ठरते. तेव्हा क्लायंटचे साइफर आणि TLS सेटिंग्ज सर्व्हरच्या data-ciphers यादीशी आणि किमान आवृत्तीशी जुळतात का, आणि पोर्ट प्रत्यक्षात राउटरकडे पाठवला जातो का ते तपासा.

तयार केलेली कॉन्फिग आणि दुरुस्ती सिद्ध करणारी लॉग ओळ जतन करा. पुढील फर्मवेअर अद्यतन डीफॉल्ट पुन्हा बदलू शकते, आणि तीच नोंद पुनरावृत्ती पाच मिनिटांच्या तपासणीत बदलते.