.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 सेटिंग ही आवृत्तीची समस्या आहे, ती ऑपरेटरसोबत सोडवावी लागते। अनोळखी विशेषाधिकार सुरू करून आयात सक्तीने करणे म्हणजे इशाऱ्याच्या बदल्यात मोठी हल्ला-पृष्ठभाग घेणे.

तुलनेसाठी मूळ फाइल ठेवा, तुमच्या विनंतीत नेमका असमर्थित निर्देश लिहा, आणि तुम्ही प्रत्यक्षात चालवत असलेल्या क्लायंटसाठी तयार केलेले प्रोफाइल मागा.

कोणत्याही बदलीनंतर, ॲप कोणती प्रोफाइल नोंद वापरत आहे ते तपासा, कारण नवीन फाइल आयात केल्याने जुनी नेहमीच ओव्हरराइट होत नाही.