IP ঠিকানাসহ ত্রুটি 868? Windows আগে কী সমাধান করে

ডায়ালগ জানায় সার্ভারের নাম সমাধান করা যায়নি, অথচ আপনি যে প্রোফাইল ক্ষেত্রটির দিকে তাকিয়ে আছেন সেটি একটি ঠিকানা। এই মিলটি বিরোধ নয়: ক্লায়েন্ট এমন কিছু সমাধান করছে যা আপনি ভাবছেন সে পড়ছে তার চেয়ে আলাদা। DNS ভাঙা বলে সিদ্ধান্তে পৌঁছানোর আগে সে আসলে কোথায় ডায়াল করে তা বের করুন। ক্লায়েন্টের নিজস্ব ধাপগুলোর ক্রম আপনাকে বলে কোথায় দেখতে হবে।

ক্লায়েন্ট ডায়াল করার আগে একটি নাম সমাধান করে

Windows-এর নেটিভ VPN সংযোগ তার প্রোফাইল পড়ে, সার্ভার ঠিকানা সমাধান করে, টানেল শুরু করে এবং কেবল তারপর প্রমাণীকরণ করে। ত্রুটি 868 দ্বিতীয় ধাপের। পরের ধাপগুলো কখনো চলে না বলে, লুকআপ আগে ব্যর্থ হলে ডায়ালগটি শংসাপত্রের সমস্যার মতো দেখাতে পারে।

এই ক্রমটি কাজের, কারণ এটি পরীক্ষা করার স্তর সংকুচিত করে। একই প্রোফাইল যখন একটি নেটওয়ার্ক থেকে কাজ করে আর অন্য থেকে ব্যর্থ হয়, তখন পার্থক্য সাধারণত নাম সমাধান, টানেলের ধরন বা অ্যাকাউন্ট নয়। যে জায়গায় ব্যর্থতা ঘটে সেখানে লুকআপ পরীক্ষা করুন, প্রোফাইল যেখানে তৈরি হয়েছে সেখানে নয়।

কোন নাম, যখন ক্ষেত্রটি ঠিকানা দেখায়

প্রদর্শিত নামের বদলে সংরক্ষিত মানটি পড়ুন। সংযোগের লেবেল তার সার্ভার ঠিকানা নয়, আর কাছাকাছি লেবেলের দুটি এন্ট্রি আপনাকে ভুলটির পেছনে পাঠায়:

Get-VpnConnection -Name "Work VPN" |
    Select-Object Name, ServerAddress, TunnelType

প্রোফাইলটি যদি সব ব্যবহারকারীর জন্য প্রস্তুত করা হয়, তবে সেই পরিসরও জিজ্ঞাসা করুন -AllUserConnection। তারপর কমান্ডটি যে মান ছাপিয়েছে ঠিক সেটিই সমাধান করুন, যে নেটওয়ার্কে ব্যর্থতা ঘটে সেখান থেকে। অপারেটরের নথিভুক্ত গেটওয়ে ব্যবহার করুন, অভ্যন্তরীণ অ্যাপ্লিকেশন নাম নয় যা কেবল টানেল ওঠার পরে সমাধান হয়। সেই দ্বিতীয় কোয়েরি প্রত্যাশিত কারণে ব্যর্থ হয় এবং ডায়াল সম্পর্কে আপনাকে কিছুই বলে না:

Resolve-DnsName vpn.example.com

সংরক্ষিত মান সত্যিই সংখ্যাসূচক হলে, ক্লায়েন্ট আর কোথায় নাম পড়ে তা খুঁজুন। একটি EAP কনফিগারেশন সার্ভারের উল্লেখ করতে পারে, অন্য সরঞ্জাম থেকে আমদানি করা প্রোফাইল নিজের মান বহন করতে পারে, আর আগের ইনস্টলার পেছনে একটি নকল এন্ট্রি রেখে যেতে পারে। ডায়ালগের ক্ষেত্রটি সবসময় একমাত্র ইনপুট নয়।

Windows 7 পুনঃসংযোগের ধরন

এই ত্রুটির পেছনের থ্রেডটি এমন মেশিনের কথা বলে যেগুলো একবার সংযুক্ত হয়েছিল এবং পরে 868 নিয়ে ব্যর্থ হয়েছে, অথচ প্রোফাইলে কিছুই বদলায়নি। অবদানকারীরা জানিয়েছেন যে Remote Access Connection Manager পরিষেবা পুনরায় চালু করা বা সাইন আউট করে আবার সাইন ইন করা সংযোগটি সাময়িকভাবে ফিরিয়ে দিয়েছিল। এগুলো প্রতিকার নয়, প্রমাণিত মূল কারণ নয়।

সেই ধরনটিকে আলাদা অনুমান হিসেবে ধরুন। পুনরায় চালু করা ক্লায়েন্টের অবস্থা রিসেট করে, তাই পরে সাময়িক সাফল্য DNS রেকর্ড ভুল ছিল বলে প্রমাণ করে না:

সারণিটি রোগনির্ণয় নয়, বরং পার্থক্যকারী পর্যবেক্ষণের সেট হিসেবে পড়ুন। প্রথম সারি নামের সমস্যা, দ্বিতীয়টি ক্লায়েন্টের অবস্থা, আর তৃতীয়টি এমন প্রোফাইল যা কখনো সঠিক ছিল না। প্রতিটি ভিন্ন মানুষ ও ভিন্ন সমাধানের দিকে নিয়ে যায়।

প্রশাসকের জন্য কী সংগ্রহ করবেন

প্রোফাইলের নাম, সংরক্ষিত ঠিকানা, টানেলের ধরন, ক্লায়েন্ট যে নেটওয়ার্কে ছিল এবং ব্যর্থতা সংযোগ বিচ্ছেদের পরে ঘটেছে কি না তা লিখে রাখুন। সেই রেকর্ডটি কাউকে অনুমান করতে না দিয়েই সত্যিকারের লুকআপ ব্যর্থতাকে ঐতিহাসিক পুনঃসংযোগ আচরণ থেকে আলাদা করে। চেষ্টার আশপাশের ক্লায়েন্ট ইভেন্ট লগও রেখে দিন।

পুরোনো বিল্ডের প্রতিকারটি প্রমাণ যে আচরণটি ছিল, এই প্রতিশ্রুতি নয় যে একই পরিষেবা পুনরায় চালু করলে বর্তমান মেশিন ঠিক হবে। নথিভুক্ত হোস্টনামের বদলে আক্ষরিক ঠিকানা বসানোও মেরামত নয়।

কিছু প্রোফাইল কনফিগার করা নামের সঙ্গে মিলে এমন সার্ভার পরিচয় আশা করে, তাই সংখ্যাসূচক প্রতিকার একটি ত্রুটির বদলে অন্য ত্রুটি ডেকে আনতে পারে। নাম থাকতেই হলে প্রোফাইল লেখা নয়, সমাধানের পথ ঠিক করুন। যেভাবেই হোক, কী বদলেছেন এবং কেন তা লিখে রাখুন।