OpenVPN client-config-dir: फाइलनाव विरुद्ध प्रमाणपत्राचे सामान्य नाव

क्लायंट जोडण्यापूर्वीच दोन नावे खेळात असतात: लॅपटॉपवरील फाइलनाव (nuc.ovpn) आणि सर्व्हर क्रेडेन्शियलमधून काढणारी ओळख. client-config-dir शोध दुसऱ्याचा वापर करतो. क्लायंटवर प्रोफाइलचे नाव बदलणे, किंवा सर्व्हरच्या फाइलमध्ये .conf जोडणे, सर्व्हर कोणती फाइल उघडतो यात काहीही बदलत नाही.

उपयुक्त तुलना «मी कोणते नाव वापरले» नाही तर «सर्व्हर कोणता नियम लागू करतो» ही आहे, कारण प्रमाणपत्र प्रमाणीकरण आणि वापरकर्तानाव/पासवर्ड प्रमाणीकरण एकाच लॉगिनमधून वेगळी प्रभावी नावे तयार करू शकतात.

प्रोफाइलचे नाव विरुद्ध प्रमाणपत्राचे सामान्य नाव

डीफॉल्ट प्रमाणपत्र-आधारित सेटअपमध्ये सर्व्हर X.509 सामान्य नाव घेतो आणि client-config-dir मध्ये नेमक्या त्या नावाची फाइल शोधतो. ज्या प्रोफाइलचे नाव nuc.ovpn आहे आणि ज्याचे प्रमाणपत्र tester सांगते ते /etc/openvpn/server/ccd/tester मध्ये सोडवले जाते. क्लायंट फाइलचे नाव कधीही गणनेत येत नाही. विसंगती लपण्याची पहिली जागा हीच आहे.

त्यामुळे काळजीपूर्वक नाव दिलेल्या प्रोफाइलने भरलेली डिरेक्टरी प्रत्येक वेळी चुकू शकते. फाइल subject, ईमेल पत्ता किंवा GUI मध्ये दिसणाऱ्या नावाने जुळवली जात नाही; ती सामान्य नावाच्या स्ट्रिंगने जुळवली जाते.

केस-संवेदनशील फाइलसिस्टमवर Tester आणि tester या दोन वेगळ्या फाइल्स आहेत, आणि फक्त एकच उघडली जाते. सामान्य नाव क्लायंट प्रत्यक्षात सादर करतो त्या प्रमाणपत्रातून तपासा, तुमच्या नोट्समधील प्रतीमधून नाही.

username-as-common-name नियम उलटतो

सर्व्हर username-as-common-name सह वापरकर्तानाव/पासवर्ड प्रमाणीकरण चालवतो तेव्हा, प्रमाणित वापरकर्तानाव या शोधासाठी प्रमाणपत्राचे सामान्य नाव बदलते.

दोन्ही प्रकरणांची थेट तुलना करा: प्रमाणपत्र ओळखीत फाइल प्रमाणपत्राचे अनुसरण करते आणि पासवर्ड बदलणे अप्रासंगिक आहे; वापरकर्तानाव ओळखीत फाइल लॉगिन नावाचे अनुसरण करते आणि प्रमाणपत्र पुन्हा जारी करणे अप्रासंगिक आहे. सर्व्हर जे क्षेत्र बदलतो त्याच्या आधारेच नाव बदलावे. नवीन CN सह पुन्हा जारी केलेले प्रमाणपत्र शोधाचे लक्ष्य शांतपणे बदलते, आणि जुनी CCD फाइल डिस्कवर बरोबर दिसत राहते.

मिश्र संरचना अस्तित्वात आहेत, आणि बहुतेक गोंधळ तिथूनच सुरू होतो. एक सेवा ब्लॉक बदली सुरू करतो आणि दुसरा करत नाही, तर प्रभावी नाव कोणत्या इन्स्टन्सने कनेक्शन हाताळले यावर अवलंबून असते. जागतिक फाइल लागू आहे असे गृहीत धरण्याऐवजी सक्रिय संरचना पुष्टी करा. अपस्ट्रीम सर्व्हर पर्याय संदर्भ नामांकित फाइल शोध आणि ऐच्छिक फॉलबॅकचे दस्तऐवजीकरण करतो.

सर्व्हर काय वाचतो, आणि काय शांतपणे वगळतो

फाइल निवडली जाईल का हे दोन छोटे फरक ठरवतात. पहिला म्हणजे जोडलेला एक्स्टेंशन. दुसरा म्हणजे नावात राहिलेले एक अक्षर.

OpenVPN ज्या नावाचा शोध घेतो त्यात .conf जोडत नाही, त्यामुळे tester.conf tester शी जुळत नाही. एक्स्टेंशन लपवणारा एडिटर यादीत बरोबर दिसणारी पण कधीही न जुळणारी फाइल सोडू शकतो.

जुळणारी फाइल नसल्यास, सर्व्हर DEFAULT नावाच्या फाइलवर परत जाऊ शकतो. त्यामुळे काही सेटिंग्ज येणे म्हणजे प्रति-क्लायंट फाइल वापरली गेली याचा पुरावा नाही. नियुक्त केलेला पत्ता किंवा पुश केलेले मार्ग प्रति-क्लायंट फाइल काय देईल त्याशी तुलना करा. परवानग्या तिसरा फिल्टर आहेत, कारण सर्व्हर विशेषाधिकार सोडल्यानंतर फाइल उघडतो; ती वाचू शकणारा root शेल काहीही सिद्ध करत नाही.

बरोबर फाइलनाव सामग्रीची पडताळणी करत नाही

निवड आणि सामग्री वेगळ्या अयशस्वीता आहेत. योग्य फाइल उघडल्यानंतरही तिच्या सूचना त्या क्लायंटसाठी वैध असणे आवश्यक आहे.

ifconfig-push ने टोपोलॉजी प्रत्यक्षात वापरू शकेल असा पत्ता द्यायला हवा, आणि iroute फक्त त्या क्लायंटच्या मागील राउटेड सबनेटसाठी अर्थपूर्ण आहे.

एक ओळख, अनेक उपकरणे

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

तुलना ओळख सामायिक करणे आणि प्रति उपकरण एक प्रमाणपत्र जारी करणे यात आहे. सामायिक करणे प्रशासनास सोपे आणि रद्दबातलतेस जाड आहे, तर प्रति-उपकरण प्रमाणपत्रांना अधिक सेटअप लागतो आणि अक्षम करण्यासाठी स्वच्छ एकक देतात.