यहाँ दुई आवश्यकता जोडिएका छन्: टनेल माथि उठ्नुपर्छ कसैले लगइन गर्नु अघि, र दोस्रो साइटको ट्राफिकले त्यसलाई पछ्याउनुपर्छ। यी फरक संयन्त्र भएका फरक समस्याहरू हुन्। सेवा सुरु हुनुले पहिलो निर्धारण गर्छ, र रुटको आयुले दोस्रो। एउटा समाधान गर्दा अर्को जहाँ थियो त्यहीँ रहन्छ।

पहिलो चरण: सेवाले खोज्ने ठाउँमा प्रोफाइल राख्नुहोस्

Windows सेवाले स्थिर डाइरेक्टरीबाट प्रोफाइल पढ्छ, र GUI पनि त्यही ठाउँबाट पढ्छ, त्यसैले आयात गर्दा काम गर्ने प्रोफाइल बुटमा अदृश्य रहन सक्छ। .ovpn फाइलहरू इन्स्टलेसनको config डाइरेक्टरीमा राख्नुहोस्, जुन सामान्यतया Program Files अन्तर्गत हुन्छ। प्रयोगकर्ताको Downloads फोल्डरमा छोडिएको प्रोफाइल सेवाको दायरामा नै पर्दैन।

पुराना निर्देशनहरू config-auto फोल्डरतर्फ सङ्केत गर्छन्, जसलाई 2.5 युगका केही बिल्डहरूले आदर गरे र पछिल्ला रिलिजहरूले गरेनन्। त्यसैले अपग्रेडले काम गर्ने अटोस्टार्टलाई मौनतामा बदल्न सक्छ, लगमा प्रमाणहरूबारे केही नभए पनि। कुनै पनि फाइल सार्नु अघि इन्स्टल गरिएको बिल्डले वास्तवमा कुन डाइरेक्टरी पढ्छ भनी पुष्टि गर्नुहोस्।

एउटै मेसिनमा धेरै प्रोफाइल भए, dev-node मार्फत प्रत्येकलाई नाम भएको एडाप्टर दिनुहोस्। नत्र तिनीहरू एउटै इन्टरफेसका लागि प्रतिस्पर्धा गर्छन् र दोस्रो प्रमाण समस्याजस्तो देखिने तरिकाले असफल हुन्छ।

दोस्रो चरण: ट्रे आइकन होइन, सेवा सुरु गर्नुहोस्

सेवालाई OpenVPN Automatic मा राख्दा त्यो लगइन बिना बुटमा सुरु हुन्छ। त्यही संयन्त्र हो, र ट्रे आइकन त्यसको भाग होइन। जब कनेक्सन सेवाको स्वामित्वमा हुन्छ, GUI ले कुनै आइकन वा स्थिति नदेखाउन सक्छ, जुन अपेक्षित हो, खराबी होइन।

नतिजा यो हो कि डिस्कनेक्ट गर्नु भनेको सेवा रोक्नु हो, Disconnect क्लिक गर्नु होइन। मेसिनलाई सहयोग गर्नेलाई भन्नुहोस्, नत्र पहिलो सहयोग कल हराएको आइकनबारे हुनेछ।

सेवा खाताले प्रोफाइल र कुञ्जी सामग्री पढ्न सक्छ कि जाँच्नुहोस्। बुटमा अनुमति समस्या लगमा ठ्याक्कै प्रमाणीकरण असफलता जस्तो देखिन्छ।

तेस्रो चरण: रुटलाई टनेलसँग बाँध्नुहोस्

स्थायी प्रविष्टि यहाँ गलत साधन हो। -P सँग रुट थप्दा त्यो रिबुट पनि सहन्छ र, अझ नराम्रो, टनेल बन्द हुनु पनि सहन्छ। VPN बन्द हुँदा प्रिफिक्स अझै नभएको गेटवेतर्फ सङ्केत गर्छ, त्यसैले कसैले प्रविष्टि नमेटाएसम्म होस्ट त्यो गन्तव्यमा पुग्न सक्दैन।

तीन विकल्पहरू सही व्यवहार गर्छन्। सर्भरबाट रुट पुश गर्नुहोस्, जसले कनेक्ट हुँदा थप्छ र डिस्कनेक्ट हुँदा हटाउँछ। route_vpn_gateway पढ्ने route-up स्क्रिप्टमा थप्नुहोस्, ताकि अर्को हप वार्ता गरिएको टनेलबाट आउँछ। वा Add-VpnConnectionRoute लाई Windows को मूल VPN प्रोफाइलसँग प्रयोग गर्नुहोस्, जसले प्रिफिक्सलाई त्यो कनेक्सनमा बाँध्छ।

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

चौथो चरण: चिसो बुट सहनुहोस्

नेटवर्क स्ट्याक हुनु अघि सेवा सुरु गर्दा एउटा असफल प्रयास हुन्छ र पुनः प्रयास हुँदैन। त्यसलाई Automatic (Delayed Start) मा राख्दा, वा नेटवर्क सेवामा निर्भरता थप्दा, त्यो दौड हट्छ। त्यसपछि बुट परीक्षण दोहोर्याउनुहोस् र दोस्रो प्रयास अब आवश्यक नभएको जाँच्नुहोस्।

रुट र एडाप्टर परिवर्तनका लागि प्रशासक अधिकार चाहिन्छ। प्रति-प्रयोगकर्ता स्टार्टअप सर्टकटमा ती हुँदैनन्, त्यसैले उन्नत शेलबाट चल्ने स्क्रिप्टले लगइनमा चुपचाप केही नगर्न सक्छ। यसलाई उच्चतम विशेषाधिकारसहितको कार्यका रूपमा तालिकाबद्ध गर्नुहोस्, वा सेवालाई परिवर्तन सम्हाल्न दिनुहोस्। त्यसपछि वास्तवमै लगइन गर्ने प्रयोगकर्ताका रूपमा परीक्षण गर्नुहोस्।

तपाईंले वास्तवमै तैनाथ गर्ने क्रम परीक्षण गर्नुहोस्, हातले चलाउन सकिने होइन। चिसो बुट मात्र क्रम परीक्षण गर्ने एकमात्र परीक्षण हो।

पाँचौं चरण: GUI बिना प्रमाणित गर्नुहोस्

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

एडाप्टर कहिल्यै नदेखिए, शंकास्पद प्रोफाइल होइन, ड्राइभर हो। ती दुई असफलता लगमा बिल्कुलै उस्तै देखिँदैनन्, र तीमध्ये एउटाले मात्र सफ्टवेयर पुनः इन्स्टल गर्न प्रतिक्रिया दिन्छ।

सम्बन्धित लेखहरू