सामायिक CA, वेगळे दरवाजे: प्रत्येक प्रवेश फाईलसाठी एक सेवा

सामायिक प्राधिकरणाविरुद्ध सत्यापित होणारे प्रमाणपत्र विश्वासाची चाचणी उत्तीर्ण करते, सदस्यत्वाची नाही. हे दोन निर्णय अनेकदा एकत्र मिसळले जातात कारण दोन्ही जोडणीच्या वेळी घडतात, आणि ज्याचे त्या सेवेवर स्थान नसावे अशा व्यक्तीला प्रवेश मिळेपर्यंत हे मिश्रण अदृश्य राहते. उपाय दुसरे प्राधिकरण नाही; तो दुसरा निर्णय आहे, प्रत्येक सेवेसाठी घेतलेला आणि डेमन जिथे वाचतो तिथे नोंदवलेला. दोन्ही वेगळे ठेवा आणि या क्षेत्रातील बहुतेक गोंधळ नाहीसा होईल.

विश्वासार्ह साखळी सेवा सदस्यत्वाबद्दल काहीही सांगत नाही

दोन सेवा एकच जारी करणारी श्रेणी स्वीकारू शकतात आणि तरीही वेगळी लोकसंख्या असू शकते. एक लॅपटॉप पहिल्यात येतो आणि त्याला दुसऱ्यापर्यंत पोहोचू नये, तर त्याच श्रेणीचे इतर क्लायंट तिथे खरोखर येतात. त्या सेवेतून प्राधिकरण काढले तर ती कायदेशीरपणे वापरणाऱ्या सर्वांना बाहेर ठेवले जाईल, म्हणून काम विश्वास नाही, प्रवेश आहे.

एका दरवाजावर दोन कुलुपे कल्पना करणे उपयुक्त ठरते. प्रमाणपत्र बाहेरील कुलूप उघडते, आणि प्रति-सेवा निर्णय आतील कुलूप उघडतो; कोणतेही दुसऱ्याची जागा घेत नाही. फक्त बाहेरील कुलूप असलेली सेवा सदस्यत्व अजिबात लागू करत नाही, ती फक्त प्रमाणीकरण करते. काहीही बदलण्यापूर्वी दोन्ही निर्णय लिहून ठेवा, कारण केवळ कार्यरत जोडणीच्या स्वरूपात असलेल्या धोरणाचे ऑडिट होऊ शकत नाही. पुढील मजकूर आतील कुलुपाबद्दल आहे.

ऐच्छिक ओव्हरराइडचे प्रवेशद्वार करा

क्लायंट कॉन्फिगरेशन डिरेक्टरी सहसा सोय असते: त्यातील फाईल्स त्या नावाच्या क्लायंटच्या सेटिंग्ज ओव्हरराइड करतात, आणि फाईल नसलेला क्लायंट फक्त सर्व्हरच्या डीफॉल्टसह चालतो. एक निर्देश ती सोय प्रवेशद्वारात बदलतो, त्यामुळे फाईल नसणे म्हणजे जोडणी नाकारली जाते.

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

समुदाय आवृत्ती OpenVPN 2.6 ccd-exclusive आपल्या मॅन्युअल पृष्ठावर नेमकी हीच अट नोंदवते, आणि नामनिर्देशित फाईलचा शोध प्रभावी क्लायंट ओळखीवर अवलंबून असतो. इतर बिल्ड आणि उत्पादन-व्यवस्थापित सर्व्हर वेगळे असू शकतात, म्हणून इतरत्र त्याच अर्थावर अवलंबून राहण्यापूर्वी स्थापित आवृत्तीची खात्री करा.

वरील मार्ग उदाहरण माना आणि मार्गदर्शकाने रचलेली डिरेक्टरी तयार करण्याऐवजी प्रत्यक्षात तैनात केलेली मांडणी तपासा. विद्यमान प्रमाणपत्र तपासण्या, सर्व्हर ओळख तपासण्या आणि खाते प्रमाणीकरण जसे होते तसेच ठेवा, कारण हा तुकडा अट जोडतो आणि काहीही काढत नाही. उत्पादनापूर्वी बदल तयार करा, कारण चुकीच्या ठिकाणी उपस्थित केलेला नकार प्रमाणपत्र बिघाडासारखा दिसतो आणि तपासणी प्राधिकरणाकडे वळवतो. नंतर नाकारलेल्या क्लायंटची लॉग ओळ साखळी नाही, गहाळ कॉन्फिगरेशन फाईलचे नाव देते याची खात्री करा.

