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 पर बातचीत नहीं करना चाहता, तो यह एक निष्कर्ष है, वरीयता नहीं। यदि टनल ऐसा सूट सूचीबद्ध करता है जिसकी आपको अपेक्षा नहीं थी, तो महत्वपूर्ण कॉन्फ़िगरेशन वही है जो सहकर्मियों ने चुना, न कि टेम्पलेट वाला।
सहकर्मी पहचान एक अलग प्रश्न है
सत्यापित सहकर्मी के बिना एन्क्रिप्शन ट्रैफ़िक को देखने वालों से बचाता है और उसे उसी को सौंप देता है जिसने कनेक्शन का उत्तर दिया। सहकर्मी प्रमाणीकरण पूछता है कि किस पहचान की अपेक्षा है, कौन-सी विश्वास सामग्री उसे प्रमाणित करती है, और जब उत्तर मेल न खाए तो क्लाइंट कैसा व्यवहार करता है। प्रमाणपत्र श्रृंखला, पिन किया गया कुंजी और पहले से साझा रहस्य तीन भिन्न उत्तर हैं जिनकी तीन भिन्न परिचालन लागतें हैं।
फिर उपयोगकर्ता या डिवाइस के बारे में वही प्रश्न पूछें। जो गेटवे मशीन का प्रमाणीकरण करके किसी भी उपयोगकर्ता को प्रवेश देता है, या उल्टा करता है, उसकी एक विशिष्ट स्थिति है जिसे लिखा जाना चाहिए, न कि मान लिया जाना। प्रवेश के बाद लागू संसाधन अनुमतियाँ उसी क्षेत्र का हिस्सा हैं, क्योंकि प्रमाणीकरण प्राधिकरण नहीं है।
होस्टनेम और प्रमाणपत्र जाँचों को बनाए रखना लॉगिन विंडो की परिचितता से अधिक महत्वपूर्ण है। सत्यापन अनदेखा करने के लिए कॉन्फ़िगर क्लाइंट ने वह अकेला कदम हटा दिया है जो आपके गेटवे को एक विश्वसनीय नकल से अलग करता है।
वह सीमा जो उत्पाद उजागर करता है
क्लाइंट-रहित पोर्टल चुने हुए एप्लिकेशन संचालनों को गेटवे से प्रॉक्सी करता है, इसलिए उपयोगकर्ता नेटवर्क नहीं बल्कि इंटरफ़ेस तक पहुँचता है। पूर्ण-टनल क्लाइंट वह ढोता है जो उसके मार्ग और फ़िल्टरिंग नीति चुनते हैं, जो कहीं बड़ी सतह है। दोनों की तुलना प्रोटोकॉल शक्ति पर करना यह अंतर छोड़ देता है कि हमलावर उनके ज़रिए क्या पहुँच सकता है। एक एप्लिकेशन इंटरफ़ेस उजागर करता है, दूसरा मार्गित नेटवर्क, और दोनों भिन्न समीक्षाएँ माँगते हैं।
पूछें कि कौन-सी सेवा उजागर है, कौन-से संचालन अधिकृत हैं और गेटवे स्वयं किस पर सुनता है। उपयोगकर्ता पोर्टल के उसी पते से पहुँचने योग्य प्रबंधन इंटरफ़ेस परिनियोजन का निष्कर्ष है, और कोई प्रोटोकॉल चयन उसकी भरपाई नहीं करता।
प्रति-एप्लिकेशन दायरा सतह को और सीमित करता है, और टनल गिरने पर विफलता का व्यवहार भी बदलता है। पूर्ण-टनल पहुँच मान लेने वाला डिज़ाइन उन तरीकों से टूटता है जो प्रति-ऐप डिज़ाइन नहीं जानता, और सहायता भार उसके पीछे आता है।
विफलता का परिणाम और जीवनचक्र तय करें
जब प्रमाणीकरण या सुरक्षा उपलब्ध न हो तो क्या होता है, यह एक नीति निर्णय है जो समीक्षा में आता है। अवरुद्ध परिणाम और बिना घोषणा वाला सीधा वापसी के भिन्न परिणाम होते हैं, और अंतर किसी विशेषता सूची में अदृश्य है। इच्छित व्यवहार उस संसाधन के साथ लिखें जिसकी वह रक्षा करता है।
गेटवे का पैच और सहायता जीवनचक्र, उसकी सक्रिय बाहरी सुविधाएँ और क्लाइंट के लिए अद्यतन पथ शामिल करें। सही प्रोटोकॉल चयन खराब परिनियोजित सेवा को सुरक्षित नहीं बनाता, और अधिकांश घटनाएँ सूट में नहीं बल्कि उसी अंतराल में रहती हैं।
पाँच क्षेत्र, विफलता नीति और जीवनचक्र का स्वामी एक पृष्ठ पर लिखें। वह पृष्ठ एक समीक्षा है; प्रोटोकॉल परिवारों की तुलना एक राय है।