.ovpn फ़ाइल में वास्तव में क्या होता है, और वह क्या नहीं कर सकती

ज़्यादातर लोग मानते हैं कि .ovpn फ़ाइल VPN कॉन्फ़िगर करती है। ऐसा नहीं है: यह एक क्लाइंट कॉन्फ़िगर करती है, और जो कुछ भी वह माँगती है वह दूसरी तरफ़ पहले से मौजूद होना चाहिए। फ़ाइल में एक पंक्ति बदलने से बदल सकता है कि आपकी मशीन क्या आज़माती है, कभी नहीं कि सर्वर क्या पेश करता है। यही अंतर उन प्रोफ़ाइलों के बारे में ज़्यादातर उलझन समझाता है जो आयात या कनेक्ट नहीं हो पातीं।

फ़ाइल को अपने क्लाइंट को संबोधित अनुरोधों की सूची की तरह पढ़ें, और उसकी ज़्यादातर पंक्तियाँ स्पष्ट हो जाएँगी।

फ़ाइल आपके क्लाइंट का वर्णन करती है, सर्वर का नहीं

एक प्रोफ़ाइल remote एंडपॉइंट, एक ट्रांसपोर्ट, एक इंटरफ़ेस प्रकार, पहचान सामग्री और ऑपरेटर की चाही हुई किसी भी क्लाइंट-पक्षीय व्यवहार को एक साथ जोड़ती है। हर पंक्ति क्लाइंट द्वारा शुरू होने पर निष्पादित होती है। इनमें से कोई भी कॉन्फ़िगरेशन परिवर्तन के रूप में सर्वर तक नहीं पहुँचती, और कोई भी ऐसा श्रोता नहीं बना सकती जो पहले से न चल रहा हो। ऐसी प्रोफ़ाइल जो TCP 443 बताती है उस सर्वर के सामने जो केवल UDP 1194 पर सुनता है पहले ही पैकेट पर विफल हो जाती है।

इसीलिए वही फ़ाइल दो क्लाइंट पर अलग व्यवहार करती है: फ़ाइल माँगती है, और क्लाइंट तय करता है कि अनुरोध का कितना हिस्सा वह पूरा कर सकता है।

ट्रांसपोर्ट पंक्तियों को उस श्रोता से मेल खाना चाहिए जो पहले से मौजूद हो

proto और remote पंक्तियों को उससे मेल खाना चाहिए जो सर्वर वास्तव में बाँधता है। UDP सामान्य विकल्प है क्योंकि खोया डेटाग्राम टनल को रोकता नहीं, जबकि TCP टनल के भीतर हेड-ऑफ़-लाइन ब्लॉकिंग की कीमत पर प्रतिबंधित नेटवर्क में टिक सकता है। प्रोफ़ाइल को UDP से TCP में बदलने से सर्वर TCP स्वीकार नहीं करता; यह केवल क्लाइंट को ऐसे पोर्ट पर भेजता है जिसे कोई नहीं पढ़ता।

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

एम्बेडेड कुंजियाँ फ़ाइल को संभालने का तरीका बदल देती हैं

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

कुंजी की रक्षा करने वाला पासफ़्रेज़ खाता पासवर्ड से अलग रहस्य है, और दोनों को मिलाने से प्रमाणीकरण विफलता होती है जो ग़लत क्रेडेंशियल जैसी लगती है।

रूट और DNS शायद फ़ाइल से ही न आएँ

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

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

असमर्थित विकल्प क्लाइंट संस्करण का सवाल है

आयात चेतावनियों का आम मतलब है कि क्लाइंट कोई निर्देश लागू नहीं करता, यह नहीं कि फ़ाइल ख़राब है। डेस्कटॉप क्लाइंट दस्तावेज़ित नियंत्रणों के अंतर्गत स्क्रिप्ट और प्लगइन चला सकते हैं, जबकि मोबाइल क्लाइंट सीमित समुच्चय स्वीकार करते हैं और जिन पंक्तियों को वे समझते नहीं उन्हें चुपचाप छोड़ सकते हैं। पुराने क्लाइंट द्वारा अस्वीकृत साइफ़र या TLS सेटिंग संस्करण की समस्या है जिसे ऑपरेटर के साथ सुलझाना है। अनजान विशेषाधिकार चालू करके आयात थोपने से चेतावनी के बदले व्यापक आक्रमण-सतह मिलती है।

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

किसी भी प्रतिस्थापन के बाद पुष्टि करें कि ऐप कौन-सी प्रोफ़ाइल प्रविष्टि इस्तेमाल कर रहा है, क्योंकि नई फ़ाइल आयात करना पुरानी को हमेशा नहीं लिखता।