VPN क्लाइंट चालू होने पर LAN पते को ping करने में General failure
विंडोज़ कहता है कि वह किसी भी अडैप्टर तक पहुँच ही नहीं पा रहा, जबकि रूट टेबल सही दिखती है। तय करें कि रोक रूटिंग की है, फ़िल्टरिंग की है या क्लाइंट की।
एक होस्ट रूट, एक पता, और ping तुरंत General failure के साथ विफल हो जाता है, अनुरोध के समय-समाप्त होने के बजाय। यही अंतर पूरा निदान है। समय-समाप्त होने का अर्थ है कि पैकेट निकल गया और किसी ने उसे अनदेखा कर दिया। General failure का अर्थ है कि विंडोज़ शुरू में ही पैकेट को किसी भी इंटरफ़ेस को नहीं दे सका।
इसलिए जब रूट टेबल बिल्कुल सही दिखती है और त्रुटि अब भी General failure है, तो रोक रूटिंग निर्णय के नीचे हो रही है, और प्रदाता का क्लाइंट वही है जो वहाँ काम कर रहा है।
रूट टेबल से पहले त्रुटि पढ़ें
विंडोज़ वह त्रुटि तब लौटाता है जब उसे भेजने के लिए कोई इंटरफ़ेस नहीं मिलता, और वह इस बारे में कुछ नहीं कहता कि गंतव्य पैकेट के साथ क्या करता। पहुँच, दूर के छोर की फ़ायरवॉल और सेवा की उपलब्धता—ये सब बाद के प्रश्न हैं जहाँ आप अभी नहीं पहुँचे हैं।
इस मामले का पारंपरिक विन्यास एक होस्ट रूट है जो एक LAN पते को भौतिक गेटवे की ओर भेजता है ताकि वह टनल को दरकिनार कर दे। route add उसे स्वीकार करता है, route print उसे दिखाता है, और ping फिर भी विफल होता है, क्योंकि फ़िल्टर ड्राइवर पहले ही तय कर चुका है कि पैकेट को बाहर जाने की अनुमति नहीं है।
इस व्याख्या को स्वीकार करने से पहले पुष्टि करें कि रूट वास्तव में चुना जा रहा है: इंटरफ़ेस इंडेक्स और मीट्रिक जाँचें, और सुनिश्चित करें कि फिर से कनेक्ट होने के बाद प्रविष्टि पुरानी नहीं है। ऐसा रूट जो अब मौजूद नहीं इंटरफ़ेस की ओर इशारा करता है, बहुत कम दिलचस्प कारण से वैसी ही त्रुटि देता है।
तीन परतें, तीन अलग मालिक
जीत उस परत की होती है जो सबसे अंत में चलती है, और ये तीन उस क्रम में नहीं हैं जो ज़्यादातर लोग मानते हैं।
| Layer | What it decides |
|---|---|
| Routing table | Which interface and next hop should carry the packet |
| Client filter driver | Whether this packet is permitted to leave outside the tunnel at all |
| Client feature | Whether a named feature, such as LAN blocking, is active right now |
बीच की परत ही वह कारण है कि रूट एक ही समय में सही और बेकार हो सकता है। प्रदाता के क्लाइंट फ़िल्टर और फ़ायरवॉल नियम स्थापित करते हैं ताकि टनल के बाहर का ट्रैफ़िक छोड़ दिया जाए, और यही वह तंत्र है जो उनके kill switch को लागू करता है। रूट टेबल में कुछ भी उस निर्णय में भाग नहीं लेता।
तीसरी परत एक अजीब रिपोर्ट समझाती है जो नियमित रूप से आती है: क्लाइंट डिस्कनेक्ट करने के बाद भी स्थानीय सबनेट पहुँच से बाहर है। सेवा अब भी चल रही है और फ़िल्टर अब भी स्थापित है, इसलिए कनेक्ट न होना फ़िल्टर न करने के बराबर नहीं है। कोई निष्कर्ष निकालने से पहले क्लाइंट से बाहर निकलें, केवल डिस्कनेक्ट करने के बजाय।
क्या आज़माएँ, क्रम से
उन सुविधाओं को हटाकर शुरू करें जिन्हें हटाना सस्ता और बहाल करना आसान है। LAN खोज, जिसे कभी-कभी LAN पर अदृश्यता कहा जाता है, निजी पता श्रेणियों तक ट्रैफ़िक रोकती है ताकि मशीन अपने पड़ोसियों से छिपी रहे। प्रिंटर, स्थानीय फ़ाइल सर्वर और राउटर स्वयं उस स्विच के पीछे गायब हो जाते हैं। DNS फ़िल्टर करने वाली खतरा सुरक्षा सुविधाएँ अपने हुक स्थापित करती हैं और कहा जाता है कि वे स्थानीय पहुँच को लगभग उसी तरह तोड़ती हैं।
दोनों बंद करें, क्लाइंट से पूरी तरह बाहर निकलें, फिर पता जाँचें। यह क्रम ट्रैफ़िक रोकने वाली सुविधा को गलत रूट करने वाली टनल से अलग करता है, और स्थिर रूट में पूरी दोपहर लगाने के बजाय दो मिनट लेता है।
ping 192.168.1.50
tracert -d 192.168.1.50
route print -4सुविधाएँ बंद होने के बाद अगर पता जवाब देता है, तो आपके पास खराबी नहीं बल्कि नीति का निर्णय है: सुविधा बंद रखना, अपवाद जोड़ना, या यह स्वीकार करना कि मशीन स्थानीय नेटवर्क पर अदृश्य रहेगी—इनमें से चुनें।
क्लाइंट के अपवाद मार्ग का संकीर्ण उपयोग करें
जब किसी सुविधा को चालू ही रखना हो, तो क्लाइंट का अपना स्प्लिट टनलिंग समर्थित रास्ता है। अपवाद को उतना ही छोटा रखें जितना आवश्यकता अनुमति देती है, जिसका आमतौर पर अर्थ है एक सर्वर के लिए एक होस्ट पता या एक सेगमेंट के लिए एक प्रीफ़िक्स। पूरी निजी श्रेणी को कवर करने वाला नियम एक स्थायी छेद है जिसे जोड़ना किसी को याद नहीं रहेगा और जिसे हटाने की हिम्मत कोई नहीं करेगा।
फिर पहले पते से और बाद में नाम से सत्यापित करें। अगर पता भौतिक गेटवे पर पहली हॉप के साथ जवाब देता है, तो अपवाद काम करता है। अगर नाम अब भी विफल होता है, तो आप DNS पर पहुँच गए हैं, क्योंकि टनल का रिज़ॉल्वर स्थानीय ज़ोन नहीं जानता और कोई रूटिंग परिवर्तन उसे यह नहीं सिखाएगा।
रूट या अपवाद रखें, दोनों नहीं, साथ में एक टिप्पणी कि कौन काम कर रहा है। दो अतिव्यापी तंत्र एक-दूसरे को छिपाते हैं, और इस मशीन को डिबग करने वाला अगला व्यक्ति एक को हटा देगा और कोई बदलाव नहीं देखेगा।
जब क्लाइंट ही बाधा हो
कुछ बिल्ड ट्रैफ़िक को ऐसे फ़िल्टर करते हैं जिसे न स्थिर रूट हरा सकता है न क्लाइंट अपवाद। जब यही निष्कर्ष हो, तो ईमानदार विकल्प हैं बायपास सुविधा की प्रतीक्षा करना या प्रदाता की अपनी प्रोफ़ाइल का उपयोग करते हुए सादे OpenVPN क्लाइंट से जुड़ना, जिसकी सिफ़ारिश मूल रिपोर्ट में विक्रेता के सहायता उत्तर ने की थी।
यह प्रतिस्थापन करने से पहले सौदे को समझें। सादी प्रोफ़ाइल किसी भी सामान्य टनल की तरह व्यवहार करती है: वह अपने रूट स्थापित करती है और बाकी स्टैक को पुनर्गठित नहीं करती, इसलिए संकीर्ण होस्ट रूट अब भी वैसे ही व्यवहार करता है जैसी आप अपेक्षा करते हैं। आप जो खोते हैं वह सब कुछ है जो ब्रांडेड क्लाइंट ने टनल के आसपास लागू किया, जिसमें kill switch और DNS फ़िल्टरिंग शामिल है, और उन्हें जानबूझकर फिर से बनाना होगा या अनुपस्थित मानना होगा।
आप जो भी चुनें, दर्ज करें कि रोक किस परत की थी। जो पैकेट कभी मशीन से बाहर नहीं गया वह फ़िल्टर का परिणाम है, और कोई रूटिंग परिवर्तन फ़िल्टर ठीक नहीं कर सकता।