GUI उघडते त्या प्रोफाइलवर OpenVPN सेवा अयशस्वी होते: पाच तपासण्या

दोन लाँचर एकाच मशीनवर तेच प्रोफाइल उघडतात, आणि फक्त 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 सेवा व्यवस्थापक जो बायनरी मार्ग सुरू करेल तो दाखवते. यापैकी कोणतेही संपादित करण्यापूर्वी त्या मार्गाची रॅपरच्या साठवलेल्या कॉन्फिगरेशनशी तुलना करा.

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