इन्टरनेट VPN एप खुला भएमा मात्र चल्छ? चार तह जाँच्नुहोस्

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

क्लाइन्टले टनेलको स्वामित्व नभएका सेटिङ बदल्छ

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

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

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

तीन बाँकी, तीन फरक असफलता

पहिलो बाँकी केही नभएको ठाउँमा देखाउने प्रोक्सी हो: LAN प्रोक्सी बाकस अझै टिक गरिएको, वा कन्फिगरेसन स्क्रिप्ट URL कुनै प्रक्रिया नसुनिरहेको localhost पोर्टतिर लक्षित। ब्राउजरले हरेक अनुरोध त्यो मृत पोर्टमा पठाउँछ र समयसीमा मृत नेटवर्कजस्तो नदेखिएसम्म अड्किन्छ। दोस्रो एउटा एडाप्टर हो जसले अझै पूर्वनिर्धारित रुट राख्छ, किनभने TAP-Windows यन्त्र वा विक्रेताको रुटिङ ड्राइभर अनइन्स्टलपछि पनि वास्तविक इन्टरफेस रहन्छ। यसले पाएको रुट राख्छ, र ट्राफिक नभएको टनेलभित्र हराउँछ। कुनै पनि बाँकीले आफ्नो घोषणा गर्दैन; दुवै ठ्याक्कै अवरोधजस्तै देखिन्छन्।

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

चार तह क्रमैसँग जाँच्नुहोस्

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

Windows मा हरेक जाँच अपरेटिङ सिस्टमसँगै आउने एउटै कमाण्ड हो, त्यसैले केही इन्स्टल गर्नु पर्दैन। तिनीहरू क्रमैसँग चलाउनुहोस् र आउटपुट सँगै राख्नुहोस्, किनभने चारै उत्तर सँगसँगै मात्र अर्थपूर्ण हुन्छन्। तिनीहरूले प्रोक्सी, एडाप्टर, IPv4 रुट र रिजोल्भर सूची त्यही क्रममा रिपोर्ट गर्छन्:

netsh winhttp show proxy
Get-NetAdapter
route print -4
Get-DnsClientServerAddress

Linux र macOS लाई आ-आफ्नै कमाण्ड चाहिन्छ, र ती साटासाट गर्न मिल्दैन। Linux मा रुट ip route बाट र रिजोल्भर resolvectl status बाट आउँछ जहाँ systemd-resolved को स्वामित्व छ, cat /etc/resolv.conf मा फर्कने विकल्पसहित। macOS मा रुट netstat -rn बाट, रिजोल्भर scutil --dns बाट र सिस्टम प्रोक्सी scutil --proxy बाट आउँछ। ip route चलाउने macOS पाठकले command not found पाउँछ, र त्यहाँ /etc/resolv.conf अधिकारिक कन्फिगरेसन नभई उत्पन्न स्टब हो। तह जाँच्नुअघि प्लेटफर्म जाँच्नुहोस्, नत्र पहिलो कमाण्ड नै निष्कर्ष बन्छ।

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

प्रोक्सी टनेल होइन

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

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

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

कम्पोनेन्ट हटाउनुहोस्, प्रमाण होइन

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

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

पुनःइन्स्टलले प्रोक्सी रिसेट गर्छ तर पुरानो एडाप्टर गर्दैन, र सूचीमा दुई रिजोल्भर छोड्न सक्छ। त्यही असमानताले गर्दा अनइन्स्टल-अनि-परीक्षण सबै रिसेट गर्ने बटनभन्दा राम्रो हुन्छ। अर्कोचोटि जडान झर्दा तुलना गर्ने आधाररेखा पनि यसैले दिन्छ।