SSL VPN और साइट-टू-साइट VPN एक-दूसरे के विपरीत क्यों नहीं हैं
SSL VPN और साइट-टू-साइट VPN अलग-अलग अक्षों का वर्णन करते हैं: कौन नेटवर्क से जुड़ता है और टनल कैसे बनता है। दोनों को एक साथ कहना श्रेणी की भूल है।
दो प्रशासकों से एक ही VPN का वर्णन करने को कहें; एक शायद “SSL VPN” कहेगा जबकि दूसरा “साइट-टू-साइट” कहेगा, जैसे दोनों मेनू में प्रतिद्वंद्वी विकल्प हों। ये अलग-अलग सवालों के जवाब हैं, और इन्हें विकल्प मानने से ऐसी तुलनाएँ बनती हैं जिन्हें सुलझाया नहीं जा सकता। एक लेबल बताता है कि कौन-से छोर जोड़े जा रहे हैं; दूसरा बताता है कि उनके बीच ट्रैफ़िक क्या ले जाता है। अक्षों को अलग रखें और बहस का ज़्यादातर हिस्सा गायब हो जाएगा।
दो लेबल, दो अलग सवाल
टोपोलॉजी बताती है कि कौन किससे जुड़ता है। रिमोट-एक्सेस डिज़ाइन व्यक्तिगत उपयोगकर्ताओं या उपकरणों को गेटवे से जोड़ता है, आमतौर पर प्रति-उपयोगकर्ता पहचान और पतों के पूल के साथ। साइट-टू-साइट डिज़ाइन दो नेटवर्क को गेटवे के ज़रिए जोड़ता है, इसलिए दिलचस्प पहचान साथी गेटवे है, कीबोर्ड के सामने बैठा व्यक्ति नहीं। ये अलग-अलग परिचालन समस्याएँ हैं, पता योजना से लेकर रात 2 बजे कौन एक्सेस रद्द कर सकता है तक।
मेकैनिज़्म बताता है कि टनल कैसे बनता और प्रमाणित होता है। IKEv2 के साथ IPsec, अंदर IP ले जाने वाला TLS-आधारित उत्पाद, और ब्राउज़र की ओर का एप्लिकेशन पोर्टल मेकैनिज़्म के चुनाव हैं, और हर एक की अपनी बातचीत, सिफ़र सूट और विफलता के तरीके हैं। इनमें से कोई टोपोलॉजी नहीं बताता, और टोपोलॉजी मेकैनिज़्म नहीं चुनती।
दोनों अक्षों को एक तालिका में रखें और उलझन दिखने लगेगी, क्योंकि ग्रिड का हर सेल भरा जा सकता है। ग्रिड जो नहीं कर सकता वह है आपको बताना कि आपके विक्रेता ने कौन-सा संयोजन भेजा, क्योंकि उत्पाद नाम दोनों अक्षों को एक विपणन वाक्यांश में समेट देते हैं।
श्रेणी की भूल कहाँ से आती है
विक्रेताओं ने वर्षों तक “SSL VPN” को “IPsec VPN” का विपरीत बताकर बेचा, जिससे मेकैनिज़्म की तुलना टोपोलॉजी के चुनाव जैसी लगने लगी। यह वाक्यांश अपनी ही शर्तों पर बुरी तरह पुराना पड़ गया है, क्योंकि आज के डिज़ाइन समर्थित TLS संस्करणों का उपयोग करते हैं और SSL नाम मुख्य रूप से उत्पाद श्रेणी के रूप में बचा है।
| Axis | Question it settles | What it cannot tell you |
|---|---|---|
| Topology | Whether users join a gateway or two networks join each other | Which protocol carries the traffic, or how peers prove identity |
| Mechanism | Which protocol suite builds the tunnel and negotiates keys | Whether the endpoints are people, devices or routers |
| Access surface | Whether the client sees a routed network or a set of published applications | Which topology or mechanism is underneath the portal |
| Authentication | What proof each side presents, and to whom | Whether the traffic is later authorized per resource |
उसी संकुचन से दो जुड़े मिथक निकलते हैं। पहला यह है कि IPsec का मतलब साइट-टू-साइट है; IKEv2 क्लाइंट-से-गेटवे संबंधों के लिए भी बनाया गया था, इसलिए एक अकेला लैपटॉप IPsec से जुड़ सकता है। दूसरा यह है कि TLS-आधारित उत्पाद का मतलब केवल रिमोट एक्सेस है; OpenVPN नियमित रूप से दो साइटों के बीच ट्रैफ़िक ले जाने के लिए उपयोग होता है, और इसका TLS उपयोग ब्राउज़र सत्र में नहीं बल्कि नियंत्रण और प्रमाणीकरण की अदला-बदली में केंद्रित है।
किसी भी विवरण के लिए उपयोगी परीक्षा: यदि एक शब्द बदलने से छोर और प्रोटोकॉल दोनों बदल जाएँ, तो वाक्य अक्षों को मिला रहा है। “SSL VPN बनाम साइट-टू-साइट” इस परीक्षा में विफल है, क्योंकि पहला पद मेकैनिज़्म-परिवार बताता है और दूसरा टोपोलॉजी।
तैनाती का वर्णन ऐसे करें कि उसकी तुलना हो सके
चार खाने लिखें और भरें: छोर, मेकैनिज़्म, प्रमाणीकरण और एक्सेस-सतह। किसी शाखा लिंक को दो नामित प्रीफ़िक्स के बीच प्रमाणपत्र-प्रमाणीकरण सहित और उपयोगकर्ता-स्तरीय पोर्टल के बिना IKEv2 गेटवे-जोड़ी के रूप में पढ़ा जा सकता है। रिमोट-एक्सेस सेवा को प्रति-उपयोगकर्ता पते बाँटने वाले, लॉगिन पर दूसरा कारक माँगने वाले और केवल आंतरिक DNS ज़ोन प्रकाशित करने वाले TLS-आधारित क्लाइंट के रूप में पढ़ा जा सकता है।
ये वाक्य उस तरह तुलनीय हैं जिस तरह उत्पाद नाम नहीं। दो रिमोट-एक्सेस डिज़ाइनों को एक ही उपयोगकर्ता कार्यप्रवाह और एक ही रद्दीकरण पथ के विरुद्ध मापा जा सकता है, और दो अंतर-साइट डिज़ाइनों को एक ही प्रीफ़िक्स सूची, ट्रैफ़िक नीति और विफलता आवश्यकताओं के विरुद्ध। लेबल तुलना को व्यवस्थित करते हैं; उसकी जगह नहीं लेते।
शब्दावली का एक प्रकाशित आधार भी है। IETF का VPN शब्दावली दस्तावेज़ कई सेवा-मॉडलों को, जिनमें रिमोट एक्सेस और साइट-टू-साइट शामिल हैं, उन्हें बनाने में उपयोग होने वाले मेकैनिज़्म से अलग करता है, और यही वह भेद है जो बार-बार खो जाता है।
बातचीत तय प्रोटोकॉल पढ़ें, उत्पाद का नाम नहीं
डिब्बे पर का लेबल यह तय नहीं करता कि चल रहा टनल किस पर सहमत हुआ। TLS पक्ष पर साथी से सीधे पूछें और ब्रोशर के संस्करण के बजाय हैंडशेक द्वारा उत्पन्न प्रोटोकॉल संस्करण और सिफ़र पढ़ें।
openssl s_client -connect vpn.example.net:443 -tls1_3 -briefIPsec गेटवे के लिए समतुल्य अवलोकन कार्यान्वयन के अपने स्टेटस आउटपुट से आता है, जो उपयोग में IKE और ESP प्रस्तावों की रिपोर्ट करता है। किसी भी तरह, बात एक ही है: मेकैनिज़्म-अक्ष को जीवित सत्र से पढ़ना होगा, क्योंकि क्लाइंट और गेटवे दोनों प्रशासकों की अपेक्षा से पुराने किसी चीज़ पर नीचे बातचीत कर सकते हैं।
ipsec statusall | grep -E "IKE|ESP"इसके बाद बचे सवाल वे हैं जिनका कोई लेबल जवाब नहीं देता। कौन-से प्रोटोकॉल संस्करण अभी स्वीकार किए जाते हैं, गेटवे की पहचान कैसे सत्यापित होती है, कौन-सा एल्गोरिदम सेट अनुमत है, कौन दिए गए उपयोगकर्ता को दिए गए संसाधन के लिए अधिकृत करता है, और उपकरण खो जाने पर क्या एक्सेस रद्द करता है। टोपोलॉजी आरेख और मेकैनिज़्म नाम उस सूची की शुरुआत हैं, उसका विकल्प नहीं।
तो दोनों लेबल रखें, पर उन्हें वही समझकर उपयोग करें जो वे हैं: यह कहने का छोटा तरीका कि कौन-से छोर जोड़े जाते हैं और टनल कैसे बनता है। जिस पल एक को दूसरे से बाहर रखने के लिए उपयोग किया जाए, विवरण किसी चीज़ का वर्णन करना बंद कर देता है।