OpenVPN सेवा उस प्रोफ़ाइल पर विफल होती है जिसे GUI खोलता है: पाँच जाँचें

दो लॉन्चर एक ही मशीन पर वही प्रोफ़ाइल खोलते हैं, और केवल GUI जुड़ता है। फ़ाइल अक्षुण्ण है और इंस्टॉलर शायद ठीक है; जो अलग है वह संदर्भ है जो हर लॉन्चर openvpn.exe को देता है। कार्य निर्देशिका, खाते की पहचान और फ़ाइल एट्रिब्यूट सभी उस संदर्भ के साथ चलते हैं। उन्हें उसी क्रम में जाँचें और उस पहले वाले पर रुकें जो त्रुटि समझाता है।

पुष्टि करें कौन सा लॉन्चर विफल होता है

विभाजन सिद्ध करके शुरू करें। यदि GUI जुड़ता है और सेवा नहीं, उसी प्रोफ़ाइल पथ के साथ, तो फ़ाइल किसी के लिए पठनीय है और सवाल यह हो जाता है कि इसे कौन पढ़ता है और कहाँ से। यदि दोनों विफल हों, तो प्रोफ़ाइल टूटी है और इसमें से कुछ भी लागू नहीं होता। सेवा का नाम और वह सटीक प्रोफ़ाइल लिख लें जिसे लोड करने को कहा गया था।

अपनी ही ऑटोस्टार्ट निर्देशिका की ओर इंगित सेवा शायद वह फ़ाइल लोड न करे जो आपने संपादक में खोली है। सेवा कॉन्फ़िगरेशन के पथ की GUI के पथ से अक्षर-दर-अक्षर तुलना करें, क्योंकि अंत में जुड़ा फ़ोल्डर नाम या अलग ड्राइव अक्षर आपको गलत शाखा में भेजने के लिए पर्याप्त है।

सापेक्ष पथ कहाँ हल होते हैं

जो प्रोफ़ाइल ca.crt या किसी सहायक स्क्रिप्ट का केवल नाम से संदर्भ देता है, वह प्रक्रिया जहाँ भी हो उसके सापेक्ष खोज माँगता है। GUI कॉन्फ़िगरेशन फ़ोल्डर में शुरू होता है, इसलिए वे नाम हल हो जाते हैं। सेवा प्रबंधक द्वारा शुरू की गई सेवा के पास ऐसा प्रारंभ बिंदु नहीं होता, और कोई भी प्रमाणपत्र पढ़े जाने से पहले खोज विफल हो जाती है। इसीलिए वही प्रोफ़ाइल एक लॉन्चर में काम करता है और दूसरे में नहीं।

रैपर को शुरू करने के लिए एक निर्देशिका दें, या हर संदर्भ को निरपेक्ष बनाएँ। कमांड लाइन पर GUI का संदर्भ दोहराना ऐसा दिखता है:

openvpn --cd "C:\VPN\profiles\office" --config "C:\VPN\profiles\office\office.ovpn"

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

जब सेवा की पहचान पढ़ नहीं सकती

सेवा आपके रूप में नहीं, सिस्टम पहचान के रूप में चलती है। जो ACL आपके उपयोगकर्ता को पूरा नियंत्रण देता है और किसी और को नहीं, वह वहाँ विफल होता है जबकि आपके सत्र में पूरी तरह काम करता है। मैप किए गए ड्राइव या प्रमाणित शेयर पर रखी प्रोफ़ाइल भी उसी कारण विफल होती है। कुछ और देखने से पहले फ़ाइल की अनुमतियाँ पुष्ट करें।

जाँच प्रभावी अनुमतियों की पढ़ाई और सेवा की पहचान के रूप में आज़माई गई पढ़ाई है। पहला भाग उन्नत प्रॉम्प्ट से चलाएँ:

icacls "C:\VPN\profiles\office\office.ovpn"

फिर वही पढ़ाई सेवा की पहचान के रूप में आज़माएँ, उदाहरण के लिए Sysinternals के psexec -s -i से, और देखें कि फ़ाइल खुलती है या नहीं। यदि नहीं, तो कोई पथ सुधार मदद नहीं करेगा। ACL ठीक करें या प्रोफ़ाइल को ऐसी जगह ले जाएँ जहाँ से सेवा की पहचान पढ़ सके।

फ़ाइल-स्तरीय एन्क्रिप्शन दूसरा, दुर्लभ मामला है। Encrypting File System एट्रिब्यूट से चिह्नित प्रोफ़ाइल उस उपयोगकर्ता के लिए पारदर्शी रूप से डिक्रिप्ट होती है जिसने इसे एन्क्रिप्ट किया, और सेवा खाते के लिए अपठनीय रहती है। इसीलिए वही फ़ाइल आपके संपादक में खुलती है और सेवा के अधीन नहीं।

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

cipher /s:"C:\VPN\profiles\office"
attrib "C:\VPN\profiles\office\office.ovpn"

एट्रिब्यूट हटाने से फ़ाइल पठनीय हो जाती है, और इससे वह सुरक्षा भी हट जाती है जो इसे प्राप्त थी। यदि प्रोफ़ाइल सुरक्षित रहना चाहिए, तो गुप्त सामग्री वहाँ रखें जहाँ सेवा की पहचान के पास स्पष्ट अनुदान हो, प्रति-उपयोगकर्ता एन्क्रिप्शन पर निर्भर रहने के बजाय। ऐसी व्यवस्था पासवर्ड बदलने पर भी टिकती है, और यह पहुँच को उस व्यक्ति के अलावा किसी और के लिए समीक्षा-योग्य बनाती है जिसने फ़ाइल एन्क्रिप्ट की थी।

यह तय करना कि टनल का मालिक कौन है

GUI पासवर्ड माँग सकता है और आपके उपयोगकर्ता भंडार से प्रमाणपत्र पढ़ सकता है। सेवा दोनों में से कुछ नहीं कर सकती, इसलिए इंटरैक्टिव गुप्त पर निर्भर प्रोफ़ाइल पथ कैसे भी ठीक किए जाएँ, बिना निगरानी कभी शुरू नहीं होगी। यह सीमा एक डिज़ाइन निर्णय है, टालने योग्य खराबी नहीं। कुछ और बदलने से पहले एक मालिक चुनें।

यदि टनल लॉगिन से पहले चालू होनी चाहिए, तो सेवा को बिना निगरानी वाला क्रेडेंशियल स्रोत और प्रोफ़ाइल की अपनी प्रति दें। यदि यह केवल तब होनी चाहिए जब आप डेस्क पर हों, तो इसे GUI में रखें और सेवा की प्रति हटा दें। दोनों एक साथ वह कॉन्फ़िगरेशन है जो एडेप्टर विरोध और दोहरे रूट पैदा करता है।

उस विरोध का निदान आमतौर पर कॉन्फ़िग त्रुटि के रूप में होता है, न कि एक एडेप्टर के लिए लड़ते दो मालिकों के रूप में। इवेंट लॉग दिखाएगा कि एक प्रक्रिया TAP उपकरण खोलने में विफल रही, जो अनुमति समस्या जैसा लगता है और नहीं है। पहले मालिकों की गिनती करें।

सेवा रैपर वास्तव में क्या शुरू करता है

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

मान रजिस्ट्री में सेवा की अपनी कुंजी के अंतर्गत रहते हैं, और sc qc वह बाइनरी पथ दिखाता है जिसे सेवा प्रबंधक शुरू करेगा। किसी भी एक को संपादित करने से पहले उस पथ की तुलना रैपर के संग्रहीत कॉन्फ़िगरेशन से करें।

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