साझा CA, अलग दरवाज़े: प्रति प्रवेश फ़ाइल एक सेवा

साझा प्राधिकरण के विरुद्ध सत्यापित होने वाला प्रमाणपत्र विश्वास की परीक्षा पास करता है, सदस्यता की परीक्षा नहीं। ये दोनों निर्णय अक्सर एक साथ मिला दिए जाते हैं क्योंकि दोनों कनेक्शन के समय होते हैं, और यह मिलावट तब तक अदृश्य रहती है जब तक किसी ऐसे व्यक्ति को सेवा में प्रवेश न दिया जाए जिसे वहाँ नहीं होना चाहिए। समाधान दूसरा प्राधिकरण नहीं है; यह दूसरा निर्णय है, प्रति सेवा लिया गया और वहीं दर्ज किया गया जहाँ डेमन उसे पढ़ता है। दोनों को अलग रखिए और इस क्षेत्र की अधिकांश उलझन गायब हो जाती है।

भरोसेमंद श्रृंखला सेवा सदस्यता के बारे में कुछ नहीं कहती

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

एक दरवाज़े पर दो ताले कल्पना करना मदद करता है। प्रमाणपत्र बाहरी ताला खोलता है, और प्रति-सेवा निर्णय भीतरी ताला खोलता है; कोई भी दूसरे का स्थान नहीं लेता। केवल बाहरी ताले वाली सेवा सदस्यता लागू ही नहीं करती, वह केवल प्रमाणीकरण करती है। कुछ भी बदलने से पहले दोनों निर्णय लिखिए, क्योंकि केवल काम करते कनेक्शन के रूप में मौजूद नीति का ऑडिट नहीं किया जा सकता। आगे की बात भीतरी ताले के बारे में है।

वैकल्पिक ओवरराइड को प्रवेश द्वार बनाइए

क्लाइंट कॉन्फ़िगरेशन निर्देशिका आम तौर पर सुविधा है: उसमें रखी फ़ाइलें उन क्लाइंट की सेटिंग्स ओवरराइड करती हैं जिनके नाम वे लेती हैं, और बिना फ़ाइल वाला क्लाइंट केवल सर्वर की डिफ़ॉल्ट सेटिंग्स के साथ चलता है। एक निर्देश उस सुविधा को द्वार में बदल देता है, जिससे फ़ाइल का न होना कनेक्शन के अस्वीकार होने का अर्थ है।

client-config-dir /etc/openvpn/service-a/clients
ccd-exclusive

समुदाय संस्करण OpenVPN 2.6 ccd-exclusive अपने मैनुअल पृष्ठ में ठीक इसी शर्त का दस्तावेज़ीकरण करता है, और नामित फ़ाइल की खोज प्रभावी क्लाइंट पहचान पर निर्भर करती है। अन्य बिल्ड और उत्पाद-प्रबंधित सर्वर भिन्न हो सकते हैं, इसलिए कहीं और उसी अर्थ पर निर्भर होने से पहले स्थापित संस्करण की पुष्टि करें।

ऊपर के पथ को उदाहरण मानिए और किसी मार्गदर्शिका द्वारा गढ़ी गई निर्देशिका बनाने के बजाय तैनात लेआउट जाँचिए। मौजूदा प्रमाणपत्र जाँच, सर्वर पहचान जाँच और खाता प्रमाणीकरण को ठीक वैसा ही रहने दीजिए, क्योंकि यह अंश एक शर्त जोड़ता है और कुछ हटाता नहीं। उत्पादन से पहले बदलाव तैयार कीजिए, क्योंकि गलत जगह उठाया गया अस्वीकार प्रमाणपत्र विफलता जैसा दिखता है और जाँच को प्राधिकरण की ओर भेजता है। बाद में पुष्टि कीजिए कि अस्वीकृत क्लाइंट की लॉग पंक्ति श्रृंखला नहीं, गुम कॉन्फ़िगरेशन फ़ाइल का नाम लेती है।

प्रति सेवा एक निर्देशिका, एक साझा सूची नहीं

सदस्यता उस सेवा की है जो उसे लागू करती है, इसलिए हर सेवा अपनी निर्देशिका और अपनी फ़ाइलें रखती है। दो सेवाओं को एक सूची की ओर इंगित करना उन्हें सदस्यता साझा करा देता है चाहे किसी ने इसका इरादा किया हो या नहीं, और परिणामी बदलाव को किसी निर्णय तक वापस खींचना कठिन है। साझा प्राधिकरण साझा रह सकता है; प्रवेश फ़ाइलें नहीं। इन्हें अलग रखने का अर्थ यह भी है कि एक सेवा की गलती दूसरी को चुपचाप नहीं बढ़ा सकती।

DEFAULT प्रविष्टि वह मामला है जो लोगों को भ्रमित करता है। नामित फ़ाइल न मिलने पर यह फ़ॉलबैक सेटिंग्स देती है, पर यह वह नामित फ़ाइल नहीं है जिसकी द्वार मांग करता है, इसलिए यह अकेले किसी क्लाइंट को प्रवेश नहीं दे सकती। ऐसे क्लाइंट की जाँच कीजिए जिसकी कोई प्रविष्टि ही नहीं है और अस्वीकार की पुष्टि कीजिए; यदि वह क्लाइंट प्रवेश पाता है, तो फ़ॉलबैक लागू हो रहा है और ccd-exclusive उस उदाहरण में लागू नहीं है।

प्रभावी पहचान तय करती है कौन-सी फ़ाइल पढ़ी जाती है

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

पढ़ना दूसरा आधा है। डेमन सामान्यतः शुरू होने के बाद विशेषाधिकार छोड़ देता है, इसलिए घटाए गए खाते को निर्देशिका और उसकी हर प्रविष्टि पर पढ़ने की पहुँच चाहिए। क्लाइंट किसी भी लिखने योग्य पथ से अपनी प्रविष्टि नहीं बना सकें, क्योंकि स्व-सेवा प्रवेश पूरी व्यवस्था को विफल कर देता है। केवल फ़ाइल मोड नहीं, माउंट और शेयर अनुमतियाँ भी जाँचिए, क्योंकि एक खाते के लिए बंद दिखने वाली निर्देशिका दूसरे के लिए खुली हो सकती है। फिर पुष्टि कीजिए कि चल रही प्रक्रिया वास्तव में कौन-सा खाता उपयोग करती है, यह नहीं कि unit फ़ाइल किस खाते का उल्लेख करती है। दोनों तभी समान होते हैं जब और किसी चीज़ ने उन्हें न बदला हो।

अस्वीकार, प्रवेश और निरसन को अलग-अलग देखिए

सेवा में आने वाली पहचान आज़माइए और पुष्टि कीजिए कि वह जुड़ती है। बिना प्रविष्टि वाला वैध प्रमाणपत्र आज़माइए और पुष्टि कीजिए कि वह अस्वीकार होता है। दूसरी सेवा में प्रवेश पाई पहचान आज़माइए और पुष्टि कीजिए कि वह यहाँ प्रवेश नहीं पाती। हर परिणाम के साथ सेवा का उदाहरण और प्रभावी पहचान दर्ज कीजिए, क्योंकि इस संदर्भ के बिना परिणाम कोई और दोहरा नहीं सकता।

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

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