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%-এ থামে, তবে ভেন্ডরের টীকা আর এটি ব্যাখ্যা করে না এবং লগই আপনার পরের প্রমাণ। উপসর্গের চিকিৎসা বন্ধ করুন এবং ধাপ-কাউন্টারে ফিরে যান।