रनबुक: दोन OpenVPN ग्राहक स्वतंत्रपणे ऑनबोर्ड करणे

एका होस्टवर दोन ग्राहक म्हणजे अजून एक सर्व्हर ब्लॉक आणि दुसरा पोर्ट असे वाटते। ग्राहकाकडे प्रत्यक्षात जे काही आहे ते सर्व सूचीबद्ध केल्यावर हे वेगळा प्रकल्प बनते: लिसनर, टनेल पूल, ओळख, विश्वास फाइल्स, मार्ग आणि रद्दीकरणाचे वेळापत्रक। यापैकी एकही वगळले तर दुसरा ग्राहक पहिल्याचा एक भाग शांतपणे वारसाने घेतो। प्रत्येक ग्राहकासाठी कार्ड तयार करा आणि पहिला क्लायंट जोडण्यापूर्वी ते भरा।

प्रत्येक ग्राहकासाठी पूर्ण संसाधन कार्ड नियुक्त करा

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

कार्ड कॉन्फिगरेशनजवळ ठेवा आणि मूल्य बदलल्यावर ते अद्ययावत करा। वास्तवापासून दूर जाणारे दस्तऐवजीकरण नसण्यापेक्षा वाईट आहे।

विश्वास सामग्री प्रत्येक ग्राहकाच्या आत ठेवा

प्रत्येक ग्राहकासाठी स्वतंत्र जारीकर्ता प्राधिकरण सीमा समजणे सोपे करते आणि स्वाक्षरी की इंटरनेटसमोर उघड असलेल्या होस्टपासून दूर ठेवते। सामायिक रूट देखील कार्य करू शकतो, परंतु सामायिक अँकर दोन सेवांचे एक सदस्यत्व डोमेन करत नाही। प्रत्येक लिसनर कोणत्या साखळ्या स्वीकारतो आणि कोणत्या क्लायंट ओळखींना अधिकृत करतो ते ठरवा, नंतर दोन्ही लिहा। काही जोडले जाईपर्यंत प्रयत्न आणि चुकांनी साखळीतून प्रमाणपत्रे काढू नका।

सर्व्हरची स्वतःची खाजगी की प्रत्येक ग्राहकासाठी संरक्षित फाइलमध्ये असावी, कॉन्फिगरेशनसह प्रतिकृत होणाऱ्या टेम्पलेट डिरेक्टरीमध्ये नाही।

प्रक्रियांप्रमाणेच नेटवर्कही वेगळे करा

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

ss -lunp | grep -E '1194|1195'
openssl verify -CAfile customer-a/ca.crt customer-a/client.pem

लिसनर तपासणी दाखवते की कोणती प्रक्रिया प्रत्येक सार्वजनिक पोर्टची मालक आहे, आणि पडताळणी दाखवते की क्लायंट प्रमाणपत्र इच्छित अँकरशी साखळत आहे का। कोणतेही आउटपुट हे सिद्ध करत नाही की A चा क्लायंट B च्या सबनेटपर्यंत पोहोचू शकत नाही, म्हणून स्रोत आणि गंतव्य धोरण, परतीचे मार्ग आणि जाणीवपूर्वक सामायिक केलेली कोणतीही सेवा परिभाषित करा। नेटवर्क नेमस्पेस किंवा कंटेनर राउटिंग संदर्भ वेगळे करतात आणि अपघाती मिसळणे कमी करतात, परंतु ते पूर्ण भाडेकरू सीमा नाहीत स्वतःहून। धोक्याचे मॉडेल मागत असल्यास अधिक मजबूत अलगीकरण यंत्रणा निवडा।

हस्तांतरणापूर्वी रद्दीकरण पोहोचवा

रद्दीकरणाला वितरण मार्ग नसेपर्यंत प्रमाणपत्र तैनाती अपूर्ण आहे। ऑनबोर्डिंगचा भाग म्हणून CRL चा जारीकर्ता आणि वैधता कालावधी तपासा।

openssl crl -in customer-a/crl.pem -noout -lastupdate -nextupdate
systemctl status openvpn@customer-a

CRL तपासणी सांगते की यादी कधी जारी झाली आणि कधी संपेल, आणि सेवा स्थिती पुष्टी करते की ती वाचणारे उदाहरण चालू आहे। नवीन काहीही रद्द न झाले तरी जारीकरण धोरणाच्या वेळापत्रकानुसार यादी ताजी करा, कारण कालबाह्य CRL प्रत्येक क्लायंटला नाकारू शकते। वाचकांना अपूर्ण लेखन भेटू नये म्हणून संपूर्ण फाइल प्रकाशित करा, आणि तैनातीपूर्वी स्वाक्षरीची पडताळणी करा। जारीकरण, अंतबिंदू संचालन आणि निवृत्तीची मालकी कोणाकडे आहे ते नोंदवा, जेणेकरून ग्राहक A बंद केल्याने B ला अडथळा होणार नाही।

मग स्वीकृती जोडी चालवा: परवानगी असलेला क्लायंट आपल्या सेवेपर्यंत पोहोचतो, आणि A चे क्रेडेन्शियल B च्या लिसनरकडून नाकारले जाते। हीच सीमा, चाचणी म्हणून व्यक्त।