नया हॉटस्पॉट क्लाइंट IP पाने पर अटकना VPN की खराबी नहीं है

एक फ़ोन हॉटस्पॉट से जुड़ता है, «IP पता प्राप्त हो रहा है» पर रुका रहता है और अंत में हार मान लेता है। स्वाभाविक निष्कर्ष यह है कि फ़ोन का VPN DNS में बाधा डाल रहा है, इसलिए लोग रिज़ॉल्वर और जोड़े गए नियम संपादित करने लगते हैं। यह गलत चरण है। क्लाइंट को कभी स्थानीय पता नहीं मिला, और उसके बिना न उसके पास गेटवे है, न रिज़ॉल्वर और न ही आगे भेजने के लिए कुछ, इसलिए होस्ट फ़ोन पर कोई भी VPN सेटिंग इस विफलता की व्याख्या नहीं कर सकती। जुड़ाव, स्थानीय पता आवंटन और आगे फ़ॉरवर्डिंग तीन अलग चरण हैं, और केवल अंतिम चरण में टनल शामिल है।

तीन चरण, और आप किसमें हैं

पहले जुड़ाव आता है: क्लाइंट हॉटस्पॉट के वायरलेस नेटवर्क से जुड़ता है। गलत पासवर्ड, WPA3 का मेल न खाना या रेडियो संगतता की समस्या यहीं विफल होती है, और क्लाइंट आमतौर पर यह बताता है। दूसरे स्थानीय पता आवंटन आता है: IPv4 के लिए क्लाइंट लीज़ माँगता है और पता तथा स्थानीय गेटवे सेटिंग्स पाता है, जबकि IPv6 आमतौर पर DHCP के बजाय राउटर घोषणाओं का उपयोग करता है, जैसा AOSP के टेदरिंग दस्तावेज़ बताते हैं। तीसरे बाहर की पहुँच आती है: होस्ट फ़ोन अनुमत ट्रैफ़िक को अपने चुने हुए अपस्ट्रीम पथ पर भेजता है, जो उसकी टनल हो सकता है या नहीं।

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

भ्रम: राउट किया गया VPN स्थानीय DHCP को दूरस्थ अनुरोध बना देता है

राउट की गई टनल अपने चुने गए गंतव्यों के लिए IP पैकेट ले जाती है। DHCP डिस्कवरी हॉटस्पॉट के अपने सेगमेंट पर एक प्रसारण है, और फ़ोन पर टेदरिंग सेवा उसका स्थानीय रूप से उत्तर देती है, इसलिए टनल चालू होने पर भी क्लाइंट को पता मिल सकता है। केवल जानबूझकर ब्रिज या रिले किया गया डिज़ाइन वह अदला-बदली कहीं और भेजता है, और वह अलग विफलता-हस्ताक्षर वाली अलग व्यवस्था है।

इसलिए «VPN सर्वर DHCP का उत्तर नहीं दे रहा» कोई निदान नहीं, यह मॉडल की गलती है। स्थानीय ब्रोकर फ़ोन पर ही है। यदि वह उत्तर देना बंद कर दे, तो कारण स्थानीय हैं: टेदरिंग सेवा, क्लाइंट सीमा, लीज़ पूल, या ऐसा क्लाइंट जिसने जुड़ाव ठीक से पूरा ही नहीं किया। इनमें से कुछ भी टनल के दूर वाले हिस्से पर नहीं रहता।

पहले से जुड़ा क्लाइंट काम करना वास्तव में क्या साबित करता है

यदि पहले से जुड़ा लैपटॉप अब भी काम करता है जबकि नया फ़ोन नहीं, तो हॉटस्पॉट और अपस्ट्रीम पथ मोटे तौर पर जीवित हैं। यह तुलना उपयोगी है और यह इस बात का प्रमाण नहीं कि कौन-सा घटक दोषी है, क्योंकि काम कर रहा क्लाइंट बदलाव से पहले की लीज़ थामे हुए चुपचाप उसे नवीनीकृत कर रहा हो सकता है।

वहाँ रहते हुए दो स्थानीय सीमाएँ जाँचना उचित है। हॉटस्पॉट सीमित लीज़ पूल और विन्यास-योग्य क्लाइंट सीमा देता है, इसलिए जुड़कर सो गया डिवाइस पता थामे रह सकता है जबकि नया इंतज़ार करता है। और दूसरे नेटवर्क का स्थिर विन्यास याद रखने वाला क्लाइंट लीज़ ही नहीं माँगेगा, जो बाहर से एक जैसा दिखता है और फ़ोन पर नहीं, क्लाइंट पर ठीक किया जाता है।

तुलना को स्थानीय और प्रतिवर्ती रखें

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

टनल पर निर्भर लगातार लीज़ विफलता स्थानीय नीति या कार्यान्वयन अंतःक्रिया के बारे में उपयोगी प्रमाण है। यह डिवाइस पर हर फ़ॉरवर्डिंग और NAT नियम साफ़ करने का लाइसेंस नहीं है। वे नियम असंबद्ध ट्रैफ़िक की रक्षा करते हैं, और व्यापक फ़ॉरवर्डिंग स्वीकृति यह नहीं समझाती कि स्थानीय DHCP सेवा ने उत्तर देना क्यों बंद किया।

छूटी हुई लीज़ को अनुमानित स्थिर पते से ढकें भी नहीं। जानबूझकर किया गया स्थिर विन्यास वास्तविक सबनेट, गेटवे, आवंटन योजना और टकराव जाँच माँगता है। क्लाइंट का DNS बदलने से इनमें से कुछ नहीं मिलता, और अगला डिवाइस उसी विफलता के साथ रह जाता है।

लीज़ क्या साबित नहीं करती

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

चरणों को क्रम से करें और विफलता जगह बदलना बंद कर देगी। पता पाने पर अटका क्लाइंट स्थानीय टेदरिंग का प्रश्न है; पता है पर पेज नहीं ऐसा क्लाइंट फ़ॉरवर्डिंग या नामकरण का प्रश्न है; पेज हैं पर निकास गलत है ऐसा क्लाइंट टनल कवरेज का प्रश्न है। इन्हें अलग रखना ही डिबगिंग का बड़ा हिस्सा है।