के 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 ले त्यो विवरणमा योगदान दिन्छ, तर त्यसलाई पूरा गर्दैन।