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 सूची र न्यूनतम संस्करणसँग मेल खान्छ कि, र पोर्ट साँच्चै राउटरमा फर्वार्ड भएको छ कि जाँच्नुहोस्।

बनाइएको कन्फिग र सुधार प्रमाणित गर्ने लग लाइन सुरक्षित राख्नुहोस्। अर्को फर्मवेयर अपडेटले पूर्वनिर्धारित फेरि बदल्न सक्छ, र त्यही अभिलेखले पुनरावृत्तिलाई पाँच मिनेटको जाँचमा बदल्छ।