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% मा रोकिन्छ भने विक्रेताको टिप्पणीले अब यसको व्याख्या गर्दैन र लग तपाईंको अर्को प्रमाण हो। लक्षणको उपचार गर्न छोड्नुहोस् र चरण-काउन्टरमा फर्कनुहोस्।