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'

नियुक्त केलेल्या पत्त्याची ऑपरेटरने वर्णन केलेल्या पूलशी तुलना करा, नंतर मार्ग आणि रिझोल्व्हर स्वतंत्रपणे पाहा। मूळ हब कनेक्शन स्वच्छपणे प्रमाणीकृत होऊ शकते आणि कोणतेही मार्ग स्थापित करू शकत नाही, जे क्लायंटच्या बाजूने तुटलेल्या बोगद्यासारखे दिसते। हे तिन्ही जुळल्यावरच सूचना संपादित करणे योग्य आहे। लवकर संपादन केल्यास कोणता स्तर चुकीचा होता हे लपते।