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% पर रुकता है, तो विक्रेता का नोट अब इसे समझाता नहीं और लॉग आपका अगला साक्ष्य है। लक्षण का इलाज बंद करें और चरण-काउंटर पर लौटें।