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 ची खाजगी किल्ली वाचू शकत नाही याची पुष्टी करा।

या तीन तपासण्या काही मिनिटे घेतात आणि कर्मचारी बदलल्यावरही टिकतात, कारण त्या सवयीबद्दल नाही तर परवानग्यांबद्दलची विधाने आहेत। निकाल त्याने व्यापलेल्या मार्गांसह आणि खात्यांसह, आणि त्या चालवल्याच्या तारखेसह लिहा। नाहीतर ही तैनाती वारसा म्हणून मिळणारा पुढचा माणूस जिथे सीमाच कधी नव्हती अशा ट्युटोरियलमधून सीमा पुन्हा काढेल। तारखेची नोंद हीच पुढच्या आढाव्याला दुपारऐवजी काही मिनिटांचा बनवते।