OpenVPN प्रोफ़ाइल की पोर्टेबिलिटी: पोर्टेबल कुंजियाँ बनाम प्लेटफ़ॉर्म विकल्प

वही .ovpn फ़ाइल एक क्लाइंट में सुरंग खोलती है और दूसरे में शुरू नहीं होती, और प्रमाणपत्र आमतौर पर पहला संदिग्ध होता है। अधिकतर फ़ाइल में ऐसा निर्देश होता है जिसे केवल एक इंजन लागू करता है। प्रोफ़ाइल किसी विशिष्ट क्लाइंट के साथ एक अनुबंध है, पोर्टेबल स्क्रिप्ट नहीं।

जो पहचान के साथ यात्रा करता है उसे उससे अलग करें जो किसी प्लेटफ़ॉर्म का है। तब विफलता आमतौर पर अपना नाम स्वयं बता देती है।

एक फ़ाइल, दो अनुबंध

एक प्रोफ़ाइल तीन प्रकार की सामग्री को एक साथ रखती है: पहचान सामग्री जैसे CA और क्लाइंट प्रमाणपत्र तथा निजी कुंजी, परिवहन तथ्य जैसे दूरस्थ एंडपॉइंट और प्रोटोकॉल, और व्यवहार निर्देश जैसे DNS प्रबंधन या डिवाइस विकल्प। पहले दो उन इंजनों के बीच व्यापक रूप से पोर्टेबल हैं जो एक ही प्रोटोकॉल का समर्थन करते हैं। तीसरा वह जगह है जहाँ कार्यान्वयन अलग हो जाते हैं। पूरी फ़ाइल को एक पोर्टेबल इकाई मानना ही भ्रमित करने वाली विफलताएँ पैदा करता है।

एक प्लेटफ़ॉर्म पर GUI में काम करने वाली फ़ाइल दूसरे प्लेटफ़ॉर्म पर कमांड-लाइन क्लाइंट के लिए स्वतः मान्य नहीं होती। जब दोनों OpenVPN हों तब भी पार्सर और विकल्प-समुच्चय अलग होते हैं। इसलिए सफल आयात पोर्टेबल प्रोफ़ाइल का प्रमाण नहीं है।

पोर्टेबल सामग्री बनाम प्लेटफ़ॉर्म निर्देश

पहचान और परिवहन खंड वह हिस्सा हैं जिन्हें सुरक्षित रखना है। ca, cert, key और remote बताते हैं कौन जुड़ रहा है और कहाँ, और वे हर अनुरूप क्लाइंट के लिए एक ही अर्थ रखते हैं।

व्यवहार निर्देश वह हिस्सा हैं जिनकी तुलना करनी है। block-outside-dns, उदाहरण के लिए, Windows में DNS व्यवहार बदलने के लिए मौजूद है। हो सकता है कि कोई Unix क्लाइंट इसे बिल्कुल न पहचाने।

प्राप्त करने वाले क्लाइंट की विकल्प सूची पढ़ें, भेजने वाले की नहीं। OpenVPN 2.6 संदर्भ मैनुअल इंजन के विकल्पों का दस्तावेज़ीकरण करता है, और किसी GUI का आयात संवाद वह सूची नहीं है।

प्रमाणपत्र से पहले पार्सर की त्रुटि पढ़ें

अपरिचित विकल्प का नाम लेने वाली त्रुटि पार्सर विफलता है, प्रमाणीकरण विफलता नहीं। कनेक्शन कभी TLS तक नहीं पहुँचा, इसलिए प्रमाणपत्र बदलने से मदद नहीं हो सकती। वास्तविक क्लाइंट और संस्करण से पहली त्रुटि पढ़ें, फिर केवल उसी निर्देश को हटाएँ या बदलें जिसे वह क्लाइंट लागू नहीं कर सकता। फ़ाइल लोड होने के लिए प्रमाणपत्र या रूट खंड मिटाना वह तरीका है जिससे काम करने वाला प्रोफ़ाइल असुरक्षित हो जाता है।

यदि त्रुटि हैंडशेक, प्रमाणपत्र या सिफ़र का उल्लेख करती है, तो प्रोफ़ाइल पार्स हो गया और समस्या कहीं और है।

मूल फ़ाइल को अनुकूलित फ़ाइल के पास रखें। जब अनुकूलित फ़ाइल बाद में विफल हो, तो मूल फ़ाइल वह नियंत्रण है जो बताती है कि बदलाव हिला या वातावरण।

विशेषाधिकार दूसरी सीमा हैं

विशेषाधिकार दूसरी सीमा हैं: सुरंग डिवाइस बनाना, रूट स्थापित करना और निजी कुंजी पढ़ना सभी स्थानीय अनुमतियों पर निर्भर हैं। केवल root द्वारा पढ़ी जा सकने वाली कुंजी फ़ाइल सामान्य परिनियोजन है, प्रोफ़ाइल की खराबी नहीं। सुधार स्वामित्व या क्षमताओं में है, फ़ाइल में नहीं।

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

सोच-समझकर अनुकूलन करें

जब कोई प्रदाता अलग-अलग प्रोफ़ाइल प्रकाशित करता है, तो वह लें जो प्राप्त करने वाले क्लाइंट के लिए बनाया गया है। किसी अन्य प्लेटफ़ॉर्म की फ़ाइल अनुकूलित करना अंतिम उपाय है। इसके लिए हर बदले गए विकल्प का रिकॉर्ड और मूल की प्रति चाहिए।

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