सेटअप स्क्रिप्ट चालल्यानंतर 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 किंवा आवृत्ती नोंदवा आणि त्याची प्रत ठेवा. ती एक सवय जबाबदारी न देता येणारी स्थिती अशा गोष्टीत बदलते ज्याचा दुसरा माणूस रात्री दोन वाजता विचार करू शकतो.

स्क्रिप्ट काय देऊ शकत नाही

स्वयंचलन कार्यरत स्थापना तयार करते आणि तिथे थांबते. टनेलने कोणत्या खाजगी संसाधनांपर्यंत पोहोचावे हे ते ठरवत नाही, हा प्रवेश धोरणाचा प्रश्न आहे आणि त्याबद्दल होस्ट फायरवॉल आणि वरील नेटवर्क दोघांचेही मत आहे. कोणाला क्रेडेन्शियल मिळतात, ते कसे दिले जातात, किंवा कोणी गेल्यावर त्याचा प्रवेश कसा काढला जातो हेही ते ठरवत नाही. आणि वाईट अपडेटनंतर मशीन कशी पुनर्संचयित होते हेही ठरवत नाही, जो भाग सहसा सर्वात वाईट क्षणी उघड होतो.

क्लायंट प्रोफाइल आणि दाखवलेली गुपिते ही प्रवेश सामग्री आहेत, स्थापना नोंदी नाहीत. सामायिक चॅनेलमध्ये पेस्ट केलेले तयार केलेले प्रोफाइल हे खाते आहे, आणि तेच मानक सेटअप सारांशाच्या स्क्रीनशॉटला लागू होते. सेवा पुनर्संचयित करण्यासाठी आवश्यक ओळख स्थितीची संरक्षित यादी ठेवा, आणि त्यातील कोणती क्रेडेन्शियल त्यानंतर रद्द झाली ते नोंदवा.

पहिला क्लायंट हीच स्वीकृती चाचणी

तुम्ही प्रत्यक्षात सक्षम केलेल्या प्रोटोकॉलने, एका अधिकृत क्लायंटकडून तैनाती स्वीकारा. खाजगी नाव सुटते का, परतीचा मार्ग चालतो का, पुन्हा जोडणी योग्य वागते का, आणि परवानगी असलेल्या संचाबाहेरचे गंतव्य नाकारले जाते का ते तपासा. दुसऱ्या क्लायंट अ‍ॅपमधून यशस्वी लॉगिन हा तुम्ही पाठवलेल्या अ‍ॅपचा पुरावा नाही.

तुम्हाला हवे असलेले संयोजन आता समर्थित नसल्यास, स्थापनेपूर्वी देखभाल केलेला मार्ग निवडा. जुनी आवृत्ती पुनरुज्जीवित करणे, प्रमाणीकरण कमकुवत करणे किंवा न समजावलेली स्क्रिप्ट पुन्हा चालवणे हे देखभाल योजना नव्हे तर पुढे ढकलणे आहे, आणि प्रत्येकजण हस्तांतरण कठीण करते.

हस्तांतरण पृष्ठ लिहा

हे छोटे ठेवा: सर्व्हर, तो बनवणारी आवृत्ती, आवश्यक पोर्ट, घटक आणि त्यांचे अपडेट मालक, परवानगी असलेली संसाधने, क्रेडेन्शियल मार्ग आणि पुनर्प्राप्ती प्रक्रिया. टनेलमधील बदलामुळे प्रवेश तुटला तेव्हा वापरण्याचा कन्सोल किंवा बँडबाहेरचा मार्ग जोडा. मग पुढचा माणूस दोनदा चालवायला घाबरणारा आदेश नव्हे तर सेवा वारसाहक्काने घेतो.

होस्ट बदलल्यावर ते पान पुनरावलोकन करा, केवळ काही तुटल्यावर नाही. कधीही न वाचलेला हस्तांतरण दस्तऐवज हा असा दस्तऐवज आहे जो गुपचूप खरा राहणे थांबला.