SSL VPN कि TLS खोल? असफल भएको सीमा तुलना गर्नुहोस्

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

तपाईंले साँच्चै कन्फिगर गर्नुभएको जडानबाट सुरु गर्नुहोस्

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

नेटवर्क डिजाइनको सम्झौता फरक हुन्छ, र त्यो पोर्ट जोडीमा होइन, मार्ग र नीतिमा व्यक्त हुन्छ।

ती दुई विवरणमध्ये कुन तपाईंको रेखाचित्रसँग मिल्छ हेर्नुहोस्। उत्तर बीचमा प्रमाणपत्र भएको एउटा पोर्ट म्यापिङ हो भने, उत्पादनको नाम VPN भने पनि तपाईंसँग खोल छ। उत्तर टनेल इन्टरफेस र मार्ग परिवर्तन हो भने, त्यो 443 मा चले पनि तपाईंसँग नेटवर्क डिजाइन छ।

खोल केसँग जोडिन्छ जाँच्नुहोस्

सुन्ने र जोडिने सेटिङ पढ्नुहोस् र तिनलाई साँचो backend सम्म पुर्याउनुहोस्। डेटाबेस पोर्टमा पठाउने खोलले वेब अनुप्रयोग खोल्दैन, र कार्यक्रम चलाउने खोलले होस्टले चलाउने बाँकी सबै प्रकाशित गर्नुको सट्टा त्यही कार्यक्रम सुरु गर्छ। backend मात्र खोललाई थाहा हुने एक मात्र कुरा हो।

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

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

पहिलो आदेशले क्लाइन्टलाई वास्तवमै दिइने प्रमाणपत्र देखाउँछ, र दोस्रोले होस्टमा के सुन्दै छ देखाउँछ। अरू केही पढ्नु अघि त्यो प्रमाणपत्रको नाम तपाईंले अपेक्षा गरेको नामसँग तुलना गर्नुहोस्।

डिजाइनले कुन ट्राफिक बोक्छ जाँच्नुहोस्

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

उत्पादनको लेबलले तपाईंले यीमध्ये कुन मोडेल किन्नुभयो भन्ने बताउँदैन, र पोर्ट नम्बरले अझ कम बताउँछ।

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

असफल सीमा जाँच्नुहोस्, लेबल होइन

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

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

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