तुमची VPN किल्ली प्रत्येकासाठी वाचनीय आहे: काय दुरुस्त करावे

पहिले लक्षण सहसा इशारा असतो, बिघाड नाही। क्लायंट किल्ली लोड करण्यास नकार देतो कारण फाइल गटासाठी किंवा सर्वांसाठी वाचनीय आहे, किंवा सुरक्षा पुनरावलोकनात client.key निर्यात केलेल्या बंडल्स असलेल्या प्रोफाइल डिरेक्टरीत 644 मोडवर आढळते। अजून काहीही बिघडले नाही, आणि म्हणूनच इशाऱ्याकडे दुर्लक्ष केले जाते। किल्ली काम करते, टनेल वर येते, आणि फाइल मशीनवरील प्रत्येक खात्यासाठी वाचनीय आहे।

लक्षण परवानगीचा इशारा आहे, आउटेज नाही

युनिक्ससदृश प्रणालीत खाजगी किल्ली फक्त सेवा चालवणाऱ्या खात्यासाठीच वाचनीय असावी। योग्य मालकासह 600 मोड ही सामान्य व्यवस्था आहे। 644 मोडचा अर्थ प्रत्येक स्थानिक वापरकर्ता किल्लीची प्रत करू शकतो, आणि सामायिक बिल्ड होस्टवर ते खरे प्रेक्षक आहे।

हे तपासणारे क्लायंट तुमच्यावर उपकार करतात। जे तपासत नाहीत ते फाइल सुरक्षित असल्याचा पुरावा नाही, आणि यशस्वी कनेक्शन ते शक्य करणारी सामग्री इतर कोण वाचू शकतो याबद्दल काहीही सांगत नाही। इशाऱ्यालाच संपूर्ण निष्कर्ष माना। तो अचूक आहे, आणि कोणी फाइलची प्रत करण्यापूर्वीच आला आहे।

मोड सेवेच्या ओळखीशी जुळवा

फक्त मालकाचा प्रवेश त्या मालकाने वापरलेल्या किल्लीसाठी योग्य आहे। जाणूनबुजून सामायिक गट असलेल्या सेवेला वेगळी नियंत्रित व्यवस्था लागू शकते, जसे सेवा खात्याच्या मालकीच्या किल्लीवर गट वाचन। प्रत्येक फाइल अंधाधुंद एकाच संख्यात्मक मोडवर ठेवल्याने समर्थित क्लायंट तुटतात, आणि chmod -R 777 कोणत्याही गोष्टीचा उपाय नाही।

काहीही बदलण्यापूर्वी मालक आणि सेवा खाते तपासा। सार्वजनिक CA प्रमाणपत्रे आणि खाजगी ओळख किल्ल्यांच्या गोपनीयतेच्या आवश्यकता वेगळ्या असतात, जरी त्या एकाच डिरेक्टरीत असल्या तरी, म्हणून संपूर्ण फोल्डरवर लागू होणारा आवर्ती मोड दोन्हींना एकच वस्तू मानतो।

ls -l /etc/openvpn/client/
stat -c '%U %G %a %n' /etc/openvpn/client/*.key
id openvpn

इतर प्लॅटफॉर्मवर युनिक्स मोडचे अंदाजात भाषांतर करण्याऐवजी दस्तऐवजीकृत किल्ली स्टोअर किंवा प्रवेश-नियंत्रण मॉडेल वापरा। private ने संपणारे फाइलनाव लेबल आहे, अंमलबजावणीची यंत्रणा नाही।

मोड व्यापत नसलेल्या प्रती शोधा

संपादक, बॅकअप संग्रह, निर्यात केलेली प्रोफाइल आणि तात्पुरती बंडल्स प्रत्येक एकच ओळख टिकवू शकतात। त्या प्रती त्यांच्या सामग्रीनुसार संरक्षित करा, कारण मूळ फाइल घट्ट करणे गेल्या महिन्याच्या टारबॉलमधील प्रतीसाठी काहीही करत नाही।

किल्ली फाइलवरील पासफ्रेज साठवलेल्या सामग्रीसाठी उपयुक्त आहे आणि एन्क्रिप्टेड फाइल तिच्या पासवर्डशेजारी प्रकाशित करण्याचे समर्थन करत नाही। परवानग्या सध्याच्या फाइलसिस्टम ऑब्जेक्टचे रक्षण करतात; इतरत्र आधीच प्रत केलेल्या क्रेडेन्शियलबद्दल त्या काहीही सांगत नाहीत।

काम पूर्ण झाले असे घोषित करण्यापूर्वी प्रती शोधा: grep -rl संभाव्य डिरेक्टरींमध्ये किल्लीची हेडर ओळ, आणि बॅकअप वगळण्यांवर एक नजर। निकाल सहसा तुम्ही सुरू केलेल्या फाइलपेक्षा अधिक मनोरंजक असतो।

दुरुस्तीनंतर, पडताळा आणि बदला

इच्छित सेवा अजूनही प्रमाणीकरण करते का ते तपासा, नंतर कोणत्याही अनावश्यक खात्याला प्रवेश मिळाला नाही याची खात्री करा। निदान आउटपुट मेटाडेटापर्यंत मर्यादित ठेवा, कारण फाइल वाचनीय असल्याचे सिद्ध करण्यासाठी किल्ली छापण्याची गरज नाही आणि त्यामुळे सामग्री लॉगमध्ये जाते।

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