तपाईंको VPN मार्फत स्थानीय नेटवर्कले अझै के देख्छ

कसैले VPN ले आफ्नो ट्राफिक लुकाउँछ कि भनी सोध्ने बित्तिकै तीन पर्यवेक्षक एउटै प्रश्नमा मिसिन्छन्: ऊ जोडिएको नेटवर्क, उसको हातको यन्त्र र सुरुङको अपरेटर। प्रत्येकले फरक कुरा सिक्छ, र सुरुङले ती प्रत्येक दृष्टिकोणलाई फरक तरिकाले बदल्छ। उल्टो दिशामा काम गर्नु र गरिएको दाबीबाट सुरु गर्नु उपयोगी हुन्छ, किनभने जाँचको सामना गर्नुपर्ने कुरा त्यही दाबी हो। तपाईंलाई कुन दाबी चाहिन्छ त्यो तय गर्नुहोस्, त्यसपछि त्यससँग औजारहरू तुलना गर्नुहोस्।

पहिलो दाबी: कोहीले पनि ट्राफिक पढ्न सक्दैन

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

security find-certificate -a -p /Library/Keychains/System.keychain | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -noout -print_certs | grep subject
certutil -store Root

macOS मा त्यो पाइपलाइनले यन्त्रको कुञ्जीगुच्छाको प्रत्येक प्रमाणपत्रका लागि एउटा विषय-लाइन छाप्छ, झ्याल नखोली, र Windows मा certutil -store Root ले certlm.msc ले ग्राफिक रूपमा देखाउने त्यही भण्डार सूचीबद्ध गर्छ। विद्यालय, रोजगारदाता वा नेटवर्क सुरक्षा उत्पादनको मूल नै खोज्नुपर्ने प्रविष्टि हो। एउटा भेट्नुले अवरोधन सम्भव छ भन्ने मात्र प्रमाणित गर्छ, भइरहेको छ भन्ने होइन।

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

दोस्रो दाबी: तपाईं कहाँ जानुहुन्छ कोही देख्दैन

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

resolvectl status | grep -A2 "Link"
nslookup example.com

कुन रिजोल्भर वास्तवमा प्रयोग भइरहेको छ त्यसैले खुलासाको मात्रा तय गर्छ, र त्यो बहस गर्नुको सट्टा नाप्न सकिन्छ। Linux मा resolvectl status ले प्रत्येक लिङ्कका DNS सर्भर छाप्छ, र त्यसको आउटपुटले साइटको रिजोल्भर जवाफ दिइरहेको छ कि थोपरिएको भनी बताउँछ। Windows ले त्यही प्रश्नको जवाफ nslookup example.com ले दिन्छ, जसको आउटपुटको पहिलो खण्ड जवाफ दिने DNS सर्भर हो।

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

तेस्रो दाबी: तपाईं जोडिनुभयो भन्ने कसैलाई थाहा छैन

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

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

अर्को छेउको अपरेटरसँग त्यो दृश्यको ऐनामा परेको प्रतिबिम्ब हुन्छ: निकास ठेगाना, समय, परिमाण र प्रायः साइटका नाम। तपाईंको प्रदायक नै दृष्टिकोण भएको पक्ष बन्छ, जुन अदृश्यताभन्दा फरक सौदा हो। विश्वासिलो प्रदायक छान्नु वास्तविक निर्णय हो; नतिजालाई अ-पर्यवेक्षित भन्नु होइन।

तपाईंलाई कुन दाबी चाहिन्छ तय गर्नुहोस्

क्लाइन्ट छुनु अघि आवश्यकता एक लाइनमा लेख्नुहोस्: सामग्री लुकाउनुहोस्, गन्तव्य लुकाउनुहोस्, वा तपाईं जोडिनुभयो कि भन्ने नै लुकाउनुहोस्। सामग्री HTTPS र सुरुङले पहिले नै सम्हाल्छ, तर गन्तव्यका लागि साइटका उपकरण पूर्ण रूपमा छल्ने रिजोल्भर र मार्ग चाहिन्छ।

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