अधिकार कमी केल्यानंतर: कोणत्या OpenVPN फाइल्स अजूनही काम करतात?
कमी करण्यापूर्वी उघडलेले डिस्क्रिप्टर काम करत राहतात; नंतर पुन्हा उघडले जाणारे मार्ग करत नाहीत. तुमच्या सेटअपला तीन रनटाइम फाइल्सपैकी कोणती पुन्हा उघडायची आहे हे ठरवा.
लांब अपटाइम फक्त हे सिद्ध करतो की त्या क्षणी डेमनकडे असलेल्या अधिकारांसह सुरुवात यशस्वी झाली. येथे महत्त्वाचे अपयश नंतर येतात: नवीन क्लायंट जोडतो, रद्दीकरण यादी बदलली जाते, सहाय्यक स्क्रिप्टला फाइल लिहायची असते. यापैकी प्रत्येक अधिकार नसलेल्या खात्याने केलेले नवीन उघडणे आहे, त्याच्या स्वतःच्या परवानगीच्या प्रश्नासह आणि स्वतःच्या त्रुटी संदेशासह. तीन निर्णय काम करत राहणाऱ्या कॉन्फिगरेशनला पुढील घटनेत अपयशी होणाऱ्यापासून वेगळे करतात.
लवकर लोड झालेले आणि नंतर उघडले जाणारे वेगळे करा
डिस्क्रिप्टर म्हणजे उघड्या फाइल वर्णनावरील हँडल, आणि प्रवेश पद्धत ते वर्णन तयार झाल्यावर ठरली होती. नंतर प्रक्रियेचा वापरकर्ता बदलल्याने हँडल बंद होत नाही, म्हणूनच root म्हणून वाचलेली की फाइल कमी केल्यानंतरही काम करते. पद्धतही बदलत नाही: वाचनासाठी उघडलेले हँडल लिहिण्यायोग्य होत नाही, आणि लिहिण्यायोग्य हँडल खात्याने मार्गावरील हक्क गमावल्यामुळेच मागे घेतले जात नाही. या दोन तथ्यांमुळे या अहवालांतील बहुतेक आश्चर्यकारक वर्तन स्पष्ट होते.
दुसरा अर्धा भाग स्मृति आहे. डेमन प्रमाणपत्राचे विश्लेषण करू शकतो, विश्लेषित सामग्री ठेवू शकतो आणि फाइल बंद करू शकतो; वापरात राहणारा भाग म्हणजे डेटा, उघडी फाइल नाही. त्यामुळे सुरू असलेला रहदारी डिस्क्रिप्टर उघडा आहे किंवा मार्गाचे नाव पोहोचण्यायोग्य आहे हे सिद्ध करत नाही. तो फक्त हे सिद्ध करतो की सध्याच्या सत्रासाठी आवश्यक सामग्री आधी मिळाली होती.
नंतरचे उघडणे हा वेगळा व्यवहार आहे. ते सध्याच्या क्रेडेन्शियल्स, सध्याच्या सुरक्षा संदर्भ आणि सध्याच्या माउंट दृश्याखाली चालते, त्यामुळे सुरुवातीला वाचनीय असलेला मार्ग पुढील कनेक्शनला नाकारला जाऊ शकतो. फिरणे एक सापळा जोडते: त्याच मार्ग नावावर नवीन फाइल लिहिल्याने विद्यमान डिस्क्रिप्टर जुन्या ऑब्जेक्टशी जोडलेले राहते, त्यामुळे पुन्हा लोड होणे यशस्वी दिसू शकते, पण डेमन अजूनही मागील सामग्री वापरत असतो. फिरणे अंमलात आले असे मानण्यापूर्वी प्रक्रियेकडील inode ची डिस्कवरील inode शी तुलना करा.
तीन रनटाइम वाचनांची आणि प्रत्येक कधी होते याची नावे द्या
तीन संसाधने सामान्यतः आरंभानंतर खूप नंतर उघडली जातात, आणि ती वेगवेगळ्या क्षणी अपयशी होतात. विशिष्ट क्लायंटची कॉन्फिगरेशन फाइल तो क्लायंट जोडतो तेव्हा वाचली जाते, त्यामुळे इतर चालू असताना एका वापरकर्त्यासाठी ती तुटू शकते. रद्दीकरण डेटा सहकारी प्रमाणीकरणाच्या वेळी आणि फाइल बदलल्यावर पुन्हा पाहिला जातो. तात्पुरत्या डिरेक्टरीला स्क्रिप्ट किंवा प्लगइन काही लिहिते तेव्हाच हात लावला जातो.
तीनपैकी कोणतेही आरंभ मार्गाचे नाही, त्यामुळे आठवडे निरोगी असलेला सर्व्हर पुढील कनेक्शनला अपयशी होऊ शकतो. श्रेणी दुरुस्तीच्या मालकाचेही नाव घेते: पहिले दोन डेमन खात्याखालील कॉन्फिगरेशनवरील वाचन परवानग्या आहेत, आणि तिसरे अरुंद उद्देशाचे लिहिण्यायोग्य स्थान आहे.
| Path reopened later | What triggers the open | First sign when it fails |
|---|---|---|
| Client configuration file | A connection for that client identity | One client rejected while others connect |
| Revocation data | Peer authentication, including after replacement | Revoked and valid peers both refused |
| Script or plugin temporary directory | A helper needs to create a file | The helper exits with a path error |
persist-key बहुतेक लोक गृहीत धरतात त्यापेक्षा अरुंद प्रश्नाचे उत्तर देते. ते दस्तऐवजीकृत SIGUSR1 आणि ping-restart रीसेटमध्ये की फाइल उघडी ठेवते, आणि CCD फाइल्स, रद्दीकरण डेटा, सहाय्यक एक्झिक्युटेबल्स किंवा प्रक्रियेच्या पूर्ण पुनःप्रारंभासाठी काहीही करत नाही. ते अजूनही स्वतःच्या उघडण्याच्या मार्गांनी जातात, त्या क्षणी चालू असलेल्या कोणत्याही खात्याखाली.
खाते आणि त्याला प्रत्यक्षात असलेले दृश्य याची खात्री करा
unit फाइलवर विश्वास ठेवण्याऐवजी चालू असलेल्या डेमनला कोणते खाते वापरत आहे ते विचारा, नंतर उत्तराची unit ठरवते त्याशी तुलना करा. विसंगती ही पहिली सोडवायची गोष्ट आहे, कारण पुढील प्रत्येक परवानगी तपासणी प्रक्रिया प्रत्यक्षात जो आहे त्याच्या रूपात चालते. नंतर मार्ग घटकागणिक चाला; ओलांडणे प्रत्येक स्तरावर मूल्यांकन केले जाते, त्यामुळे ओलांडता न येणाऱ्या डिरेक्टरीतील वाचनीय फाइल वाचनीय राहत नाही. अंतिम फाइल मोड हा पहिला नाही, शेवटचा प्रश्न आहे.
नामस्थाने आणि सेवा सँडबॉक्स मालकी आणि मोड बिट्स वर्णन करत नाहीत अशा सीमा जोडतात. तुमच्या शेलमध्ये दिसणारा मार्ग chroot, माउंट नामस्थान किंवा घरातील डिरेक्टरी लपवणाऱ्या unit मध्ये अनुपस्थित किंवा फक्त-वाचन असू शकतो. सुरक्षा मॉड्यूल्स आणखी एक स्तर जोडतात, त्यामुळे वाचनीय दिसणारी फाइल उघडताना तरीही नाकारली जाऊ शकते.
ps -o user:12,pid,args -C openvpn
systemctl show -p User -p Group -p ProtectHome -p RootDirectory [email protected]
sudo -u openvpn namei -l /etc/openvpn/ccd/aliceप्रशासकाच्या शेलमधील यशस्वी वाचन या एकत्रित अटींपैकी एकही तपासत नाही. तपासणी डेमन खात्याने, त्याच नामस्थान आणि सँडबॉक्ससह चालवा, किंवा निकाल सर्व्हरचे नाही तुमच्या शेलचे वर्णन करतो हे मान्य करा. तिसरा आदेश त्या चाचणीची स्वस्त आवृत्ती आहे: तो प्रत्येक घटकाचा मोड छापतो आणि डेमन खाते ओलांडू शकत नाही अशा पहिल्या घटकावर अपयशी होतो.
रनटाइम लेखनाला स्वतःची डिरेक्टरी द्या
वाचन हा सूचीचा फक्त अर्धा भाग आहे. सहाय्यक स्क्रिप्टला स्थिती फाइल तयार करावी लागू शकते, प्लगइनला त्याच्या कॉन्फिगरेशनजवळ स्थिती लिहावी लागू शकते, आणि ती लेखन कॉन्फिगरेशन वृक्ष लिहिण्यायोग्य करून झाकली जात नाहीत. विशिष्ट डिरेक्टरीला तिच्या कार्यासाठी आवश्यक लेखन परवानगी द्या, स्पष्ट करता येतील अशा मालक आणि मोडसह. फक्त वाचल्या जाणाऱ्या सर्व गोष्टींसाठी फक्त-वाचन प्रवेशाला प्राधान्य द्या.
खाजगी कीच्या परवानग्या धोरण फाइल्सपासून वेगळ्या ठेवा. रीसेटनंतर पुन्हा वाचावी लागणाऱ्या कीची गरज प्रत्येक कनेक्शनला वाचल्या जाणाऱ्या क्लायंट फाइलपेक्षा वेगळी आहे, आणि दोन्हींसाठी एकच सोयीस्कर मोड समस्या मागते त्यापेक्षा जास्त प्रवेश देते. अरुंद मालकीचे समर्पित डेमन खाते रुंद गटापेक्षा तपासणे सोपे आहे. कीला रीसेट टिकवावे लागतात तेव्हा, persist-key डिरेक्टरी रुंद करण्याऐवजी ते पुनर्वाचन काढून टाकते.
तुम्ही पुनरुत्पादित करू शकता अशा घटनेवरून ठरवा
जिवंत बोगदा कोडमधून फक्त एक मार्ग सिद्ध करतो. फाइल आवश्यक असलेली घटना ही तुम्हाला महत्त्वाच्या उघडण्याचे कव्हर करणारी एकमेव चाचणी आहे, मग ती नवीन क्लायंट कनेक्शन असो, बदललेली रद्दीकरण फाइल असो, परवानगी दिलेला मऊ रीसेट असो किंवा नियोजित पुनःप्रारंभ असो. घटना निवडा, ती चालवा, आणि शेवटचा नाही पहिला त्रुटी ठेवा.
मऊ रीसेटसाठी एक सिग्नल आणि unit चा लॉग की पुन्हा वाचली गेली का हे दाखवतात. सिग्नल पाठवा, नंतर unit ने लिहिलेल्या शेवटच्या ओळी वाचा:
systemctl kill -s SIGUSR1 [email protected]
journalctl -u [email protected] -n 40 --no-pagerफक्त अधिकार कमी झाले म्हणून तडजोड झालेला डेमन आता फाइल्स बदलू शकत नाही असा निष्कर्ष काढू नका. तो अजून काय करू शकतो हे उरलेल्या क्रेडेन्शियल्स, त्याच्या क्षमता, तो लिहू शकतो त्या डिरेक्टरी आणि अजूनही धरलेल्या कोणत्याही लिहिण्यायोग्य डिस्क्रिप्टरवर अवलंबून आहे. अधिकार कमी करणे अधिकार क्षेत्र अरुंद करते, आणि रनटाइम उघडण्यांची यादी किती हे दाखवते. ती सीमा कॉन्फिगरेशनजवळ लिहा जेणेकरून पुढच्या व्यक्तीला ती पुन्हा शोधावी लागणार नाही.