OpenVPN को CA साइनिङ कुञ्जी /etc/openvpn बाहिर राख्नुहोस्

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

CA को कार्यक्षेत्रमा के हुन्छ

PKI निर्देशिका जारीकर्ताको अवस्था हो, कन्फिगरेसन होइन। यसमा CA को निजी कुञ्जी र प्रमाणपत्र, क्रमसंख्या फाइल, जारी गरिएका प्रमाणपत्रहरूको सूची, र तिनबाट बनेको हरेक पहिचानको सामग्री हुन्छ।

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

सार्वजनिक CA प्रमाणपत्र फरक छ। त्यो वितरणका लागि हो, र ग्राहक तथा सर्भरले एकअर्कालाई जाँच्न त्यही प्रयोग गर्छन्।

डेमन सुरु हुँदा के पढ्छ

चलिरहेको सर्भरले थोरै समूह उपभोग गर्छ: आफ्नै प्रमाणपत्र, आफ्नै निजी कुञ्जी, साथीहरू जाँच्न CA प्रमाणपत्र, र छानिएको विधिले माग्ने कुञ्जी सामग्री। यी बाटाहरू सुरुमा र फेरि रिलोडमा पढ्छ।

स्वामित्व वास्तवमा सुरु हुने युनिटको तुलनामा मूल्याङ्कन गर्नुपर्छ, इन्टरएक्टिभ root शेलको तुलनामा होइन। घोषित स्यान्डबक्सिङले फाइल प्रणालीको भाग पढ्न-मात्र वा अदृश्य बनाउन सक्छ, root का रूपमा हातले गरेको परीक्षण सफल भए पनि।

systemctl show -p User -p Group -p ReadOnlyPaths [email protected]
stat -c '%a %U:%G' /etc/openvpn/server/server.key
runuser -u openvpn -- test -r /etc/openvpn/server/server.key; echo $?

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

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

CA कुञ्जी सर्भरमा प्रतिलिपि गर्दा पछि किन विफल हुन्छ

प्रतिलिपि सामान्यतया डिबगिङको कदमका रूपमा सुरु हुन्छ: कसैले VPN होस्टमा ग्राहक नवीकरण गर्न चाहन्छ, त्यसैले CA कुञ्जी /etc/openvpn मा पुग्छ र नवीकरण चल्छ। तत्काल काम सफल हुन्छ, र सीमा हराउँछ।

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

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

खाता, निर्देशिका, ब्याकअप

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

रद्द गरेपछि सर्भर कन्फिगरेसनले नाम दिने CRL फाइल अद्यावधिक गर्नुहोस्, त्यसपछि नयाँ जडानहरूले त्यो पढ्न सेवा रिलोड गर्नुहोस्। Easy-RSA कागजात ले कार्यक्षेत्रको लेआउट र हस्ताक्षर प्रवाह समेट्छ; त्यसको वरिपरिका स्वामित्व नियम तपाईंको होस्टको निर्णय नै रहन्छ। सेवाले के लोड गर्यो भनी openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate बाट पुष्टि गर्नुहोस्, रिलोडले त्यो लियो भनी मान्नुको सट्टा।

विभाजन प्रमाणित गर्ने परीक्षण

काम गर्ने अवस्था मात्र होइन, नकारात्मक अवस्था पनि जाँच्नुहोस्। ढाँचाअनुसार जारीकर्ता खाताबाट प्रमाणपत्रमा हस्ताक्षर गर्नुहोस्, त्यसपछि त्यही खाताले सेवा सुरु गर्न वा सर्भरको निजी कुञ्जी पढ्न नसक्ने पुष्टि गर्नुहोस्। त्यसपछि डेमनको खाताले CA को निजी कुञ्जी पढ्न नसक्ने पुष्टि गर्नुहोस्।

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