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

फिर क्लाइंट कनेक्ट करें और पुश किए गए विकल्प के लिए सर्वर लॉग पढ़ें। जो सेटिंग कभी केवल फ़ॉर्म में रही हो, वह ऐसी सेटिंग है जिसे किसी ने जाँचा नहीं।