सेटअप स्क्रिप्ट चलने के बाद VPN सर्वर का मालिक कोई होना चाहिए

दो अलग काम एक जैसे बेचे जाते हैं: किसी मशीन को VPN सर्वर बनाना, और ऐसे लैपटॉप में VPN क्लाइंट जोड़ना जिसे किसी और के गेटवे से जुड़ना है। सेटअप स्क्रिप्ट पहले का जवाब देती है और दूसरे का नहीं दे सकती, उसका README जो भी कहे। setup-ipsec-vpn परियोजना को ठोस उदाहरण मानें: यह समर्थित Linux होस्ट पर Libreswan और xl2tpd से IPsec/L2TP, Cisco IPsec या IKEv2 सर्वर बनाती है। यह सर्वर के लिए परिनियोजन अनुबंध है, किसी भी मशीन के लिए सामान्य विधि नहीं। स्क्रिप्ट चलने से पहले तय करें कि आपका काम कौन सा है, क्योंकि इसके बाद सब कुछ सर्वर के बारे में है।

होस्ट के बारे में ईमानदार रहें

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

सेवा सक्षम करने से उसका रास्ता नहीं खुलता। IPsec के लिए होस्ट के आगे का नेटवर्क UDP 500 और 4500 को अनुमति दे और परिनियोजन के अनुसार ESP प्रोटोकॉल भी। जो स्क्रिप्ट प्रोटोकॉल 50 गिराने वाले सुरक्षा समूह के पीछे सफल होती है, उसने ऐसा सर्वर बनाया है जहाँ कोई नहीं पहुँच सकता, और इंस्टॉलर के आउटपुट में कुछ भी यह नहीं कहेगा।

इंस्टॉलर वास्तव में क्या लेता है

IPsec कॉन्फ़िगरेशन और गुप्त फ़ाइल, L2TP डेमॉन कॉन्फ़िगरेशन, PPP विकल्प और अब उन पोर्टों के मालिक systemd यूनिट की अपेक्षा करें। प्रोजेक्ट का README कहता है कि मौजूदा कॉन्फ़िगरेशन फ़ाइलों का बदलाव से पहले बैकअप लिया जाता है, जो उपयोगी है और होस्ट बैकअप के समान नहीं है। तय करें कि कौन से घटक डिस्ट्रिब्यूशन के पैकेज से अपडेट होंगे और कौन से स्क्रिप्ट दोबारा चलाकर या फिर से लिखकर, क्योंकि ये अलग विफलता विधियों वाले दो रखरखाव मार्ग हैं।

जिस रिवीज़न को आपने स्वीकृत किया उसे पिन करें। मौजूदा डिफ़ॉल्ट शाखा देने वाला डाउनलोड URL अगले महीने अलग सामग्री लौटा सकता है, इसलिए जो commit या रिलीज़ आपने चलाया उसे दर्ज करें और उसकी प्रति रखें। यही एक आदत न-जिम्मेदार ठहराई जा सकने वाली स्थिति को ऐसी चीज़ में बदल देती है जिस पर दूसरा व्यक्ति रात दो बजे सोच सके।

स्वचालन क्या नहीं दे सकता

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

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

पहला क्लाइंट ही स्वीकृति परीक्षण है

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

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

हैंडऑफ पृष्ठ लिखें

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

जब होस्ट बदले तब उस पृष्ठ की समीक्षा करें, केवल तब नहीं जब कुछ टूटे। जिस हैंडऑफ दस्तावेज़ को कभी पढ़ा नहीं जाता वह ऐसा दस्तावेज़ है जो चुपचाप सही होना बंद कर चुका है।