तपाईंको 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 फाइलहरू, स्थिर कुञ्जी सामग्री र पूर्ण क्लाइन्ट बन्डल टिकटमा हुँदैनन्; विकल्पका नाम र शृंखलाको आकार सामान्यतया दोस्रो जोडी आँखालाई पर्याप्त हुन्छ।

शृंखला अक्षुण्ण छ र लग अझै नेटवर्कतर्फ संकेत गर्छ भने, अर्को कदम क्लाइन्ट र सर्भरबीचको मार्ग हो, अर्को इन्स्टल होइन। कथाको त्यही भाग हेल्परसँग कहिल्यै थिएन।