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