VPN कनेक्ट है पर इंटरनेट नहीं? चारों परतें जाँचें

क्लाइंट कहता है कनेक्ट है, ब्राउज़र घूमता है, और हर साइट टाइमआउट पर खत्म होती है। यह संयोजन आम है और विरोधाभास नहीं: कनेक्ट का मतलब है कि टनल ने बातचीत की, बस इतना ही। नाम विश्लेषण, रूटिंग और सर्वर का अपना एग्ज़िट—हर एक अपने तरीके से विफल होता है, और हर एक का मालिक अलग है। परतें क्रम से जाँचें और जो पहली विफल हो उसी पर रुकें।

जिस नेटवर्क से आए हैं, वहीं से शुरू करें

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

टनल छूने से पहले Wi-Fi लिंक, राउटर और लॉगिन माँगने वाले किसी भी पोर्टल पेज को देखें। किल स्विच डिज़ाइन के अनुसार डिस्कनेक्ट रहते हुए ट्रैफ़िक रोक सकता है, इसलिए नेटवर्क मृत मानने के बजाय उसकी प्रलेखित परीक्षण प्रक्रिया अपनाएँ। दूसरा भरोसेमंद नेटवर्क उपयोगी तुलना है, और नया VPN एग्ज़िट समाप्त हो चुका होटल लॉगिन पूरा नहीं करेगा। अगर खुला नेटवर्क चलता है और टनल नहीं, तो नेटवर्क निर्दोष है और अगली परत आपकी है।

तय करें कि विफलता नाम विश्लेषण की है या नहीं

त्रुटि का पाठ लिख लें, क्योंकि विश्लेषण विफलता, टाइमआउट और प्रमाणपत्र चेतावनी हर एक कहीं और इशारा करती है। जल्दी पकड़ने वाला पैटर्न यह है कि कभी न देखा गया होस्टनाम विफल हो जबकि खुले सत्र वाला ऐप चलता रहे। यह पैटर्न नई लुकअप की बात करता है, टनल के पैकेट ढोने की नहीं। एक लुकअप दिखाता है कि रिज़ॉल्वर क्या लौटाता है, और चलाने में एक सेकंड लगता है। दूसरा नाम भी आज़माएँ, ताकि एक कैश किया उत्तर या एक टूटा रिकॉर्ड निदान तय न कर दे।

nslookup example.com

HTTPS एड्रेस बार में मनमाना IP, DNS परीक्षण नहीं है, क्योंकि प्रमाणपत्र और वर्चुअल होस्ट आमतौर पर नाम पर निर्भर करते हैं। आंतरिक नामों को सार्वजनिक विकल्प के बजाय संगठन के रिज़ॉल्वर की ज़रूरत हो सकती है, और अपना सुरक्षित रिज़ॉल्वर रखने वाला ब्राउज़र ऑपरेटिंग सिस्टम की लुकअप से अलग उत्तर दे सकता है। जहाँ दोनों अलग हों, वहाँ ब्राउज़र का रिज़ॉल्वर वही है जो उपयोगकर्ता अनुभव करता है, और यह अंतर टिकट का हिस्सा है।

पूरा टनल या सिर्फ़ कंपनी सबनेट

कुछ प्रोफ़ाइल सिर्फ़ कुछ कंपनी सबनेट तक पहुँचने के लिए होती हैं; दूसरी सब कुछ ढोने के लिए बनी होती हैं और उनके पीछे काम करता एग्ज़िट चाहिए। संकेतक हर ऐप और हर एड्रेस परिवार को ढकता है—यह मानने से पहले प्रलेखित उद्देश्य पढ़ें। निजी नेटवर्क प्रोफ़ाइल ठीक वैसे चल सकती है जैसे बनाई गई थी, जबकि वह ब्राउज़र, जिसे इसे कभी इस्तेमाल करना नहीं था, अब भी विफल रहे। रूट तालिका बदले बिना पढ़ें, और IPv6 शामिल करें, क्योंकि चलता IPv4 मार्ग दूसरे परिवार के बारे में कुछ नहीं कहता।

ज़्यादा विशिष्ट रूट तब भी जीत सकता है जब डिफ़ॉल्ट रूट अभी मौजूद हो, इसलिए तालिका माननी नहीं, पढ़नी चाहिए। प्रतिस्पर्धी वर्चुअल अडैप्टर भी वह ट्रैफ़िक रख सकते हैं जिसकी उम्मीद आप कहीं और कर रहे थे, खासकर दूसरा VPN क्लाइंट इंस्टॉल करके भुला देने के बाद। प्रयोग के तौर पर डिफ़ॉल्ट रूट न हटाएँ; इससे निदान दूसरी गड़बड़ी बन जाता है।

चलती साइटों के बीच एक विफल साइट उस साइट की समस्या है, और यह भी साबित करती है कि टनल ट्रैफ़िक ढो रहा है। सिर्फ़ बड़े स्थानांतरणों में दिखने वाली अटक पैकेट आकार की ओर इशारा करती है, पहुँच की ओर नहीं।

जब सर्वर कभी कुछ फ़ॉरवर्ड नहीं करता

अगर हर गंतव्य दो उपकरणों और दो एक्सेस नेटवर्क पर विफल हो, तो टनल ऊपर है और एग्ज़िट फ़ॉरवर्ड नहीं कर रहा। यही जोड़ी सर्वर-पक्ष की विफलता को एक जगह गलत कॉन्फ़िगर किए गए एक उपकरण से अलग करती है। ऑपरेटर को संकेतक का स्क्रीनशॉट नहीं, फ़ॉरवर्डिंग, NAT और वापसी मार्ग के सवाल भेजें।

ये तीन सर्वर-पक्ष के ज़्यादातर कारण ढकते हैं, और इनका जवाब ऑपरेटर का काम है। OpenVPN कनेक्टिविटी समस्या-निवारण पृष्ठ सर्वर की ओर से वही सवाल चलाता है, इसलिए इसे टिकट के साथ भेजें। हरे संकेतक का स्क्रीनशॉट इनमें से किसी का जवाब नहीं देता।

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

एक बार में एक परत जाँचें

कुछ बदलने के बाद फिर कनेक्ट करें और ठीक वही ऐप दोहराएँ जो विफल हुआ था। एक पेज लोड होना उन संसाधनों तक दोहराने योग्य रास्ते से कम साबित करता है जिनके लिए प्रोफ़ाइल बनी थी। दो कमांड विश्लेषण को पहुँच से अलग करते हैं, और दूसरा होस्ट-विशिष्ट है। curl पंक्ति कहीं भी चलाएँ, फिर आपके सामने वाले होस्ट से मेल खाता रूट कमांड चलाएँ।

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://example.com
route print -4          # Windows
ip -4 route show        # Linux
netstat -rn | head      # macOS

अगर संख्यात्मक अनुरोध चलता है और नाम नहीं, तो DNS पर रहें। अगर दोनों में से कोई नहीं चलता, तो रूट तालिका की टनल के अपेक्षित डिफ़ॉल्ट से तुलना करें, और वह परिवार जाँचें जिसे आप वास्तव में परख रहे हैं। अगर रूट सही है और अनुरोध अब भी एग्ज़िट पर मरता है, तो बाकी सवाल ऑपरेटर का है, और आपने जो सबूत रखे वही टिकट है।