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"त्यानंतर उरलेले प्रश्न ते आहेत ज्यांचे कोणतेही लेबल उत्तर देत नाही. कोणत्या प्रोटोकॉल आवृत्त्या अजून स्वीकारल्या जातात, गेटवेची ओळख कशी सत्यापित होते, कोणता अल्गोरिदम संच परवानगी आहे, कोण विशिष्ट वापरकर्त्याला विशिष्ट संसाधनासाठी अधिकृत करतो, आणि उपकरण हरवल्यावर काय प्रवेश रद्द करते. टोपोलॉजी आकृती आणि यंत्रणा-नाव या यादीची सुरुवात आहे, तिचा पर्याय नाही.
म्हणून दोन्ही लेबल ठेवा, पण ती जे आहेत त्यासाठी वापरा: कोणते टोक जोडले जातात आणि टनेल कसा बांधला जातो हे सांगण्याचा छोटा मार्ग. ज्या क्षणी एक दुसऱ्याला वगळण्यासाठी वापरले जाते, तेव्हा वर्णन काहीही वर्णन करणे थांबवते.