GVC Acquiring IP पर अटका है: यह पासवर्ड की समस्या नहीं है

Global VPN Client Acquiring IP पर रुक जाता है, और पहली प्रतिक्रिया पासवर्ड दोबारा लिखने या क्लाइंट को फिर से इंस्टॉल करने की होती है। दोनों में से कोई उस चरण को नहीं छूता जो विफल हुआ। प्रमाणीकरण उससे पहले पूरा हो चुका था जब क्लाइंट ने पता माँगा भी नहीं था, इसलिए उस पंक्ति पर आपको रोकने वाला क्रेडेंशियल नहीं है। आपको वहाँ रोकने वाला एक अधूरा DHCP आदान-प्रदान है, और वह तीन अलग जगहों पर अटक सकता है।

प्रमाणीकरण और पता आवंटन अलग-अलग चरण हैं

GVC पहले साबित करता है कि आप कौन हैं, फिर आपके कनेक्शन को दी गई नीति के अनुसार अपने वर्चुअल एडाप्टर की सेटिंग माँगता है। ये अलग-अलग विफलता-चिह्नों वाले क्रमिक चरण हैं। खराब क्रेडेंशियल आमतौर पर पहले विफल होते हैं, पते की पंक्ति के बजाय प्रमाणीकरण या बातचीत के संदेश के साथ।

यही क्रम बताता है कि पासवर्ड रीसेट, नया स्थानीय उपयोगकर्ता या पुनः इंस्टॉल यहाँ कुछ भी क्यों नहीं बदलते। क्लाइंट पहले ही अधिकृत है; अब वह ऐसी लीज़ का इंतज़ार कर रहा है जो गेटवे या उसके DHCP साथी को देनी होती है। यहाँ तक कि वह नीति जो उपयोगकर्ता को अनुमति देती है पर कोई पता-सीमा नहीं देती, ठीक यही स्क्रीन बनाती है।

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

लीज़ वास्तव में कहाँ से आती है

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

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

कुछ भी परखने से पहले लिख लें कि आपका परिनियोजन कौन-सा मॉडल इस्तेमाल करता है। ऑनलाइन विरोधाभासी सलाह में से आधी दूसरे को मान लेती है।

टनल चालू हो सकता है और फिर भी लीज़ गिरा सकता है

स्थापित नियंत्रण कनेक्शन साबित करता है कि बातचीत काम कर गई, यह नहीं कि टनल का डेटा दोनों दिशाओं में जाता है। DHCP आदान-प्रदान को डेटा पथ पार करने के लिए अनुरोध और उत्तर चाहिए, और वहीं एन्क्रिप्शन सेटिंग, VPN ज़ोन की नीति और MTU समस्याएँ रहती हैं।

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

घरेलू राउटर को फिर से चालू करना उसी श्रेणी में आता है। यह कभी-कभी लक्षण हटा देता है, पर यह नहीं बताता कि लीज़ क्यों विफल हुई, और समस्या अगले कनेक्शन पर लौट आती है।

लीज़ के रास्ते को क्रम से चलें

एडाप्टर से शुरू करें और बाहर की ओर बढ़ें, ताकि हर चरण केवल एक कारण से विफल हो सके:

> Get-NetAdapter | Where-Object Name -like "*GVC*"
> ipconfig /all | findstr /i /c:"GVC" /c:"IPv4" /c:"DHCP"
> Test-NetConnection 10.60.0.1 -Port 443

169.254.x.x जैसा पता का मतलब है कि एडाप्टर मौजूद है और उसे कोई उत्तर नहीं मिला, जो लीज़ के स्रोत या डेटा पथ की ओर इशारा करता है। VPN सीमा में सही पता पर गलत DNS प्रविष्टियाँ दूसरी खराबी है: लीज़ काम कर गई और नीति ने अधूरी सेटिंग दीं। जो एडाप्टर कभी दिखाई ही नहीं देता, उसका मतलब है कि क्लाइंट उसे बनाने तक नहीं पहुँचा।

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

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