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 की निजी कुंजी नहीं पढ़ सकता।

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