SECLEVEL=0 लक्षण निको पार्छ, प्रमाणपत्र होइन

OpenVPN जडान असफल हुन्छ, कसैले SECLEVEL=0 थप्ने एक हरफको समाधान भेट्टाउँछ, र सुरुङ माथि उठ्छ। परिवर्तन भएको प्रमाणपत्र होइन र साइफर सुट पनि होइन; पुस्तकालयभरिको स्वीकृति सीमा सर्यो, र प्रक्रियाले त्यसपछि गर्ने सबै कुराले नयाँ सीमा उत्तराधिकारमा पाउँछ। त्यही हरफ वातावरणको प्रत्येक प्रोफाइलमा प्रतिलिपि हुनुअघि यो बुझ्न लायक छ।

कुन पुस्तकालय र कुन नीति लागू छन् निर्धारण गर्नुहोस्

SECLEVEL OpenSSL को अवधारणा हो, त्यसैले पहिलो प्रश्न यो हो कि तपाईंको बिल्डले OpenSSL प्रयोग गर्छ कि गर्दैन। OpenVPN एकभन्दा बढी क्रिप्टोग्राफी पुस्तकालयसँग जोडिन सक्छ, र तीमध्ये एउटामा लागू हुने सेटिङ अरूका लागि अर्थहीन हुन्छ। बाइनरीलाई केसँग बनाइयो सोध्नुहोस्, त्यसपछि पुस्तकालयलाई कुन संस्करण र कन्फिगरेसन लोड गर्यो सोध्नुहोस्:

openvpn --version | head -3
openssl version -a

संस्करणको आउटपुट ध्यानपूर्वक पढ्नुहोस्, किनकि वितरणहरूले पूर्वनिर्धारित मान प्याच गर्छन्। केहीले न्यूनतम स्तरलाई upstream पूर्वनिर्धारितभन्दा माथि उठाउने प्रणाली कन्फिगरेसन पठाउँछन्, र त्यसैले एउटै OpenVPN प्याकेज भएका दुई मेसिनमा एउटै प्रोफाइल फरक व्यवहार गर्छ। प्रभावकारी नीति त्यही हो जुन चलिरहेको प्रक्रियाले लोड गर्यो, upstream पुस्तिकाको होइन।

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

अस्वीकार हुन सक्ने तीन कुरा छुट्याउनुहोस्

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

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

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

इनपुट बदल्नुहोस्, सीमा होइन

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

अस्वीकृत इनपुट तपाईंले नियन्त्रण नगर्ने सहकर्मीको हो भने, कुराकानी त्यसको मालिकसँग समर्थित प्रतिस्थापन सामग्रीबारे हुन्छ। कोहीले पनि सम्हाल्ने नगरेको प्रणाली अटाउन आफ्नै सीमा घटाउँदा लागत उनीहरूबाट उनीहरूपछि जोडिने सबैतिर सर्छ।

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

घटाउनै पर्ने भए, सीमित गर्नुहोस् र अभिलेख राख्नुहोस्

कहिलेकाहीँ स्वीकृत अनुकूलता अपवाद नै सही उत्तर हुन्छ, विशेषगरी मिति तोकिएको अवकाश योजना भएको पुरानो सहकर्मीका लागि। यसलाई पूरै होस्टको सट्टा आवश्यक पर्ने सेवामा सीमित गर्नुहोस्: सेवा-विशिष्ट कन्फिगरेसन फाइल वा समर्पित OpenSSL कन्फिगरेसनको प्रभाव दायरा विश्वव्यापी प्रोफाइलमा निर्यातभन्दा सानो हुन्छ।

अपवादसँगै चार कुरा लेख्नुहोस्: सही सेटिङ, यसलाई स्वीकृत गर्ने मालिक, प्रभावित ग्राहक, र यो हटाइने सर्त। अवकाश-सर्त नभएको अपवाद अस्थायी औचित्य जोडिएको स्थायी कमजोरी हो।

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

त्यसपछि पहिचान र सुरक्षा प्रमाणित गर्नुहोस्

सफल जडानले संशोधित सर्तहरूले यसलाई स्वीकार गरेको मात्र प्रमाणित गर्छ। होस्टनाम र सहकर्मी प्रमाणीकरणले अझै आफ्नो काम गरिरहेको, प्रयोगमा रहेको प्रमाणपत्र तपाईंले तैनाथ गर्न चाहेको नै भएको, र वार्ता गरिएको डेटा च्यानल तपाईंले ठानेको नीतिसँग मिल्ने कुरा पुष्टि गर्नुहोस्।

openssl x509 -in /etc/openvpn/client.crt -noout -subject -dates -text | grep -E 'Signature Algorithm|Public-Key'
openvpn --show-tls | head -20

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

लेखापरीक्षण टिक्ने हस्तान्तरणले कुन नीतिले कुन इनपुट अस्वीकार गर्यो, के बदलियो, र परिणामस्वरूप के स्वीकार्य रहन्छ भन्छ। „यो SECLEVEL=0 सँग काम गर्छ“ एउटा जडानबारेको अवलोकन हो, तैनाथीको सुरक्षा मूल्याङ्कन होइन।