SSTP बनाम OpenVPN: वही पोर्ट 443, अलग प्रोटोकॉल

दोनों विकल्प TCP 443 के पीछे बैठ सकते हैं, इसलिए लोग मानते हैं कि वे विनिमेय एंडपॉइंट हैं। वे नहीं हैं: SSTP सर्वर HTTPS के अंदर PPP बोलता है, जबकि OpenVPN सर्वर TLS के ऊपर या कच्चे UDP प्रवाह से अपना प्रोटोकॉल बोलता है। एक क्लाइंट को दूसरे के पोर्ट पर भेजने से ऐसा कनेक्शन बनता है जो कभी लॉगिन प्रॉम्प्ट तक नहीं पहुँचता। चुनाव इस बात का है कि आप किस क्लाइंट और ट्रांसपोर्ट का समर्थन कर सकते हैं, नंबर का नहीं।

साझा पोर्ट साझा प्रोटोकॉल नहीं बनाता

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

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

पोर्ट 443 नीति की सुविधा है। यह ऐसे नेटवर्क से गुज़रता है जो बहुत कम और कुछ अनुमति देते हैं, और यह असली लाभ है, लेकिन यह इस बारे में कुछ नहीं बताता कि इसके पीछे कौन सा प्रोटोकॉल चल रहा है।

SSTP, HTTPS के अंदर PPP को टनल करता है

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

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

SSTP आमतौर पर केवल TCP होता है। वही एक ट्रांसपोर्ट प्रभावित करता है कि यह हानि वाली लिंक पर कैसे व्यवहार करता है, क्योंकि पुनःप्रेषण टनल के अंदर भी होता है और उसके नीचे भी।

OpenVPN अपना क्लाइंट और ट्रांसपोर्ट का चुनाव लाता है

OpenVPN अपना क्लाइंट और प्रोफ़ाइल देता है, जो आपको ऐसा निदान देता है जो मूल Windows संवाद नहीं दिखाता। सर्वर UDP या TCP पर सुन सकता है, और ऑपरेटर की कॉन्फ़िगरेशन तय करती है कि आपके क्लाइंट को कौन सा उपयोग करना है। गलत ट्रांसपोर्ट पर भेजी गई प्रोफ़ाइल प्रमाणीकरण से पहले विफल हो जाती है।

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

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

क्लाइंट, ट्रांसपोर्ट और सहायता के आधार पर चुनें

तीन प्रश्न इनमें से अधिकांश निर्णय तय करते हैं। क्या हर क्लाइंट डिवाइस को बिना अतिरिक्त सॉफ़्टवेयर के काम करने वाला कनेक्शन चाहिए? जिस नेटवर्क पर आप निर्भर हैं वह UDP की अनुमति देता है, या TCP 443 ही एकमात्र निकास है? और जब प्रोफ़ाइल समाप्त हो जाए तो क्लाइंट, उसके अपडेट और उसकी रिकवरी का समर्थन कौन करता है?

जब आप दोनों की तुलना करें, तो उसी डिवाइस और उसी एक्सेस नेटवर्क पर परीक्षण करें। यदि SSTP एंडपॉइंट और OpenVPN एंडपॉइंट अलग सर्वर या अलग साइट हैं, तो आपके परिणाम में प्रोटोकॉल को अलग करने के बजाय वे मार्ग और मशीनें शामिल होती हैं। यही सबसे आम तरीका है जिससे ऐसी तुलनाएँ आत्मविश्वास से भरा पर गलत उत्तर देती हैं।

फिर कुछ और डीबग करने से पहले पुष्टि करें कि आपने वास्तव में कौन सा स्थापित किया:

> Get-VpnConnection -Name "Office SSTP" | Select-Object TunnelType, ServerAddress
> openvpn --config office.ovpn --verb 4

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

प्रबंधित फ़्लीट में, प्रोफ़ाइल वितरण और अपडेट सहायता आमतौर पर किसी भी ट्रांसपोर्ट बेंचमार्क से बहुत पहले यह प्रश्न तय कर देते हैं।