सञ्चालन निर्देशिका: दुई 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 को लिसनरले अस्वीकार गर्छ। यही सीमा हो, परीक्षणका रूपमा व्यक्त।