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 ची टीप अनेक वेगळ्या शाखा सूचीबद्ध करते, आणि तिचे जुने स्क्रीनशॉट सध्याचा मेनू नकाशा म्हणून वाचू नयेत. तुम्ही पोहोचलेल्या टप्प्याची पुष्टी करण्यासाठी ते वापरा, संपूर्णपणे लागू करण्याची तपासणी यादी म्हणून नाही.