FortiClient 98% वर अडकतो: त्या अडॅप्टरवर IPv6 बंद करा

बार 98% पर्यंत पोहोचतो, क्लायंट तिथेच बसतो, आणि पासवर्ड पुन्हा टाइप केल्याने काहीही बदलत नाही. हाच उपयुक्त सुगावा: क्लायंटने आधीच गेटवेचे प्रमाणपत्र स्वीकारले, क्रेडेन्शियल्स पाठवली आणि टनेल कॉन्फिगरेशन मिळवले. उरलेले आहे व्हर्च्युअल अडॅप्टर उचलणे आणि टनेल ट्रॅफिक वाहतो याची खात्री करणे. जेव्हा ते शेवटचे पाऊल कधीच पूर्ण होत नाही, तेव्हा दोष स्थानिक असतो, आणि क्रेडेन्शियल्स कितीही वेळा टाइप केली तरी तिथवर पोहोचत नाहीत.

चार पायऱ्या, आणि पहिली बार नाही तर लॉग वाचणे आहे.

98% काउंटर प्रत्यक्षात काय नोंदवतो

टक्केवारी क्लायंटचा स्वतःचा टप्पा-काउंटर आहे, थ्रूपुटचे माप नाही. प्रत्येक प्रयत्नात त्याच संख्येवर अडकणे म्हणजे क्लायंट विशिष्ट टप्प्यावर पोहोचून वाट पाहत आहे; म्हणूनच संथ कनेक्शन आणि अडकलेला क्लायंट लॉगमध्ये वेगळे दिसतात. क्रेडेन्शियल्सची समस्या शांत खंडाऐवजी क्रेडेन्शियल त्रुटी छापली असती.

Fortinet ने हे लक्षण क्लायंट-बाजूच्या एकाच कारणाशी नोंदवले: क्लायंट वापरत असलेल्या अडॅप्टरवर IPv6 सक्षम असणे. यामुळे अडॅप्टर सेटिंग पहिली तपासण्याची गोष्ट बनते, प्रत्येक SSL-VPN अडकण्यासाठी सार्वत्रिक स्पष्टीकरण नाही.

पायरी 1: बारच्या आधी लॉग वाचा

काहीही बदलण्यापूर्वी अडकण्याच्या लगेच आधीच्या ओळी टिपून घ्या. टनेल अडॅप्टर तयार झाला का, पत्ता नेमला गेला का, आणि क्लायंटने पत्ता-कुटुंबाची वाट पाहणे सोडले का हे तुम्ही पाहत आहात. वेगळ्या टक्केवारीवर अडकणे हा स्वतःच्या निदानासह वेगळा टप्पा आहे, आणि प्रमाणपत्र इशारा किंवा चुकीचा गेटवे पत्ता शांत वाटपाहण्याऐवजी स्वतःचा संदेश देतो. वेळ-शिक्का लिहून ठेवा, कारण पुढचा प्रयत्न त्याच फाइलमध्ये अजून एक ब्लॉक जोडतो.

लॉग पूर्ण झालेले लॉगिन आणि त्यानंतर काहीही नाही असे दाखवत असेल, तर तुम्ही स्थानिक सेटअपमध्ये आहात आणि अडॅप्टर वैध संशयित आहे.

पायरी 2: IPv6 बदल एका अडॅप्टरपुरता मर्यादित करा

बदल अडॅप्टरचा आहे, मशीनचा नाही. Windows अडॅप्टर गुणधर्मांमध्ये याचा अर्थ विशिष्ट इंटरफेसवर Internet Protocol Version 6 (TCP/IPv6) काढून टाकणे, आणि शेलमधून ते Disable-NetAdapterBinding -Name "Ethernet 2" -ComponentID ms_tcpip6. पुन्हा कनेक्ट होण्यापूर्वी Get-NetAdapterBinding -ComponentID ms_tcpip6 ने स्थितीची खात्री करा. नंतर पुन्हा कनेक्ट व्हा आणि बार तिथे न थांबता 98% ओलांडतो का ते पहा.

आधी व्याप्ती ठरवा, नंतर चाचणी करा. IPv6 जागतिक पातळीवर बंद करणे प्रश्नाच्या गरजेपेक्षा मोठा बदल आहे आणि तुम्हाला स्पर्श करायचा नव्हता अशा सेवांवर परिणाम करतो.

पायरी 3: अडकणे काय लपवत होते ते तपासा

जोडणारा टनेल काम करणारा टनेल नाही. क्लायंटने नेमलेला पत्ता, प्रोफाइलने इन्स्टॉल केलेले मार्ग, आणि एका अंतर्गत होस्टसाठी नाव-निराकरण तपासा: Resolve-DnsName files.corp.example. जोडतो पण काहीच सोडवत नाही असा क्लायंट DNS समस्या असलेला असतो, आणि तेच दोष परत येत आहे असे चुकीचे वाचणे सोपे आहे.

एक अंतर्गत संसाधन नावाने आणि एक सार्वजनिक गंतव्य चाचणी करा, जेणेकरून तुटलेला स्प्लिट टनेल दुरुस्त झालेला क्लायंट समजला जाऊ नये.

पायरी 4: दुरुस्ती पुनरावृत्तीयोग्य करा

सेटिंग संपूर्ण फ्लीटपर्यंत पोहोचायचे असेल, तर प्रत्येक लॅपटॉपवर पुनरावृत्ती होणाऱ्या हाताने करायच्या पायरीऐवजी ते डिप्लॉयमेंट पॅकेजमध्ये किंवा अडॅप्टर कॉन्फिगरेशनमध्ये ठेवा. तिकिटात नोंदवा की 98% अडकणे नेटवर्क इंटरफेसवरील IPv6 शी जोडलेले होते, आणि कोणीतरी असंबंधित गोष्ट दुरुस्त करण्यासाठी ते पुन्हा सक्षम करण्यापूर्वी होस्टवर आणखी काय IPv6 वर अवलंबून होते ते नोंदवा.

फक्त एका अभियंत्याच्या स्मरणात असलेली दुरुस्ती पुढच्या तिमाहीत परत येणारी दुरुस्ती आहे.

IPv6 बंद असतानाही बार 98% वर थांबत असेल, तर विक्रेत्याची टीप आता ते स्पष्ट करत नाही आणि लॉग हा तुमचा पुढचा पुरावा आहे. लक्षणावर उपचार करणे थांबवा आणि टप्पा-काउंटरकडे परत जा.