राउटरमा OpenVPN सेटिङहरू रिबुटपछि फर्किन्छन्: जेनेरेटर ठीक गर्नुहोस्

उपभोक्ता राउटर वा NAS मा रहेको फर्मवेयरले प्रायः हरेक सुरुवातमा आफ्नो OpenVPN कन्फिगरेसन पुनः बनाउँछ, त्यसैले तपाईंले थप्ने निर्देश ठ्याक्कै अर्को बुटसम्म मात्र टिक्छ। वेब फारममा टाइप गरिएका कुञ्जीहरूमा पनि यही लागू हुन्छ, जहाँ सुरक्षित गरिएको मान सुरक्षित गरेपछि बिग्रिएर फर्कन सक्छ। यीमध्ये कुनै पनि लक्षणले परिवर्तन अस्वीकृत भयो भन्ने बुझाउँदैन। यसको अर्थ सम्पादन फर्मवेयरले आउटपुट मान्ने फाइलमा पुग्यो, र टिकाउ ठाउँ बुट क्रममा एक कदम अगाडि छ।

सम्पादित फाइल किन फेरि बनाइन्छ

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

बुट क्रमले के लेख्छ र कहिले लेख्छ हेर्नुहोस्। उत्तर लगभग सधैं फर्मवेयरको init वा अटोरन डिरेक्टरीमा रहेको स्क्रिप्ट हो।

स्क्रिप्टले फाइल बनाउने ठाउँमै निर्देश राख्नुहोस्

QTS उपकरणहरूले डेमन सुरु गर्ने init स्क्रिप्टभित्रै OpenVPN सर्भर कन्फिगरेसन पुनः बनाउँछन्, त्यसैले सम्पादन त्यहीँ हुनुपर्छ। बनेको फाइल सम्पादन गर्नुको साटो स्टार्टअप कमान्डको ठ्याक्कै अगाडि थपाइ थप्नुहोस्।

sed -i '/daemon_mgr/i echo client-config-dir clientconfig >>/etc/openvpn/server.conf' /etc/init.d/vpn_openvpn.sh
grep -c client-config-dir /etc/openvpn/server.conf

लाइन नम्बरहरू बिल्डहरूबीच बदलिने भएकाले नसर्ने कमान्डमा इन्सर्सन एङ्कर गर्नुहोस्। init स्क्रिप्ट आफै बुटका क्रममा प्रतिस्थापन हुने भएकाले प्रणाली सुरु हुने हरेक पटक फर्मवेयरको अटोरन हुकबाट परिवर्तन पुनः जारी गर्नुपर्छ। एक रिबुटपछि बनेको फाइलमा घटनाहरू गन्नुहोस्: एउटा लाइन भनेको प्याचले काम गर्यो, दुई लाइन भनेको हुक एकपटकभन्दा बढी चलिरहेको छ। दोहोरो रन अलगै अनुसन्धान गर्नुहोस्, किनकि त्यो हराएको परिवर्तनजस्तै त्यही खराबी होइन।

एस्केप गरिएका कुञ्जी भण्डारण गरेको फारम मर्मत गर्नुहोस्

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

openssl dhparam -out dh2048.pem 2048
grep -n "BEGIN DH PARAMETERS" dh2048.pem

नयाँ प्यारामिटर सेट फेर्दा, लेबलले कुञ्जीको मुख्य भाग माग्यो भने मात्र base64 पेलोड टाँस्नुहोस्, र फिल्डले पूरा PEM ब्लक अपेक्षा गरेमा मात्र आर्मर लाइनहरू राख्नुहोस्। पहिल्यै एस्केप गरिएको रूपमा सुरक्षित भएको पृष्ठ पुनःप्राप्त गर्नु भनेको सामान्यतया प्रभावित इनपुटहरू खाली गरेर लागू गर्नु हो, जसले फर्मवेयरलाई तिनीहरू फेरि बनाउन दिन्छ। 2048 बिटभन्दा माथिको जे पनि कार्यस्टेशनमा उत्पन्न गर्नुहोस्, किनकि राउटरको एन्ट्रोपी आपूर्तिले कार्यलाई ढिलो र कहिलेकाहीँ अविश्वसनीय बनाउँछ। प्यारामिटर फाइल फ्याक्टरी रिसेटपछि पनि पुग्न सकिने ठाउँमा राख्नुहोस्।

अपग्रेडपछि फेरि जाँच्नुहोस्

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

त्यसपछि क्लाइन्ट जोड्नुहोस् र पुश गरिएको विकल्पका लागि सर्भर लग पढ्नुहोस्। फारममा मात्र अस्तित्वमा रहेको सेटिङ भनेको कसैले परीक्षण नगरेको सेटिङ हो।