सेटअप स्क्रिप्ट चलेपछि 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 वा रिलिज लेख्नुहोस् र त्यसको प्रतिलिपि राख्नुहोस्। त्यो एउटै बानीले जिम्मा लगाउन नसकिने अवस्थालाई दोस्रो व्यक्तिले राति दुई बजे सोच्न सक्ने कुरामा बदल्छ।

स्क्रिप्टले दिन नसक्ने कुरा

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

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

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

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

तपाईंले चाहेको संयोजन अब समर्थित छैन भने, स्थापनाअघि मर्मत गरिएको मार्ग छान्नुहोस्। पुरानो रिलिज पुनर्जीवित गर्नु, प्रमाणीकरण कमजोर बनाउनु वा नबुझाइएको स्क्रिप्ट पुनः चलाउनु मर्मत योजना होइन, ढिलाइ हो, र प्रत्येकले हस्तान्तरण कठिन बनाउँछ।

हस्तान्तरण पृष्ठ लेख्नुहोस्

यसलाई छोटो राख्नुहोस्: सर्भर, त्यो बनाउने संस्करण, आवश्यक पोर्ट, घटक र तिनका अपडेट मालिक, अनुमति दिइएका स्रोत, प्रमाणपत्र मार्ग र पुनर्प्राप्ति प्रक्रिया। टनेलको परिवर्तनले पहुँच तोडेको बेला प्रयोग गर्ने कन्सोल वा ब्यान्डबाहिरको मार्ग थप्नुहोस्। तब अर्को व्यक्तिले दुई पटक चलाउन डराउने आदेश होइन, सेवा उत्तराधिकारमा पाउँछ।

होस्ट फेरिएपछि त्यो पृष्ठ समीक्षा गर्नुहोस्, केही बिग्रिएपछि मात्र होइन। कहिल्यै नपढिएको हस्तान्तरण कागजात त्यस्तो कागजात हो जो चुपचाप सत्य हुन छोड्यो।