SSL VPN या TLS रैपर? उस सीमा की तुलना करें जो विफल हुई

दो डिज़ाइन 443 पोर्ट पर TLS चला सकते हैं और उससे पूरी तरह अलग बातें कह सकते हैं। एक रैपर स्थानीय पोर्ट और दूरस्थ बैकएंड के बीच एक कॉन्फ़िगर किए गए कनेक्शन की रक्षा करता है। नेटवर्क-एक्सेस डिज़ाइन चुना हुआ ट्रैफ़िक ले जाता है और बदल देता है कि क्लाइंट कहाँ तक पहुँच सकता है। नीचे दी गई चार जाँचें क्रम से करें और आप जान जाएँगे कि आप किसे देख रहे हैं, जो आमतौर पर यह जानने के लिए पर्याप्त होता है कि कौन-सी परत विफल हुई।

उस कनेक्शन से शुरू करें जो आपने वास्तव में कॉन्फ़िगर किया

उत्पादों की तुलना करने से पहले आगे का सिरा और पीछे का सिरा लिख लें। एक रैपर स्थानीय पते पर सुनता है और दूरस्थ पते पर भेजता है, या दूरस्थ पक्ष पर कोई प्रोग्राम शुरू करता है, और वही जोड़ी उसका पूरा अनुबंध है। क्लाइंट के बाकी एप्लिकेशन इसके बारे में कुछ नहीं जानते, जब तक आप उन्हें इसकी ओर न भेजें। यह उपकरण की कमी नहीं है, उपकरण इसी के लिए है।

नेटवर्क डिज़ाइन का अनुबंध अलग है, और वह पोर्ट-जोड़ी में नहीं, मार्गों और नीति में व्यक्त होता है।

ध्यान दें कि उन दो विवरणों में से कौन आपके आरेख से मेल खाता है। यदि उत्तर बीच में प्रमाणपत्र वाला एक पोर्ट मैपिंग है, तो आपके पास रैपर है, भले ही उत्पाद का नाम VPN कहे। यदि उत्तर टनल इंटरफ़ेस और मार्ग परिवर्तन हैं, तो आपके पास नेटवर्क डिज़ाइन है, भले ही वह 443 पर चलता हो।

जाँचें कि रैपर किससे जुड़ता है

सुनने और जुड़ने की सेटिंग्स पढ़ें और उन्हें असली बैकएंड तक ले जाएँ। डेटाबेस पोर्ट पर भेजने वाला रैपर कोई वेब एप्लिकेशन नहीं खोलता, और प्रोग्राम चलाने वाला रैपर उसी प्रोग्राम को शुरू करता है, होस्ट के बाकी सब कुछ को प्रकाशित करने के बजाय। बैकएंड ही एकमात्र चीज़ है जो रैपर जानता है।

फिर तय करें कि TLS खत्म होने के बाद भेजी गई स्ट्रीम सादा पाठ है या नहीं। रैप किया गया कनेक्शन दो रैपरों के बीच के खंड की रक्षा करता है, और दूरस्थ रैपर के बाद क्या होता है वह अलग प्रश्न है। इसलिए जो पहले से अपनी सुरक्षा लिए है उसे रैप करना कभी समझदारी है और कभी केवल अतिरिक्त चलते भाग। दोनों उत्तरों में से कोई मान लेने के बजाय अगली छलांग जाँचें।

openssl s_client -connect wrapper.lab.example:443 -servername wrapper.lab.example -verify_return_error
sudo ss -ltnp | grep 443

पहला कमांड दिखाता है कि क्लाइंट को वास्तव में कौन-सा प्रमाणपत्र दिया जा रहा है, और दूसरा दिखाता है कि होस्ट पर कौन सुन रहा है। कोई और चीज़ पढ़ने से पहले उस प्रमाणपत्र के नाम की तुलना अपेक्षित नाम से करें।

जाँचें कि डिज़ाइन कौन-सा ट्रैफ़िक ले जाता है

नेटवर्क-एक्सेस डिज़ाइन चुना हुआ ट्रैफ़िक ले जाते हैं और क्लाइंट के रूटिंग और एक्सेस नीति के साथ एकीकृत होते हैं। प्रवेश अधिकृति नहीं है, इसलिए प्रमाणित कनेक्शन को अब भी यह तय करना होता है कि वह किन संसाधनों तक पहुँच सकता है। क्लाइंट-रहित पोर्टल तीसरा मॉडल है जो समर्थित क्रियाओं को प्रॉक्सी करता है पर कभी tun इंटरफ़ेस के रूप में नहीं दिखता।

उत्पाद का लेबल नहीं बताता कि आपने इनमें से कौन-सा मॉडल खरीदा, और पोर्ट संख्या और भी कम बताती है।

स्तर बनाना संभव है और उसे तुलना को उलझाना नहीं चाहिए। एक टनल प्रोटोकॉल स्वयं समर्थित TCP व्यवस्था में TLS में लिपटा जा सकता है, जो टनल के चारों ओर एक परत जोड़ता है पर रैपर को टनल नहीं बनाता। यह अपने प्रदर्शन और विफलता व्यवहार वाला डिज़ाइन निर्णय है, और आरेख में एक पंक्ति का हक़दार है। इसे दर्ज करें, फिर बाहरी रैपर नहीं, अंतर्निहित मॉडलों की तुलना करें।

विफल सीमा जाँचें, लेबल नहीं

एक विफल प्रयास के तथ्य लिखें: आगे का पता, श्रोता, वह पहचान जो क्लाइंट ने सत्यापित की, बैकएंड लक्ष्य और अनुरोधित क्रिया। सफल हैंडशेक सिद्ध करता है कि बाहरी TLS पूरा हुआ और बैकएंड के बारे में कुछ नहीं कहता। बैकएंड का अस्वीकार आगे की पहचान विफलता से अलग घटना है, और क्लाइंट से -verify_return_error हटाने से दोनों में से कोई सुधरता नहीं। समान की समान से तुलना करें, क्योंकि किसी दूसरे होस्टनाम या पोर्ट से सफलता यह नहीं दिखाती कि परिस्थितियाँ एक जैसी थीं।

443 पोर्ट एक परंपरा है जो TLS को बीच के बक्सों से गुजरने देती है। यह मनमाने ट्रैफ़िक को नीति उपकरण के लिए वेब अनुरोध जैसा नहीं बनाती।

एक वाक्य से समाप्त करें जो अंतिम जोड़ी, क्या ले जाया जाता है, कौन-से एप्लिकेशन इसका उपयोग करते हैं और गंतव्य कौन-सी अनुमति लागू करता है, इनका नाम ले। जो डिज़ाइन उन चार खाली स्थानों को नहीं भर सकता वह पूरा नहीं है, चाहे उसका लेबल कुछ भी दावा करे। वही वाक्य फ़ायरवॉल के मालिक को डिज़ाइन समझाने का सबसे तेज़ तरीका भी है।