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

কেন সিক্রেট কখনো যাচাই হয় না

PPP প্রমাণীকরণ নেগোশিয়েট হয়: সার্ভার পদ্ধতি প্রস্তাব করে, ক্লায়েন্ট যা পারে তা দিয়ে উত্তর দেয়, এবং কোনো ক্রেডেনশিয়াল বিনিময়ের আগেই দুপক্ষ একটি পদ্ধতিতে মিলে যায়। যখন সার্ভার কেবল EAP-PEAP দেয় আর ক্লায়েন্টের pppd তা প্রয়োগ করে না, তখন কথাবার্তা প্রস্তাবের পর্যায়েই শেষ হয়। সার্ভার প্রমাণীকরণ ব্যর্থতা লিপিবদ্ধ করে কারণ ব্যর্থ হয়েছে সেই পর্যায়, পাসওয়ার্ড মিলিয়ে অপর্যাপ্ত পাওয়া গেছে বলে নয়।

এই কারণেই ভুল পাসওয়ার্ড আর পদ্ধতির অমিলে ত্রুটিটি একই। কেবল লগই এদের আলাদা করে, আর তা-ও কেবল যদি ক্লায়েন্টকে বিস্তারিত আউটপুট দেওয়ার অনুমতি থাকে।

নেগোশিয়েশন পড়ুন, শেষ ত্রুটি নয়

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

sudo pppd call provider debug nodetach

ওই আউটপুটটি রেখে দিন। এটি নেটওয়ার্ক মালিকের সার্ভার নীতি বদলানোর আগে প্রয়োজনীয় প্রমাণও, এবং পাসওয়ার্ড আদৌ কাজে ছিল কি না সেই প্রশ্নটির মীমাংসাও করে।

দ্বিতীয় কারণ লুকিয়ে আছে সিক্রেট ফাইলে

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

sudo cat -A /etc/ppp/chap-secrets

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

সার্ভারটি কার, তা দেখে সমাধান বাছুন

সার্ভারটি যদি আপনার হয়, ওই অ্যাকাউন্টের জন্য MSCHAPv2 অনুমোদন করা সবচেয়ে ছোট পরিবর্তন, এবং আপনি সচেতনভাবে দুর্বলতর পদ্ধতি মেনেছেন তা লিখে রাখা উচিত। যদি এটি অন্যের হয়, তবে EAP-PEAP প্রয়োগ করা ক্লায়েন্টই সৎ সমাধান; pppd প্যাচ করা অসঙ্গতিটিকে আপনার রক্ষণাবেক্ষণের সমস্যা বানায়। প্রোটোকল বাছাই যদি এখনো খোলা থাকে, PPTP ডিজাইনের সবচেয়ে দুর্বল অংশ এবং মাইগ্রেশন সাধারণত প্যাচ করা ক্লায়েন্ট বাঁচিয়ে রাখার চেয়ে সস্তা। প্রোফাইলের পাশে সেই সিদ্ধান্ত লিখে রাখুন যাতে পরের ব্যক্তি এটি আবার না খোলে।

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

সম্পর্কিত নিবন্ধ