टनेलले के इन्क्रिप्ट गर्छ र के पढ्नयोग्य छोड्छ

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

टनेलले वास्तवमा के ढाक्छ

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

निकास डिक्रिप्ट गरेर अगाडि पठाउने यन्त्र हो, र VPN ठ्याक्कै त्यसैका लागि हो। यसले अगाडि पठाउने सबै यसलाई प्राप्त भएको रूपमै देखिन्छ, त्यसैले साधारण HTTP अनुरोध निकासदेखि अगाडि साधारण पाठ नै रहन्छ।

यसलाई कमी नभई गुणका रूपमा पढ्नुहोस्। इन्क्रिप्शन एउटा मार्गमा सीमित छ, र मार्ग सेवा सुरु हुने ठाउँमै सकिन्छ।

सरल शब्दमा कुञ्जी, nonce र अखण्डता

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

कुञ्जी त्यही आदानप्रदानबाट आउँछ, लगइनमा टाइप गरिएको पासवर्डबाट होइन। पासवर्डले पहिचान प्रमाणित गर्छ, र त्यसपछि प्रोटोकलले सत्र सामग्री स्थापना गर्छ। क्षणिक कुञ्जी आदानप्रदानले अगाडिको गोपनीयता दिन्छ, त्यसैले रेकर्ड गरिएको सत्र पछि दीर्घकालीन कुञ्जी चुहिए पनि पढ्न नसकिने रहन्छ।

विनिर्देशमा भएको ठूलो संख्याले यी प्रश्नमध्ये कुनैको उत्तर दिँदैन, र असम्बन्धित एल्गोरिदमबीच संख्या तुलना गर्नु क्रमबद्धता होइन। बरु कुञ्जी आदानप्रदानले के दिन्छ भनी सोध्नुहोस्।

टनेल कहाँ सकिन्छ

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

HTTPS त्यो बिन्दुपछि पनि जारी रहन्छ, त्यसैले VPN बिना पनि शत्रुतापूर्ण सञ्जालमा साइट सुरक्षित हुन सक्छ। दुवै सुरक्षा पहिलो खण्डमा ओभरल्याप हुन्छन् र निकासपछि तीमध्ये एउटा मात्र जारी रहन्छ।

जडान चलाउन प्रमाणपत्र प्रमाणीकरण कमजोर बनाउनु टनेलको परीक्षा नहुने कारण पनि यही हो। यसले अर्को सुरक्षा बन्द गर्छ र तपाईंलाई सुरुवातभन्दा कमसँग छोड्छ।

अनामता किन फरक उत्पादन हो

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

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

त्यही आवश्यकता भए लगिङ नीति र अधिकारक्षेत्रका आधारमा प्रदायक छान्नुहोस्, अनि नीति आफै पढ्नुहोस्। मार्केटिङ पृष्ठहरूले यो प्रश्नको उत्तर कसैले जाँच्न सक्ने तरिकाले विरलै दिन्छन्।

टनेल र साइट अलग-अलग जाँच्नुहोस्

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

परीक्षण गर्न अनुमति भएको होस्टविरुद्ध जाँचहरू चलाउनुहोस्, र सारांश नभई आउटपुट पढ्नुहोस्।

wg show
ip -brief addr show tun0
curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' https://example.com

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