साझा CA, छुट्टै ढोका: प्रवेश फाइल प्रति एक सेवा

साझा अधिकारको विरुद्ध प्रमाणित हुने प्रमाणपत्रले विश्वासको परीक्षा पास गरेको हुन्छ, सदस्यताको होइन। यी दुई निर्णय प्रायः एकै ठाउँमा मिसाइन्छन् किनभने दुवै जडानको समयमा हुन्छन्, र त्यो मिसावट तबसम्म अदृश्य रहन्छ जबसम्म कुनै सेवामा नहुनुपर्ने व्यक्तिलाई त्यहाँ प्रवेश दिइँदैन। समाधान दोस्रो अधिकार होइन; यो दोस्रो निर्णय हो, प्रत्येक सेवाका लागि लिइएको र डेमनले पढ्ने ठाउँमै अभिलेख गरिएको। दुवैलाई अलग राख्नुहोस्, यस क्षेत्रको अधिकांश अन्योल हराउँछ।

विश्वसनीय शृंखलाले सेवा सदस्यताबारे केही भन्दैन

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

एउटै ढोकामा दुई ताला कल्पना गर्न सहयोग पुग्छ। प्रमाणपत्रले बाहिरी ताला खोल्छ, र प्रति-सेवा निर्णयले भित्री ताला खोल्छ; कुनैले पनि अर्कोको ठाउँ लिँदैन। बाहिरी ताला मात्र भएको सेवाले सदस्यता नै लागू गर्दैन, त्यो केवल प्रमाणीकरण गर्छ। केही बदल्नु अघि दुवै निर्णय लेख्नुहोस्, किनभने कार्यरत जडानको रूपमा मात्र रहेको नीतिको अडिट गर्न सकिँदैन। अबको कुरा भित्री तालाबारे हो।

वैकल्पिक ओभरराइडहरूलाई प्रवेशद्वार बनाउनुहोस्

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

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

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

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

प्रत्येक सेवाका लागि एउटा डाइरेक्टरी, एउटै साझा सूची होइन

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

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

प्रभावकारी पहिचानले कुन फाइल पढिन्छ भनी निर्धारण गर्छ

खोजले क्लाइन्टले साँच्चै प्रमाणित गरेको पहिचान प्रयोग गर्छ, जो सामान्यतया प्रमाणपत्रको सामान्य नाम हो। जहाँ सर्भरले प्रयोगकर्ता नाम र पासवर्ड पनि जाँच्छ र त्यो नामलाई सामान्य नाममा म्याप गर्छ, त्यहाँ फाइलले सट्टामा प्रमाणित प्रयोगकर्ता नामसँग मेल खानुपर्छ। बेमेल हुँदा डाइरेक्टरी विश्वसनीय फाइल नामहरूले भरिन्छ जो कहिल्यै छानिँदैनन्।

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

अस्वीकार, प्रवेश र रद्दीकरण छुट्टाछुट्टै अवलोकन गर्नुहोस्

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

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

प्रवेश पहिलो द्वार मात्र पनि हो। कुनै सेवामा सामेल हुनुले त्यसपछाडिका सबनेट, डेटाबेस वा व्यवस्थापन इन्टरफेसबारे केही भन्दैन, र त्यो स्रोत नीति छुट्टै लेखेर परीक्षण गर्नुपर्छ।