DD-WRT पर OpenVPN 2.5 लिसनर मृत? जो कॉन्फ़िग उसने बनाया, उसे पढ़ें

DD-WRT पर मृत लिसनर का अर्थ आम तौर पर यह होता है कि डेमन अपनी कॉन्फ़िग पार्स करते समय बाहर निकल गया, यह नहीं कि किसी फ़ायरवॉल नियम ने पोर्ट अवरुद्ध किया। OpenVPN 2.5 ने कई डिफ़ॉल्ट कड़े किए जिन पर पुरानी कॉन्फ़िग निर्भर थीं, और पुराने बिल्ड पर चलने वाली बनी हुई कॉन्फ़िग सॉकेट खुलने से पहले ही अस्वीकार की जा सकती है। कारण राउटर के अपने लॉग में है, और इनपुट बनी हुई फ़ाइल में। दोनों को इसी क्रम में पढ़ना किसी भी पैकेट कैप्चर से तेज़ है।

डेमन फ़ायरवॉल नहीं है

यह अंतर मायने रखता है क्योंकि दोनों विफलताएँ बाहर से एक जैसी दिखती हैं: क्लाइंट हैंडशेक भेजता है और कुछ वापस नहीं पाता। एक ऐसी प्रक्रिया है जो चल नहीं रही, और दूसरी ऐसी प्रक्रिया है जो चल रही है और फ़िल्टर कर रही है।

कुछ भी बदलने से पहले दो जाँचों से इन्हें अलग करें, क्योंकि मृत डेमन पर फ़ायरवॉल संपादन सिर्फ़ दूसरा चर जोड़ता है।

DD-WRT ने जो कॉन्फ़िग बनाया, उसे पढ़ें

DD-WRT आपको वेब इंटरफ़ेस में टाइप किया गया टेक्स्ट OpenVPN को नहीं देता। यह एक बनी हुई कॉन्फ़िग /tmp/openvpn/openvpn.conf में लिखता है और उसी फ़ाइल के साथ डेमन शुरू करता है, इसलिए GUI के फ़ील्ड और Additional Config का कोई भी टेक्स्ट OpenVPN के उन्हें देखने से पहले ही मिल जाते हैं। यदि आप बनी फ़ाइल की जगह फ़ॉर्म को डीबग करते हैं, तो आप इरादा पढ़ रहे हैं, वास्तविक इनपुट नहीं। रीबूट /tmp को साफ़ करने से पहले उस फ़ाइल को किसी स्थायी जगह कॉपी करें।

बनी फ़ाइल की तुलना उससे करें जो आप चाहते थे, ख़ासकर वहाँ जहाँ GUI कोई ऐसा निर्देश लिखता है जिसे आपने कभी चुना ही नहीं। पुराना विकल्प निकालने वाला ड्रॉपडाउन फ़ॉर्म में अदृश्य और डेमन के लिए घातक होता है।

यदि बनी फ़ाइल खाली है या मौजूद नहीं है, तो डेमन शुरू होने तक भी नहीं पहुँचा, और समस्या 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 सूची और न्यूनतम संस्करण से मेल खाते हैं, और पोर्ट वास्तव में राउटर तक फ़ॉरवर्ड है।

बनी कॉन्फ़िग और वह लॉग पंक्ति सहेजें जिसने सुधार साबित किया। अगला फ़र्मवेयर अपडेट डिफ़ॉल्ट फिर बदल सकता है, और वही रिकॉर्ड दोहराव को पाँच मिनट की जाँच में बदल देता है।