OpenVPN प्रोफ़ाइल SoftEther में क्यों आयात नहीं होती

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

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

OpenVPN प्रोफ़ाइल एक क्लाइंट कॉन्फ़िगरेशन है: दूरस्थ एंडपॉइंट, ट्रांसपोर्ट, TLS सामग्री, और रूटिंग तथा पुनः बातचीत के लिए निर्देश। SoftEther कनेक्शन वर्चुअल हब के सामने एक मूल क्लाइंट सत्र है, जिससे एक वर्चुअल एडाप्टर जुड़ा रहता है।

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

फ़ाइल का एक्सटेंशन आपको लगभग कुछ नहीं बताता, इसलिए ऑपरेटर का उत्तर फ़ाइल के नाम से अधिक मायने रखता है।

प्रमाणपत्र ब्लॉक छूने से पहले सर्वर पढ़ें

ऑपरेटर से तीन बातें पूछें: कौन-सा पोर्ट और ट्रांसपोर्ट, कौन-सी प्रमाणीकरण विधि, और वे किस क्लाइंट के उपयोग की अपेक्षा करते हैं। ये उत्तर अधिकांश अनुमान हटा देते हैं।

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

ss -lunp | grep -E ':1194|:443'
sudo ss -ltnp | grep -E ':992|:5555'
grep -nE '^(remote|proto|auth-user-pass|ca |cert |key )' profile.ovpn

श्रोता सूची से गायब UDP पोर्ट एक निष्क्रिय सुविधा है, फ़ायरवॉल की समस्या नहीं।

मूल क्लाइंट को क्या चाहिए और प्रोफ़ाइल क्या नहीं दे सकती

मूल क्लाइंट एक वर्चुअल नेटवर्क एडाप्टर स्थापित करता है और उससे कनेक्शन बाँधता है। उस एडाप्टर के बिना रूट करने के लिए कोई इंटरफ़ेस नहीं होता, इसलिए मूल कनेक्शन प्रमाणीकृत हो सकता है और फिर भी कोई ट्रैफ़िक नहीं ढोता।

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

निजी कुंजी को किसी भी रूपांतरण सेवा से दूर रखें, क्योंकि मशीन छोड़ने वाली कुंजी को उजागर मानना पड़ता है।

OpenVPN-संगत श्रोता क्या स्वीकार करता है

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

जो यह नहीं करेगा वह है मूल SoftEther प्रोफ़ाइल स्वीकार करना, क्योंकि वह प्रोफ़ाइल OpenVPN कॉन्फ़िगरेशन नहीं है। श्रोता मूल क्लाइंट को OpenVPN क्लाइंट में भी नहीं बदलता। यदि ऑपरेटर केवल मूल सेवा देता है, तो उत्तर मूल क्लाइंट है; यदि वह संगतता श्रोता देता है, तो उत्तर OpenVPN और उसकी अपनी सामग्री है।

ऑपरेटर का समर्थित निर्यात माँगें टुकड़ों से एक जोड़ने के बजाय, क्योंकि निर्यात में वे विवरण होते हैं जो हाथ से बनी फ़ाइल आमतौर पर छोड़ देती है।

निर्देश संपादित करने से पहले पथ सिद्ध करें

क्लाइंट चुन लिए जाने के बाद, रूट छूने से पहले सुरंग जाँचें। सफल लॉगिन और ट्रैफ़िक ढोने वाला इंटरफ़ेस दो अलग परिणाम हैं।

sudo openvpn --config profile.ovpn --verb 3
ip -br addr
ip route get 10.70.4.20
resolvectl status | grep -A2 'DNS Servers'

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