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 ले सेवा प्रबन्धकले सुरु गर्ने बाइनरी मार्ग देखाउँछ। कुनै पनि सम्पादन गर्नुअघि त्यो मार्गलाई र्यापरको भण्डारित कन्फिगरेसनसँग तुलना गर्नुहोस्।

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