.ovpn फाइलमा वास्तवमा के हुन्छ, र यसले के गर्न सक्दैन

धेरैजसो मानिसलाई लाग्छ कि .ovpn फाइलले VPN कन्फिगर गर्छ। त्यस्तो होइन: यसले एउटा क्लाइन्ट कन्फिगर गर्छ, र यसले माग्ने सबै कुरा पहिले नै अर्को छेउमा हुनुपर्छ। फाइलमा एउटा लाइन बदल्दा तपाईंको मेसिनले के प्रयास गर्छ त्यो बदलिन सक्छ, तर सर्भरले के दिन्छ त्यो कहिल्यै बदलिँदैन। यही भिन्नताले आयात वा जडान हुन नसक्ने प्रोफाइलबारे धेरैजसो अलमल बुझाउँछ।

फाइललाई तपाईंको क्लाइन्टमा पठाइएका अनुरोधहरूको सूचीका रूपमा पढ्नुहोस्, र यसका धेरैजसो लाइन स्पष्ट हुनेछन्।

फाइलले तपाईंको क्लाइन्ट वर्णन गर्छ, सर्भर होइन

एउटा प्रोफाइलले remote अन्त्य बिन्दु, ट्रान्सपोर्ट, इन्टरफेस प्रकार, पहिचान सामग्री र अपरेटरले चाहेको कुनै पनि क्लाइन्ट-तर्फी व्यवहार एकै ठाउँमा जोड्छ। हरेक लाइन क्लाइन्टले सुरु हुँदा चलाउँछ। तीमध्ये कुनै पनि कन्फिगरेसन परिवर्तनका रूपमा सर्भरसम्म पुग्दैन, र कुनैले पनि पहिले नै नचलिरहेको श्रोता बनाउन सक्दैन। UDP 1194 मा मात्र सुन्ने सर्भरविरुद्ध TCP 443 उल्लेख गर्ने प्रोफाइल पहिलो प्याकेटमै असफल हुन्छ।

त्यसैले एउटै फाइल दुई क्लाइन्टमा फरक व्यवहार गर्छ: फाइल माग्छ, र क्लाइन्टले अनुरोधको कति भाग पूरा गर्न सक्छ भनेर निर्णय गर्छ।

ट्रान्सपोर्ट लाइनहरू पहिले नै अवस्थित श्रोतासँग मिल्नुपर्छ

proto र remote लाइनहरू सर्भरले वास्तवमा बाँध्नेसँग मिल्नुपर्छ। UDP सामान्य विकल्प हो किनकि हराएको डेटाग्रामले टनेल रोक्दैन, जबकि TCP टनेलभित्रको लामको टाउको अवरोधको मूल्यमा प्रतिबन्धित नेटवर्कमा टिक्न सक्छ। प्रोफाइल UDP बाट TCP मा बदल्दा सर्भरले TCP स्वीकार गर्दैन; यसले क्लाइन्टलाई कोही नपढ्ने पोर्टमा पठाउन मात्र गर्छ।

पोर्ट 443 लोकप्रिय छ किनकि यो लगभग अरू केही नदिने नेटवर्कहरूबाट जान्छ, र यो OpenVPN सत्र नै रहन्छ, HTTPS अनुरोध होइन। अपरेटरले धेरै remote लाइन प्रकाशित गरेमा क्लाइन्टले ती क्रममा प्रयास गर्छ, जो लोड-ब्यालेन्सिङ निर्णय नभई फेलओभर सूची हो। अपरेटरले दिएका संयोजन राख्नुहोस्, एउटा प्रविष्टिको होस्ट अर्कोको पोर्टसँग मिसाउनुको सट्टा।

एम्बेड गरिएका कुञ्जीहरूले फाइल ह्यान्डल गर्ने तरिका बदल्छन्

प्रमाणपत्र र कुञ्जीहरू <ca>, <cert> र <key> ट्यागहरूबीच इनलाइन हुन सक्छन्, वा छुट्टै फाइलका रूपमा सन्दर्भित हुन सक्छन्। इनलाइन सामग्रीले प्रोफाइललाई आत्मनिर्भर बनाउँछ र यसलाई गोप्य पनि बनाउँछ, किनकि क्लाइन्टको निजी कुञ्जी यसभित्र यात्रा गर्छ। CA प्रमाणपत्र सार्वजनिक विश्वास सामग्री हो र साझा गर्न सुरक्षित छ; निजी कुञ्जी होइन, त्यो नपढिने पाठको ब्लकजस्तो देखिए पनि।

कुञ्जी जोगाउने पासफ्रेज खाता पासवर्डभन्दा छुट्टै गोप्य हो, र दुवै मिसाउँदा गलत प्रमाणजस्तो देखिने प्रमाणीकरण असफलता हुन्छ।

रुट र DNS फाइलबाटै नआउन पनि सक्छन्

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

DNS ले पनि त्यही ढाँचा पछ्याउँछ: धकेलिएको dhcp-option DNS क्लाइन्टले लागू गर्न सक्छ, बेवास्ता गर्न सक्छ, वा स्थानीय रिजोल्भर प्रबन्धकले त्यसलाई ओभरराइड गर्न सक्छ। प्रोफाइल फेरि पढ्नुको सट्टा जडान भएपछि रिजोल्भरको अवस्था जाँच्नुहोस्।

असमर्थित विकल्पहरू क्लाइन्ट संस्करणको प्रश्न हो

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

तुलनाका लागि मूल फाइल राख्नुहोस्, तपाईंको अनुरोधमा ठ्याक्कै असमर्थित निर्देश लेख्नुहोस्, र तपाईंले वास्तवमै चलाउनुहुने क्लाइन्टका लागि बनाइएको प्रोफाइल माग्नुहोस्।

कुनै पनि प्रतिस्थापनपछि, एपले कुन प्रोफाइल प्रविष्टि प्रयोग गरिरहेको छ पुष्टि गर्नुहोस्, किनकि नयाँ फाइल आयात गर्दा पुरानो सधैं ओभरराइट हुँदैन।