तुमचा PiVPN प्रोफाइल प्रत्यक्षात कोणता OpenVPN इन्स्टन्स वापरत आहे?

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

हेल्पर आणि डेमॉन वेगवेगळ्या वस्तू आहेत

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

systemd होस्टवर डिरेक्टरी यादीऐवजी सक्रिय युनिटपासून सुरुवात करा। नाव पॅकेजिंगवर अवलंबून आहे: Debian आणि Raspberry Pi OS इमेज सहसा टेम्पलेट इन्स्टन्स देतात, उदाहरणार्थ openvpn-server@server, तर जुनी इन्स्टॉलेशन openvpn@server वापरतात। फाइलच्या नावावरून अंदाज करण्याऐवजी मॅनेजरला विचारा की कोणता चालू आहे।

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

वाचा ExecStart= त्या आउटपुटमध्ये। तो एक्झिक्युटेबल आणि मॅनेजर प्रत्यक्षात सुरू करत असलेले पर्याय, तसेच कोणताही --config मार्ग नमूद करतो; जवळ असलेली आणि कोणत्याही आदेशाने संदर्भ न दिलेली कॉन्फिगरेशन फाइल चालू सुरुंगाचा भाग नाही।

डेमॉनने सोडवलेल्या कॉन्फिग साखळीचा मागोवा घ्या

OpenVPN सेटिंग्जसाठी डिरेक्टरी स्कॅन करत नाही। तो --config सोबत दिलेली फाइल वाचतो, आतील कोणत्याही config सूचनेचा मागोवा घेतो, आणि नंतर कमांड-लाइन पर्याय लागू करतो। मार्गदर्शक 2.6 तो क्रम वर्णन करतो, आणि दोन फाइल्स पोर्ट, डिव्हाइस किंवा सायफरवर एकमत नसताना हे महत्त्वाचे ठरते।

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

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

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

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

लॉग प्रक्रियेशी जुळवा, तुम्हाला आठवणाऱ्या त्रुटीशी नाही

दोन लॉग गंतव्ये सामान्य आहेत, आणि त्यांपैकी फक्त एक journal आहे। log-append सेट असल्यास डेमॉन त्या फाइलमध्ये लिहितो आणि journal स्टार्टअप ओळींशिवाय थोडेच ठेवते। ते नसल्यास journalctl घटनांचा स्रोत आहे।

journalctl -u openvpn-server@server -n 80 --no-pager

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

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

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

सुरुंग पुन्हा बांधणे हे निदानाचे पाऊल नाही

मोहात पडून घेतलेला शॉर्टकट म्हणजे दुसरा, सोपा सुरुंग उभारणे: स्थिर किल्ली, प्रमाणपत्रे नाहीत, अतिरिक्त प्रमाणीकरण नाही। तो अनेकदा कनेक्ट होईल, आणि दोन होस्ट त्यांच्यात UDP किंवा TCP पाठवू शकतात एवढेच सिद्ध करेल। प्रमाणपत्र-प्रमाणित तैनाती का अयशस्वी होते याबद्दल तो काहीही सांगत नाही, आणि ठेवण्यास सांगितलेले सुरक्षा मॉडेल गुपचूप बदलून टाकतो।

हेच tls-auth किंवा tls-crypt बंद करण्यावर, verify-x509-name सैल करण्यावर, किंवा हिरवा दर्जा मिळवण्यासाठी दुसरा घटक सोडण्यावरही लागू होते। पडताळणी काढून टाकल्यामुळे कनेक्ट होणारा सुरुंग वेगळी प्रणाली आहे, दुरुस्त केलेली नाही।

लॉगने नामनिर्देश केलेल्या स्तरावर एक मर्यादित बदल करा, तेच युनिट रीस्टार्ट करा, आणि तो एकच कनेक्शन प्रयत्न पुन्हा करा। यामुळे तुलना प्रामाणिक राहते, आणि परत घेता येणारा बदल शिल्लक राहतो।

पुढच्या व्यक्तीला काय द्यायचे

चार तथ्ये त्यांच्याकडे असतानाच लिहून ठेवा: OpenVPN आवृत्ती openvpn --version वरून, सक्रिय युनिट, इन्क्लूडसह कॉन्फिग साखळी, आणि एका प्रयत्नाला व्यापणारी लॉग खिडकी। ती चार अस्पष्ट तक्रार पुनरुत्पादनीय प्रकरणात बदलतात।

सामायिक करण्यापूर्वी संवेदनशील माहिती पुसा। खाजगी किल्ल्या, auth-user-pass फाइल्स, स्थिर किल्ली सामग्री आणि संपूर्ण क्लायंट बंडल तिकिटात नसावेत; पर्यायांची नावे आणि साखळीचा आकार सहसा दुसऱ्या जोडी डोळ्यांना पुरतात।

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