TLS VPN बनाम IPsec: जाँच गर्न लायक पाँच क्षेत्र
TLS VPN र IPsec VPN लाई रिलिज, प्रोटोकल संस्करण, सूट, सहकर्मी पहिचान र खुला दायराका आधारमा तुलना गर्नुहोस्, साथै तपाईंले वास्तवमै कन्फिगर गर्नुभएको असफलता-नतिजाका आधारमा।
TLS VPN लाई IPsec VPN सँग प्रोटोकल परिवारका आधारमा क्रमबद्ध गर्नु भनेको कसैले नसोधेको प्रश्नको उत्तर दिनु हो, र सामान्यतया दुवै परिवारले वर्षौं अघि छोडेको संरचनाको उल्लेख गर्छ। समीक्षकले वास्तवमै मूल्याङ्कन गर्न सक्ने कुरा भनेको वार्ताबाट तय भएको सुरक्षा, सहकर्मीको पहिचान, क्लाइन्ट मोडेल र खुला सेवा हो। यी चार कुरा परिनियोजनमा देखिन्छन्, र कुनै पनि उत्पादनको लेबलबाट आउँदैन। पाँच क्षेत्र माग्नुहोस् र कुराकानी ठोस हुन्छ।
पाँच क्षेत्र, र लेबल तीमध्ये एक होइन
पहिलो क्षेत्र समर्थित सफ्टवेयर रिलिज हो, किनकि संस्करण बिना प्रोटोकलको विवरण विज्ञापन पुस्तिका हो। दोस्रो वार्ताबाट तय भएको प्रोटोकल संस्करण हो, जसले कुन संरचना उपलब्ध छन् भन्ने तय गर्छ। तेस्रो सुरक्षा सूट हो, चौथो सहकर्मी र प्रयोगकर्ता दुवैका लागि प्रमाणीकरण विधि हो, र पाँचौं त्यो पहुँच दायरा हो जो उत्पादनले प्रवेशपछि दिन्छ।
SSL VPN लेबलले कम्तीमा तीन फरक उत्पादन समेट्छ: पूरा नेटवर्क क्लाइन्ट, अनुप्रयोग प्रोक्सी र ब्राउजरमा आधारित पुरानो पोर्टल। ती फरक सेवा खोल्छन् र फरक तरिकाले असफल हुन्छन्, त्यसैले लेबलले दायराको क्षेत्रलाई प्रतिस्थापन गर्न सक्दैन।
| Field | What a usable answer looks like |
|---|---|
| Release | A version with a support window, not a family name |
| Protocol version | TLS 1.3 or IKEv2 with the ESP suite named |
| Protection suite | An authenticated-encryption algorithm, not a cipher list |
| Authentication | Peer identity plus user or device identity, separately |
| Access scope | The services reachable after admission |
प्रमाणित इन्क्रिप्शनले वास्तवमा के बदल्छ
TLS 1.3 ले प्रमाणित इन्क्रिप्शन अनिवार्य गर्छ, जसले पुरानो MAC-then-encrypt संरचनालाई वैकल्पिक राख्नुको सट्टा प्रोटोकलबाट हटाउँछ। IPsec ESP मा पनि त्यतिकै समयदेखि प्रमाणित इन्क्रिप्शन सूट छन्, र AES-GCM आफ्नै RFC मा परिभाषित छ। दुवै परिवारमा ग्यारेन्टी परिवारको नामबाट नभई तय भएको सूटबाट आउँछ, त्यसैले क्षेत्र सूची संस्करणबाट सुरु हुन्छ। जसले सूटको नाम भन्न सक्दैन, उससँग मूल्याङ्कन गर्न केही छैन।
त्यसैले ऐतिहासिक तुलना भ्रमित गर्ने हो। CBC सूटसँग पुरानो TLS संस्करणमा अड्किएको परिनियोजन र AEAD सूटसँग TLS 1.3 चलाउने परिनियोजन एउटै सुरक्षा अवस्था होइनन्, यद्यपि दुवै TLS VPN हुन्। त्यही विभाजन IPsec पक्षमा आधुनिक ESP सूट र पुरानो संयोजनबीच पनि छ।
आफ्नो मनसायको कन्फिगरेसन नभई तय भएका मानहरू पढ्नुहोस्। तलका आदेशहरूले जीवित अन्त्य बिन्दु र जीवित टनेल वास्तवमै केमा सहमत भए देखाउँछन्।
openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sasयदि अन्त्य बिन्दुले TLS 1.3 मा वार्ता गर्न चाहँदैन भने त्यो निष्कर्ष हो, प्राथमिकता होइन। यदि टनेलले तपाईंले अपेक्षा नगरेको सूट सूचीबद्ध गर्छ भने महत्त्वपूर्ण कन्फिगरेसन त्यही हो जो सहकर्मीहरूले छाने, टेम्प्लेटको होइन।
सहकर्मी पहिचान छुट्टै प्रश्न हो
प्रमाणित सहकर्मी बिना इन्क्रिप्शनले ट्राफिकलाई अवलोकनकर्ताबाट जोगाउँछ र त्यो जसले जडानको जवाफ दियो उसैलाई सुम्पन्छ। सहकर्मी प्रमाणीकरणले कुन पहिचानको अपेक्षा छ, कुन विश्वास सामग्रीले त्यसलाई प्रमाणित गर्छ, र जवाफ नमिल्दा क्लाइन्ट कसरी व्यवहार गर्छ भनी सोध्छ। प्रमाणपत्र शृंखला, पिन गरिएको कुञ्जी र पहिल्यै साझा गरिएको रहस्य तीन फरक जवाफ हुन् जसका तीन फरक सञ्चालन लागत छन्।
त्यसपछि प्रयोगकर्ता वा उपकरणबारे तीही प्रश्न सोध्नुहोस्। जुन गेटवेले मेसिन प्रमाणित गरी जुनसुकै प्रयोगकर्तालाई प्रवेश दिन्छ, वा उल्टो गर्छ, त्यसको एक विशिष्ट अवस्था छ जो लेख्नुपर्छ, अनुमान गर्नुहुँदैन। प्रवेशपछि लागू हुने स्रोत अनुमतिहरू त्यही क्षेत्रको भाग हुन्, किनकि प्रमाणीकरण अधिकार होइन।
होस्टनाम र प्रमाणपत्र जाँच कायम राख्नु लगइन विन्डोको परिचितभन्दा महत्त्वपूर्ण छ। प्रमाणीकरण बेवास्ता गर्न कन्फिगर गरिएको क्लाइन्टले तपाईंको गेटवेलाई विश्वासिलो नक्कलबाट छुट्याउने एकमात्र कदम हटाएको छ।
उत्पादनले खोल्ने सीमा
क्लाइन्टरहित पोर्टलले छानिएका अनुप्रयोग क्रियाकलाप गेटवेमार्फत प्रोक्सी गर्छ, त्यसैले प्रयोगकर्ता नेटवर्क नभई इन्टरफेसमा पुग्छ। पूर्ण-टनेल क्लाइन्टले आफ्ना मार्ग र फिल्टरिङ नीतिले छान्ने कुरा बोक्छ, जो धेरै ठूलो सतह हो। दुवैको तुलना प्रोटोकल शक्तिमा गर्दा आक्रमणकारीले तिनीहरूमार्फत के पुग्न सक्छ भन्ने फरक छुट्छ। एउटाले अनुप्रयोग इन्टरफेस खोल्छ, अर्कोले मार्गित नेटवर्क, र दुवैले फरक समीक्षा माग्छन्।
कुन सेवा खुला छ, कुन क्रियाकलाप अधिकृत छन् र गेटवे आफैं के सुन्छ भनी सोध्नुहोस्। प्रयोगकर्ता पोर्टलकै ठेगानाबाट पुग्न सकिने व्यवस्थापन इन्टरफेस परिनियोजनको निष्कर्ष हो, र कुनै प्रोटोकल छनोटले त्यसको क्षतिपूर्ति गर्दैन।
प्रति-अनुप्रयोग दायराले सतह अझ साँघुरो बनाउँछ, र टनेल खस्दा असफलताको व्यवहार पनि बदल्छ। पूर्ण-टनेल पहुँच मान्ने डिजाइन प्रति-एप डिजाइनले नजान्ने तरिकाले टुट्छ, र सहयोग भार त्यसपछि आउँछ।
असफलताको नतिजा र जीवनचक्र तय गर्नुहोस्
प्रमाणीकरण वा सुरक्षा उपलब्ध नहुँदा के हुन्छ भन्ने नीति निर्णय समीक्षामा पर्छ। अवरुद्ध नतिजा र घोषणा नगरिएको सिधा फर्काइका फरक परिणाम हुन्छन्, र फरक विशेषता सूचीमा अदृश्य हुन्छ। इच्छित व्यवहार त्यसले जोगाउने स्रोतको छेउमा लेख्नुहोस्।
गेटवेको प्याच र सहयोग जीवनचक्र, यसका सक्रिय बाह्य सुविधा र क्लाइन्टका लागि अद्यावधिक मार्ग समावेश गर्नुहोस्। सही प्रोटोकल छनोटले नराम्रो परिनियोजित सेवा सुरक्षित बनाउँदैन, र अधिकांश घटना सूटमा नभई त्यही खाडलमा बाँच्छन्।
पाँच क्षेत्र, असफलता नीति र जीवनचक्रको मालिक एक पृष्ठमा लेख्नुहोस्। त्यो पृष्ठ एक समीक्षा हो; प्रोटोकल परिवारहरूको तुलना एक राय हो।