आपकी 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 पंक्ति दूसरी फ़ाइल खींचती है जिसके विकल्प उस बिंदु पर संसाधित होते हैं, इसलिए बाद का एकल-मान निर्देश मुख्य फ़ाइल जो कहती प्रतीत होती है उसे ओवरराइड कर सकता है। यदि दिखने वाली फ़ाइल सही लगती है और डेमॉन फिर भी अलग व्यवहार करता है, तो कुछ भी बदलने से पहले शामिल फ़ाइल पढ़ें।

लॉग को प्रक्रिया से मिलाएँ, उस त्रुटि से नहीं जो आपको याद है

दो लॉग गंतव्य सामान्य हैं, और उनमें से केवल एक जर्नल है। log-append सेट होने पर डेमॉन उस फ़ाइल में लिखता है और जर्नल स्टार्टअप पंक्तियों से आगे बहुत कम रखता है। इसके बिना, journalctl घटनाओं का स्रोत है।

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

एक कनेक्शन प्रयास को एक समय-खिड़की से सहसंबद्ध करें। क्लाइंट का एंडपॉइंट नोट करें, फिर उन्हीं सेकंडों से सर्वर घटनाएँ पढ़ें। जो TLS हैंडशेक कभी प्रमाणपत्र विनिमय तक नहीं पहुँचता वह पहुँच या प्रोटोकॉल बेमेल की ओर संकेत करता है, जबकि प्रमाणीकरण अस्वीकृति तब आती है जब सुरंग के पैरामीटर पहले ही तय हो चुके होते हैं।

पुरानी लॉग प्रविष्टि उस प्रोफ़ाइल के बारे में कुछ साबित नहीं करती जो आपने पाँच मिनट पहले डाउनलोड की। क्लाइंट फ़ाइल फिर से बनाएँ, एक बार कनेक्ट करें, और केवल वे पंक्तियाँ पढ़ें जो उस प्रयास के दौरान दिखीं।

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

सुरंग दोबारा बनाना निदान का चरण नहीं है

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

यही बात लागू होती है tls-auth या tls-crypt को बंद करने, verify-x509-name को ढीला करने, या हरा दर्जा पाने के लिए दूसरे कारक को छोड़ देने पर। जो सुरंग सत्यापन हटाए जाने के कारण कनेक्ट होती है वह अलग प्रणाली है, मरम्मत की गई नहीं।

लॉग ने जिस परत का नाम लिया उस पर एक सीमित बदलाव करें, उसी यूनिट को रीस्टार्ट करें, और एकमात्र कनेक्शन प्रयास दोहराएँ। यह तुलना को ईमानदार रखता है, और एक ऐसा बदलाव छोड़ता है जिसे आप वापस ला सकते हैं।

अगले व्यक्ति को क्या सौंपें

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

साझा करने से पहले संवेदनशील डेटा हटाएँ। निजी कुंजियाँ, auth-user-pass फ़ाइलें, स्टैटिक कुंजी सामग्री और पूरे क्लाइंट बंडल टिकट में नहीं होने चाहिए; विकल्पों के नाम और श्रृंखला का आकार सामान्यतः दूसरी जोड़ी आँखों के लिए पर्याप्त हैं।

यदि श्रृंखला अक्षुण्ण है और लॉग अब भी नेटवर्क की ओर इशारा करता है, तो अगला कदम क्लाइंट और सर्वर के बीच का रास्ता है, दूसरी इंस्टॉल नहीं। कहानी का यही वह हिस्सा है जो हेल्पर के पास कभी नहीं था।