त्रुटि पर रुकने वाले चरणों के साथ OpenVPN क्लाइंट का प्रावधान

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

पूरे मामले को पाँच जाँच-बिंदुओं वाला एक लेन-देन मानें, और हर जाँच-बिंदु को अपने आप आगे बढ़ने से इंकार करने दें।

फ़ाइल सिस्टम छूने से पहले इनपुट ठीक करें

स्पष्ट अनुबंध से शुरू करें: एक पहचान, एक प्रोफ़ाइल स्रोत, एक इच्छित सेवा स्वामी। जाँचें कि प्रोफ़ाइल मौजूद है, कि जिन प्रमाणपत्र और कुंजी का वह हवाला देता है वे पठनीय हैं, और लक्ष्य निर्देशिका अपेक्षित पैकेज की है। जो पथ हल हो जाता है वह इस बात का प्रमाण नहीं कि उसके पीछे की सामग्री पूरी है।

खाली चर जल्दी अस्वीकार करें। अनसेट $DEVICE जो किसी चीज़ में नहीं फैलता, install -m 400 $KEY /etc/openvpn/client/ को निर्देशिका की ओर लक्षित प्रतिलिपि बना देता है, और विफलता बाद में ऐसी सेवा के रूप में आती है जो अपनी कुंजी नहीं पढ़ सकती।

प्रोफ़ाइल सेट को स्टेजिंग निर्देशिका में जोड़ें

पहले पूरा सेट किसी निजी स्थान पर बनाएँ: प्रोफ़ाइल, CA, क्लाइंट प्रमाणपत्र, कुंजी और कोई भी सहायक जिसे प्रोफ़ाइल पुकारता है। install -m 400 -o root -g root से प्रतिलिपि करें ताकि अनुमतियाँ बाद में नहीं, बनाते समय तय हों। फिर प्रोफ़ाइल के भीतर के संदर्भ जाँचें, क्योंकि सापेक्ष ca या key पंक्ति सेवा शुरू होते ही यूनिट की कार्य निर्देशिका के सापेक्ष हल होती है। पूरा सेट मान्य होने तक जीवित निर्देशिका में कुछ नहीं लिखा जाना चाहिए।

इस रन ने क्या बनाया, उसकी गैर-गोपनीय फ़िंगरप्रिंट दर्ज करें, उदाहरण के लिए संस्करण चिह्न के पास रखा sha256sum office.conf। यही एक मान पुनः-रन को अद्यतन और कुछ न करने में अंतर करने देता है।

परमाणु रूप से बदलें और पिछला सेट रखें

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

जब लक्ष्य पहले से मौजूद हो, तो स्पष्ट रूप से तय करें कि यह रन अद्यतन है, बिल्कुल वही पुनः-रन है, या किसी दूसरे उपकरण की प्रोफ़ाइल से टकराव है। दूसरी पहचान की प्रोफ़ाइल को चुपचाप ऊपर लिखना ही वह रास्ता है जिससे दो मशीनें एक ही प्रमाणपत्र साझा करने लगती हैं। इसके बजाय रन अस्वीकार करें और टकराव वाले स्वामी का नाम लें।

एक स्वामी सक्रिय करें और उसे सिद्ध करें

एक सक्रियण पथ चुनें, या तो systemd इंस्टेंस या NetworkManager, और उसे लगातार इस्तेमाल करें। सक्रिय यूनिट के बगल में अप्रबंधित openvpn प्रक्रिया शुरू करने से दो टनल, प्रतिस्पर्धी DNS अद्यतन और इस बात का स्पष्ट उत्तर नहीं मिलता कि स्टॉप आदेश किसे लक्ष्य करता है। सक्रिय करने के बाद systemctl is-active openvpn-client@office जाँचें, फिर दूरस्थ प्रीफ़िक्स का रूट, फिर टनल द्वारा स्थापित रिज़ॉल्वर के लिए resolvectl status। टनल जिस एक संसाधन के लिए है, उस तक पहुँचकर समाप्त करें।

चलती प्रक्रिया और हरा ट्रे आइकन प्रक्रिया के तथ्य हैं, इस बात का प्रमाण नहीं कि पहचान और ट्रैफ़िक नीति हैंडऑफ़ से बच गईं।

पुनः-रन और सेवानिवृत्ति अलग-अलग वर्कफ़्लो हैं

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

ऐसा पुनर्प्राप्ति पथ रखें जो टनल पर निर्भर न हो, जैसे कंसोल पहुँच या दूसरा प्रबंधन मार्ग। जो प्रावधान परिवर्तन आपको मशीन से बाहर ताला लगा दे, वह विफल परिवर्तन है, भले ही हर चरण ने सफलता बताई हो।

रखने योग्य स्क्रिप्ट स्वामित्व और प्रमाण के आसपास का लेन-देन है। विशेषाधिकार प्राप्त प्रतिलिपि आदेशों की छोटी सूची वही चीज़ नहीं है।