प्रत्येक सेवेसाठी एक डिरेक्टरी, एक सामायिक यादी नाही

सदस्यत्व ते लागू करणाऱ्या सेवेचे असते, म्हणून प्रत्येक सेवा स्वतःची डिरेक्टरी आणि स्वतःच्या फाईल्स ठेवते. दोन सेवांना एका यादीकडे वळवल्यास त्या सदस्यत्व सामायिक करतात कोणी तसे हेतूने केले किंवा नाही, आणि परिणामी बदल एखाद्या निर्णयापर्यंत परत आणणे कठीण असते. सामायिक प्राधिकरण सामायिक राहू शकते; प्रवेश फाईल्स राहू शकत नाहीत. त्या वेगळ्या ठेवल्याचा अर्थ असाही की एका सेवेतील चूक दुसरीला शांतपणे रुंदावू शकत नाही.

DEFAULT नोंद हे लोकांना भुलवणारे प्रकरण आहे. नामनिर्देशित फाईल न मिळाल्यास ती पर्यायी सेटिंग्ज देते, पण ती प्रवेशद्वाराची आवश्यक असलेली नामनिर्देशित फाईल नाही, म्हणून ती एकटी क्लायंटला प्रवेश देऊ शकत नाही. अजिबात नोंद नसलेल्या क्लायंटची चाचणी करा आणि नकाराची खात्री करा; जर त्या क्लायंटला प्रवेश मिळाला, तर पर्याय लागू होत आहे आणि ccd-exclusive त्या उदाहरणात लागू नाही.

प्रभावी ओळख कोणती फाईल वाचली जाते हे ठरवते

शोध क्लायंटने प्रत्यक्षात ज्या ओळखीने प्रमाणीकरण केले ती वापरतो, जी सहसा प्रमाणपत्राचे सामान्य नाव असते. जिथे सर्व्हर वापरकर्तानाव आणि संकेतशब्दही तपासतो आणि ते नाव सामान्य नावात मॅप करतो, तिथे फाईलने त्याऐवजी प्रमाणित वापरकर्तानावाशी जुळले पाहिजे. विसंगती डिरेक्टरी विश्वासार्ह फाईलनावांनी भरून सोडते जी कधीही निवडली जात नाहीत.

वाचन हा दुसरा अर्धा भाग आहे. डेमन सहसा सुरू झाल्यानंतर विशेषाधिकार सोडतो, म्हणून कमी केलेल्या खात्याला डिरेक्टरी आणि त्यातील प्रत्येक नोंदीवर वाचन प्रवेश आवश्यक असतो. क्लायंट कोणत्याही लिहिण्यायोग्य मार्गाने स्वतःची नोंद तयार करू शकू नयेत, कारण स्व-सेवा प्रवेश संपूर्ण यंत्रणा निरर्थक करतो. केवळ फाईल मोड नाही, माउंट आणि शेअर परवानग्याही तपासा, कारण एका खात्यासाठी बंद दिसणारी डिरेक्टरी दुसऱ्यासाठी उघडी असू शकते. नंतर चालू असलेली प्रक्रिया प्रत्यक्षात कोणते खाते वापरते याची खात्री करा, unit फाईल कोणत्या खात्याचा उल्लेख करते ते नाही. दोन्ही तेव्हाच समान असतात जेव्हा दुसरे काही त्यांना बदलले नसते.

नकार, प्रवेश आणि रद्दीकरण स्वतंत्रपणे पहा

सेवेतील असलेल्या ओळखीची चाचणी करा आणि ती जोडते याची खात्री करा. नोंद नसलेल्या वैध प्रमाणपत्राची चाचणी करा आणि ते नाकारले जाते याची खात्री करा. दुसऱ्या सेवेत प्रवेश मिळालेल्या ओळखीची चाचणी करा आणि तिला येथे प्रवेश मिळत नाही याची खात्री करा. प्रत्येक निकालाशेजारी सेवा उदाहरण आणि प्रभावी ओळख नोंदवा, कारण या संदर्भाशिवाय निकाल दुसरा कोणीही पुन्हा तयार करू शकत नाही.

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

प्रवेश हे केवळ पहिले प्रवेशद्वार आहे. सेवेत सामील होणे तिच्या मागील सबनेट, डेटाबेस किंवा व्यवस्थापन इंटरफेसबद्दल काहीही सांगत नाही, आणि ते साधन धोरण स्वतंत्रपणे लिहून तपासले पाहिजे.