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"त्यसपछि बाँकी प्रश्न ती हुन् जसको कुनै लेबलले उत्तर दिँदैन। कुन प्रोटोकल संस्करण अझै स्वीकारिन्छन्, गेटवेको पहिचान कसरी प्रमाणित हुन्छ, कुन एल्गोरिदम सेट अनुमति छ, कसले निश्चित प्रयोगकर्तालाई निश्चित स्रोतका लागि अधिकार दिन्छ, र यन्त्र हराउँदा केले पहुँच रद्द गर्छ। टोपोलोजी रेखाचित्र र मेकानिज्म-नाम त्यो सूचीको सुरुवात हो, त्यसको विकल्प होइन।
त्यसैले दुई लेबल राख्नुहोस्, तर तिनलाई जे हुन् त्यसैका लागि प्रयोग गर्नुहोस्: कुन अन्त्य बिन्दु जोडिन्छन् र सुरुङ कसरी बन्छ भन्ने बताउने छोटो बाटो। जुन क्षण एउटालाई अर्को बहिष्कार गर्न प्रयोग गरिन्छ, वर्णनले केही पनि वर्णन गर्न छाड्छ।