इंटरनेट सिर्फ़ VPN ऐप चालू रहने पर चलता है? चार परतें जाँचें
Windows पर VPN ऐप प्रॉक्सी, वर्चुअल अडैप्टर, रूट और DNS पीछे छोड़ जाता है। चार परतों को एक-एक करके देखें, साथ में Linux और macOS की कमांड के साथ।
आप एक हफ़्ते तक कोई मुफ़्त VPN क्लाइंट या ब्राउज़र एक्सटेंशन आज़माते हैं, उसे बंद करते हैं, और इंटरनेट रुक जाता है। Wi-Fi आइकन अब भी कनेक्शन दिखाता है, उसी राउटर पर दूसरे डिवाइस ठीक चलते हैं, और ब्राउज़िंग वापस लाने वाली चीज़ें सिर्फ़ दो हैं: ऐप फिर से चालू करना या उसे अनइंस्टॉल करना। यह पैटर्न एन्क्रिप्शन से बनी निर्भरता नहीं है। यह वह कॉन्फ़िगरेशन है जिसे ऐप ने कहीं ऐसी जगह लिखा जो टनल के अधिकार में नहीं है।
क्लाइंट वे सेटिंग्स बदलता है जो टनल के अधिकार में नहीं हैं
Windows या macOS पर प्राइवेसी क्लाइंट आमतौर पर एक साथ तीन जगहों को छूता है। वह सिस्टम HTTP प्रॉक्सी सेट करता है, वही फ़ील्ड जो Internet Options दिखाता है। वह एक वर्चुअल अडैप्टर इंस्टॉल करता है, अक्सर 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 से आता है। macOS पर कोई पाठक ip route चलाए तो उसे command not found मिलता है, और वहाँ /etc/resolv.conf असली कॉन्फ़िगरेशन नहीं बल्कि बना हुआ स्टब है। परत जाँचने से पहले प्लेटफ़ॉर्म जाँचें, वरना पहली कमांड ही निष्कर्ष बन जाती है।
हर परत के लिए एक सवाल पूछें: जब ऐप बंद है तो क्या यह मान अब भी किसी ऐसी चीज़ की ओर इशारा करता है जो मौजूद है? मृत पोर्ट पर प्रॉक्सी, बिना टनल वाला अडैप्टर, बंद इंटरफ़ेस से जाता डिफ़ॉल्ट रूट और टनल के अंदर बैठा रिज़ॉल्वर, सबका जवाब ना है। कोई एक ना भी लक्षण समझाने के लिए काफ़ी है, इसीलिए हर परीक्षण में एक ही बदलाव मायने रखता है।
प्रॉक्सी टनल नहीं है
प्रॉक्सी अनुरोध लेता है, उसे कहीं और से लाता है और जवाब लौटा देता है, यानी वह गंतव्य जानता है और वह सब देखता है जो साइट ने ख़ुद एन्क्रिप्ट नहीं किया। वह दूसरे प्रोटोकॉल नहीं ढोता। वह रास्ते को तब तक नहीं बचाता जब तक गंतव्य पहले से TLS न इस्तेमाल करे। और उसे वही बदल सकता है जिसने उसे इंस्टॉल किया, आपकी भागीदारी के बिना।
यह फ़र्क़ उस सवाल को बदल देता है जो पूछने लायक है। जब प्रॉक्सी पीछे रह जाए, तो यह पता करें कि कौन-सा प्रोग्राम अब भी आपका ब्राउज़र चला रहा है, यह नहीं कि टनल चालू है या नहीं। टनल पूरी तरह ठीक हो सकता है और विफलता से उसका कोई लेना-देना न हो।
अगर आप जानना चाहते हैं कि ऐसे क्लाइंट ने असल में क्या किया, तो उसका डैशबोर्ड पढ़ने के बजाय उसे देखें। Process Monitor दर्ज करता है कि वह किन रजिस्ट्री कुंजियों और फ़ाइलों को छूता है, और पैकेट कैप्चर बताता है कि उसका ट्रैफ़िक कहाँ गया। दोनों आम टूल हैं, और दोनों अवशेष वाले सवाल का जवाब किसी भी स्टेटस लाइट से बेहतर देते हैं। दोनों में से किसी को ऐप के चालू रहने की ज़रूरत नहीं।
घटक हटाएँ, सबूत नहीं
टिकाऊ हल उस चीज़ को हटाना है जिसने सेटिंग लिखी। ऐप अनइंस्टॉल करें, उसके जोड़े वर्चुअल अडैप्टर को मिटाएँ, प्रॉक्सी और रिज़ॉल्वर सूची साफ़ करें, फिर रीबूट करके ऐप के अनइंस्टॉल रहते हुए जाँचें। अगर उस समय ब्राउज़िंग चलती है, तो आपने कामचलाऊ उपाय नहीं बल्कि असली कारण ढूँढ लिया है। यह लिख लें कि कौन-सी परत पुरानी थी, क्योंकि वही विक्रेता वही ग़लती दोबारा भेजने को माहिर है।
अगर अगला क्लाइंट इंस्टॉल करने के बाद लक्षण लौट आए, तो यह तय करने से पहले कि सेवा ने कुछ तोड़ा है, चारों परतें फिर देखें। सबूत आमतौर पर अब भी वहीं, चार जगहों में से किसी एक में होते हैं। दूसरा ऐप पाँचवीं परत नहीं बनाता; वह चारों में से किसी एक को बदलता है।
रीइंस्टॉल प्रॉक्सी रीसेट करता है पर पुराना अडैप्टर नहीं, और वह सूची में दो रिज़ॉल्वर छोड़ सकता है। यही असमानता वजह है कि अनइंस्टॉल-फिर-जाँच, सब कुछ रीसेट करने वाले बटन से बेहतर है। यह आपको अगली बार कनेक्शन टूटने पर तुलना के लिए आधार भी देता है।