OpenVPN प्रमाणपत्र आणि किल्ली कशी सोडवते: इनलाइन PEM की फाइल पथ

संदेश सांगतो की OpenVPN इनलाइन प्रमाणपत्र लोड करू शकत नाही, पण तुमच्या मनात असलेले फाइलनाव उलटे सांगते। पार्सरला काय मिळाले हे फाइल सिस्टीममध्ये काय आहे यापेक्षा जास्त महत्त्वाचे आहे, कारण cert निर्देश पूर्णपणे वेगळ्या दोन प्रकारची मूल्ये स्वीकारतो। एक म्हणजे तो उघडणारा पथ; दुसरे म्हणजे कॉन्फिगरेशनच्या आत आलेला PEM मजकूर। चालू असलेल्या क्लायंटला कोणता आकार मिळाला हे कळेपर्यंत प्रत्येक दुरुस्ती ही एक अटकळ आहे।

दोन साठवण आकार, एक निर्देश

cert, key आणि ca निर्देश प्रत्येकी पथ किंवा इनलाइन ब्लॉक स्वीकारतात। मूल्य पथ असल्यास OpenVPN ती फाइल उघडतो आणि डिस्कवरून ऑब्जेक्ट वाचतो। कॉन्फिगरेशनमध्ये cert टॅगने बांधलेला ब्लॉक असल्यास तोच निर्देश त्याऐवजी त्या टॅगमधील सामग्री वापरतो, आणि वेगळी फाइल गुंतलेली नसते।

दोन्ही आकार शेवटी एकाच प्रकारचा ऑब्जेक्ट तयार करतात, म्हणून कार्यरत तैनाती इतर कोणत्याही बदलाशिवाय त्यांच्यात जाऊ शकते। जे प्रोफाइल आत बसवलेले क्लायंट प्रमाणपत्र आणि खाजगी किल्ली वाहते ते स्वयंपूर्ण आहे, आणि ते दुसऱ्या मशीनवर प्रत करणे प्रमाणपत्र डिरेक्टरीही न प्रत करता चालते।

उलटे खरे नाही। स्वतःचा डेटा आत बसवणाऱ्या प्रोफाइलच्या शेजारी client.crt ठेवल्याने काहीही बदलत नाही, कारण कॉन्फिगरेशनमधील काहीही त्या फाइलचा संदर्भ देत नाही। स्पष्टपणे अस्तित्वात असलेली फाइल दुर्लक्षित वाटण्याचे हे सर्वात सामान्य कारण आहे।

इनलाइन ब्लॉक ऑब्जेक्ट कसा बनतो

इनलाइन सामग्री कॉन्फिगरेशनमधून काढून मजकूर म्हणून PEM पार्सरला दिली जाते। तो पार्सर नेहमीच्या सीमा अपेक्षितो: BEGIN ओळ, base64 पेलोड आणि जुळणारी END ओळ। ब्लॉक अयशस्वी प्रतीमुळे कापला गेला असेल, डाउनलोड पानाने तो HTMLमध्ये गुंडाळला असेल, किंवा डॅश सामान्य करणाऱ्या एडिटरमध्ये उघडला असेल, तर पार्सर अस्तित्वात दिसणाऱ्या सामग्रीवर अयशस्वी होतो।

<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>

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

लोड झालेला प्रोफाइल प्रत्यक्षात कोणता आकार वापरतो ते तपासा, तुमच्या एडिटरने योगायोगाने कोणती फाइल उघडली ते नाही:

grep -nE '^(ca|cert|key) |^<(ca|cert|key)>' client.ovpn

पथ संदर्भ कसा सोडवला जातो

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

सापेक्ष पथ तीच संदिग्धता वारसा घेतात। नुसते फाइलनाव दिसल्यावर, तुमच्या टर्मिनलशी जुळते असे गृहीत धरण्याऐवजी उत्पादनात प्रक्रियेची सध्याची डिरेक्टरी कोणती आहे ते विचारा।

वेगळी साठवलेल्या प्रमाणपत्रासाठी, त्यावर काहीही डीबग करण्यापूर्वी ऑफलाइन पार्स ऑब्जेक्टची पुष्टी करतो:

openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -check

ती आदेश सिद्ध करतात की फाइली वाचनीय आणि संरचनात्मकदृष्ट्या वैध आहेत। ते सिद्ध करत नाहीत की सहकारी जारीकर्त्यावर विश्वास ठेवतो, प्रमाणपत्र अजूनही त्याच्या वैधता कालावधीत आहे, किंवा किल्ली त्याची आहे।

पार्सर त्रुटी काय सांगू शकते आणि काय नाही

पार्स अयशस्वी होणे समस्येला एका इनपुट आणि एका टप्प्यापर्यंत मर्यादित करते। क्लायंटने दोन साठवण आकारांपैकी कोणता वापरला हे ते सांगत नाही, आणि ऑब्जेक्ट स्वीकारला गेला असता का हेही सांगत नाही। हे वेगळ्या पुराव्यांसह वेगळे प्रश्न आहेत।

पार्स यशस्वी झाल्यानंतर, पुढील अयशस्वीता नंतरच्या टप्प्याची असते। विश्वास नाकारणे, उद्देशाची विसंगती किंवा किल्लीची विसंगती लोडर नाही, सहकारी किंवा TLS स्तर कळवतो। तीच फाइल वारंवार बदलल्याने ती त्रुटी हलणार नाही।

तपासणीच्या काळात संवेदनशील अर्धा भाग सार्वजनिक अहवालांबाहेर ठेवा। निर्देशांची नावे, त्रुटीचा मजकूर आणि ब्लॉकची रचना सामायिक करा, किल्ली सामग्री आणि कोणताही ओळखणारा पेलोड काढून। openvpn(8) पुस्तिका फाइल निर्देशांचे दोन्ही आकार आणि त्यांच्या मागील कार्यरत-डिरेक्टरी वर्तनाचे दस्तऐवजीकरण करते।