OpenVPN की कई --up स्क्रिप्ट की चेतावनी: चलती केवल एक है

कई स्क्रिप्ट वाली चेतावनी शेड्यूलिंग की शिकायत जैसी लगती है, इसलिए स्पष्ट उपाय यह है कि पंक्तियों को तब तक फिर से क्रम में लगाएँ जब तक वह गायब न हो जाए। यह शेड्यूलिंग की शिकायत नहीं है। बाद की --up परिभाषा उस चरण के लिए पहले से संग्रहीत आदेश को बदल देती है, और पार्सर यही कहता है, यानी आपकी दो स्क्रिप्ट में से ठीक एक ही कभी चली है। दूसरी उसके पीछे कतार में नहीं है; वह जा चुकी है।

इसीलिए चेतावनी ध्यान देने योग्य है, भले ही वह घातक न हो: यह जिस बात का पूर्वानुमान करती है वह DNS अद्यतन या मार्ग परिवर्तन है जो चुपचाप होना बंद हो गया।

चेतावनी क्रम के बारे में नहीं है

OpenVPN up चरण के लिए एक ही उपयोगकर्ता-स्क्रिप्ट आदेश रखता है। जब पार्सर को कोई दूसरी परिभाषा मिलती है, प्रोफ़ाइल से, शामिल फ़ाइल से या कमांड लाइन से, तो वह पहले से रखे आदेश को बदल देता है और चेतावनी देता है। कुछ भी जोड़ा नहीं जाता, कुछ भी दो बार नहीं चलता, और क्रम का कोई प्रश्न ही नहीं है। जो आदेश बचता है वही पार्सर ने आखिर में देखा था, इसलिए पंक्ति हटाने से विजेता बदल सकता है जबकि दूसरी स्क्रिप्ट मृत रहती है।

यही पैटर्न बाकी स्क्रिप्ट चरणों पर भी लागू होता है: हर एक के लिए एक आदेश। अगर दो काम दोनों होने चाहिए, तो उन्हें एक प्रवेश बिंदु चाहिए, सूची जैसी दिखने वाली दो निर्देश नहीं।

असली लॉन्च में दोनों परिभाषाएँ खोजें

जिस प्रोफ़ाइल को आपने संपादित किया उससे नहीं, बल्कि उससे शुरू करें जो डेमन को वास्तव में मिला। ps -ef और यूनिट का ExecStart कमांड लाइन दिखाते हैं, जिसमें कंटेनर प्रवेश बिंदु या रैपर से --up जुड़ सकता है; डिस्ट्रीब्यूशन की init फ़ाइल भी वही कर सकती है। systemctl cat openvpn-server@server दिखाता है कि सेवा स्वयं क्या जोड़ती है, और कॉन्फ़िगरेशन निर्देशिका पर पुनरावर्ती grep फ़ाइल-स्तरीय परिभाषाएँ ढूँढता है। नकलें अक्सर अलग-अलग परतों से आती हैं, और इसीलिए एक फ़ाइल संपादित करने से कुछ नहीं बदलता।

स्क्रिप्ट को दूसरी निर्देशिका में कॉपी करना या उसका नाम बदलना भी किसी निर्देश को नहीं हटाता। पार्सर फ़ाइलें नहीं, परिभाषाएँ गिनता है।

एक ही hook काम का मालिक हो

टिकाऊ उपाय एक ही डिस्पैचर है जो दोनों क्रियाएँ सोचे-समझे क्रम में चलाता है। set -eu वाली छोटी shell स्क्रिप्ट आवश्यक इंटीग्रेशन और फिर स्थानीय क्रिया को कॉल करती है, और तर्कों की सीमाएँ बची रहें इसलिए "$@" पास करती है; इससे व्यवहार एक ही जाँचने योग्य जगह पर रहता है। तर्क पास करना केवल उन्हें सुरक्षित रखता है; यह सिद्ध नहीं करता कि दोनों सहायक एक ही इंटरफ़ेस की अपेक्षा करते हैं, इसलिए हर एक का अनुबंध पढ़ें। तय करें कि विफलता को क्या करना चाहिए और क्या आंशिक परिवर्तन वापस लेने चाहिए।

अगर लॉन्चर समर्थित एक्सटेंशन hook देता है, तो हाथ से बनी श्रृंखला की तुलना में उसे प्राथमिकता दें। कंटेनर इमेज या विक्रेता पैकेज में अक्सर अतिरिक्त काम के लिए प्रलेखित जगह होती है, और उसका उपयोग अपग्रेड को आपके डिस्पैचर को अधिलेखित करने से रोकता है।

सफ़ाई संबंधित down चरण की है। DNS फिर से लिखने या मार्ग जोड़ने वाली up क्रिया को प्रलेखित उलटाव चाहिए, और केवल शुरुआत संभालने वाला डिस्पैचर आधा डिज़ाइन है।

केवल मौन नहीं, इंटीग्रेशन की पुष्टि करें

डुप्लिकेट चेतावनी हटाना आसान हिस्सा है; इंटीग्रेशन को अब भी काम करना है। कनेक्ट करने के बाद resolvectl status से या /etc/resolv.conf पढ़कर रिज़ॉल्वर की स्थिति जाँचें, और ip route से मार्गों की पुष्टि करें। फिर डिस्कनेक्ट करके दोबारा कनेक्ट करें, क्योंकि जल्दबाज़ी में जोड़ा गया hook अक्सर पिछले सत्र से कुछ छोड़ देता है। journalctl -u openvpn-server@server -b दिखाता है कि आपका डिस्पैचर चला और क्या छापा।

hook के विशेषाधिकार वहीं रखें जहाँ उन्हें होना चाहिए। script-security बढ़ाना या डेमन को अधिक अधिकारों से चलाना बदले गए hook का उपाय नहीं है; यह बढ़ाता है कि हर भविष्य की स्क्रिप्ट क्या कर सकती है, जिसमें वह भी शामिल है जिसका नाम कोई हमलावर रखे।

समाधान के वास्तविक होने का संकेत लॉग में मौन नहीं है। वह DNS उत्तर, मार्ग प्रविष्टि और सफ़ाई हैं, जो दो पुनःकनेक्शन के बाद सब ठीक चलते हैं।