क्या TLS रैपर आपको निजी नेटवर्क देता है? आमतौर पर नहीं

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

सेवा रैपर वास्तव में क्या जोड़ता है

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

इसलिए रैपर के बारे में उपयोगी सवाल यह नहीं है कि वह एन्क्रिप्ट करता है या नहीं, बल्कि यह है कि वह जो शृंखला बनाता है उसके हर सिरे पर क्या है।

application -> local listener -> TLS connection -> remote listener -> configured backend

उस शृंखला को मार्केटिंग नाम से नहीं, कॉन्फ़िगरेशन से पढ़ें। हर तीर अपने पते और अपने एक्सेस नियमों वाला एक अलग नेटवर्क हॉप है।

पता लगाएँ कि TLS चैनल कहाँ समाप्त होता है

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

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

ss -ltnp | grep -F 443
openssl s_client -connect svc.example.net:443 -servername svc.example.net </dev/null | openssl x509 -noout -subject -dates

पहला कमांड दिखाता है कि कौन-सी प्रक्रिया पोर्ट की मालिक है और वह किस पते पर सुनती है। दूसरा वह प्रमाणपत्र छापता है जो क्लाइंट को वास्तव में मिलता है, और यही वह पहचान जाँच है जिसे पोर्ट नंबर नहीं बदल सकता।

राउटेड VPN क्या जोड़ता है जो रैपर नहीं करता

राउटेड VPN एक इंटरफ़ेस इंस्टॉल करता है, चुने गए प्रीफ़िक्स का स्वामित्व लेता है और होस्ट की राउटिंग और एक्सेस नीति के साथ जुड़ता है। मशीन का हर एप्लिकेशन सुरंग के होने की जानकारी के बिना लाभ उठाता है। रैपर वह पहुँच एक कॉन्फ़िगर किए गए श्रोता को देता है और वहीं रुक जाता है।

प्रवेश फिर अलग है। क्लाइंट को प्रमाणित करने वाले VPN को अब भी ऐसा प्राधिकरण चाहिए जो कहे कि क्लाइंट किन संसाधनों तक पहुँच सकता है, और साथी को प्रमाणित करने वाले रैपर को अब भी ऐसा बैकएंड चाहिए जो अपनी अनुमतियाँ लागू करे।

एक वैध संयोजन है: जान-बूझकर समर्थित TCP व्यवस्था पर TLS रैपर के अंदर ले जाया गया VPN प्रोटोकॉल। यह दो परतें चढ़ाता है, और यह रैपर और VPN को एक ही तरह की वस्तु नहीं बनाता।

जो सीमा विफल हो रही है उसकी तुलना करें

कुछ भी बदलने से पहले फ़्रंट-एंड पता, श्रोता, साथी की पहचान, बैकएंड लक्ष्य और एप्लिकेशन क्रिया लिख लें। फिर तुलनीय की तुलनीय से तुलना करें: किसी दूसरे होस्टनाम या पोर्ट से मिली सफलता यह साबित नहीं करती कि फ़ायरवॉल और प्रमाणपत्र की शर्तें एक जैसी थीं।

अस्वीकृत बैकएंड अनुरोध को फ़्रंट-एंड पहचान सत्यापन बंद करके कभी ठीक नहीं करना चाहिए। यह एक निदान योग्य प्राधिकरण विफलता को निदान न करने योग्य विश्वास विफलता से बदल देता है।

curl -sv --resolve svc.example.net:443:203.0.113.10 https://svc.example.net/health 2>&1 | head -30

नाम को चुने गए पते पर पिन करना नाम समाधान को पहुँच से अलग करता है, और आमतौर पर यह जानने का सबसे तेज़ तरीका यही है कि दोनों में से कौन टूटा है।

महत्वपूर्ण तुलना संरक्षित सिरा-युग्म, ले जाया गया पेलोड, उसका उपयोग करने वाले एप्लिकेशन और गंतव्य पर लागू अनुमति का नाम लेती है। TLS उस विवरण में योगदान देता है, उसे पूरा किए बिना।