रनबुक: दो 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 के लिसनर द्वारा अस्वीकार कर दिया जाता है। यही सीमा है, परीक्षण के रूप में व्यक्त।