इंटरनेट फक्त 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 त्याने स्पर्श केलेल्या रजिस्ट्री की आणि फाइली नोंदवतो, तर पॅकेट कॅप्चर त्याची रहदारी कुठे गेली हे उघड करते। दोन्ही साधी साधने आहेत, आणि कोणत्याही स्थिती दिव्यापेक्षा दोन्ही शिल्लकीच्या प्रश्नाचे उत्तर चांगले देतात। ॲप अजूनही चालू असण्याची गरज त्यांना नाही।

पुरावा नाही, घटक काढा

टिकाऊ उपाय म्हणजे ज्याने सेटिंग लिहिली ते काढून टाकणे। ॲप अनइन्स्टॉल करा, त्याने जोडलेला व्हर्च्युअल अडॅप्टर हटवा, प्रॉक्सी आणि रिझॉल्व्हर यादी साफ करा, नंतर रीबूट करा आणि ॲप अनइन्स्टॉल असतानाच चाचणी करा। त्या टप्प्यावर ब्राउझिंग चालले तर तुम्ही तोडगा नाही तर कारण शोधले आहे। कोणता स्तर जुना होता याची नोंद ठेवा, कारण तोच विक्रेता तीच चूक दोनदा पाठवण्याकडे कलतो।

पुढील क्लायंट इन्स्टॉल केल्यावर लक्षण परत आले तर सेवेने काहीतरी बिघडवले असे ठरवण्यापूर्वी चार स्तरांतून पुन्हा जा। पुरावा सहसा त्या चारपैकी एका ठिकाणी अजूनही असतो। दुसरे ॲप पाचवा स्तर निर्माण करत नाही; ते चारपैकी एक संपादित करते।

पुनर्स्थापना प्रॉक्सी रीसेट करते पण जुना अडॅप्टर नाही, आणि ती यादीत दोन रिझॉल्व्हर सोडू शकते। ही विषमता म्हणूनच सर्व-रीसेट बटणापेक्षा अनइन्स्टॉल-मग-चाचणी बरी आहे। कनेक्शन पडल्याच्या पुढील वेळी तुलना करण्यासाठी ती तुम्हाला आधाररेषाही देते।