কেন কেবল PPP CHAP MPPE-এর প্রয়োজন মেটাতে পারে না

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

একটি PPTP সংযোগের ভেতরে দুটি আলোচনা চলে

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

সাধারণ CHAP হলো RFC 1994-এর চ্যালেঞ্জ-প্রতিক্রিয়া বিনিময়, যা কেবল একটি ভাগ করা গোপন তথ্যের উপর গড়া। MS-CHAPv2 ভিন্ন বার্তা ও ভিন্ন আউটপুটসহ আরেকটি বিনিময়, যা RFC 2759-এ মানকৃত। দুটি নামের ভাগ করা শব্দটিই তারের উপর তাদের একমাত্র মিল। কোনও নামই বলে না বিনিময়টি কী তৈরি করে, অথচ এটিই একমাত্র গুরুত্বপূর্ণ অংশ।

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

প্রয়োজনীয় পদ্ধতিকে তার উৎপাদনযোগ্য কী-এর সঙ্গে মিলিয়ে নিন

MPPE কী সাধারণভাবে PPP-এর বৈশিষ্ট্য নয়। Microsoft CHAP পরিবারের জন্য উদ্ভব পদ্ধতিটি RFC 3079-এ নির্ধারিত, এবং এটি ভাগ করা গোপন তথ্য নয়, MS-CHAP বিনিময়ের আউটপুট ইনপুট হিসেবে নেয়। EAP পদ্ধতিগুলো ভিন্ন পথে একই জায়গায় পৌঁছায়, যেখানে প্রমাণীকরণ সার্ভার কী-গুলো MS-MPPE-Recv-Key ও MS-MPPE-Send-Key অ্যাট্রিবিউট হিসেবে ফেরত দেয়। সাধারণ CHAP কোনও পথেই আসে না, আর এই অমিল থাকার পুরো কারণ সেটাই।

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

এরপরের নিয়মটি সংক্ষিপ্ত: প্রোফাইল যদি MPPE দাবি করে, পদ্ধতিকে হতে হবে MS-CHAP-এর একটি রূপ বা এমন EAP পদ্ধতি যার কী সার্ভার ফেরত দেয়। কেবল MS-CHAPv2 প্রত্যাখ্যান করলে তা নিশ্চিত হয় না, কারণ MS-CHAPv1-ও কী উদ্ভাবন করে এবং আলাদাভাবে প্রত্যাখ্যান না করলে উপলব্ধ থাকে; দুটিই প্রত্যাখ্যান করলে সাধারণ CHAP ও PAP থাকে, যারা কিছুই উদ্ভাবন করে না এবং দাবিটিকে অসম্পাদনীয় করে তোলে। আপনি যা পছন্দ করেন না তা তালিকাভুক্ত করার বদলে গৃহীত পদ্ধতিটির নাম দিন। ক্লায়েন্ট সংযুক্ত করার জন্য এনক্রিপশন দাবি ছেড়ে দেওয়া মেরামত নয়, অবনমন।

ক্লায়েন্ট সম্পাদনার আগে সার্ভারের অপশন পড়ুন

এই অমিলগুলোর বেশিরভাগই সার্ভারে দুটি ফাইলে দৃশ্যমান, আর সেগুলো পড়া ক্লায়েন্ট নতুন করে বানানোর চেয়ে কম খরচ। Linux PPTP এন্ডপয়েন্টে প্রাসঙ্গিক সেটিংস থাকে pppd অপশন ফাইলে, যা pptpd পাস করে। এটি সার্ভারে চালান, ক্লায়েন্টের স্ট্যাটাস স্ক্রিন থেকে নয়। যে লাইনগুলো সুরক্ষা মোড দাবি করে, প্রত্যাখ্যান করে বা নাম দেয়, সেগুলো দিয়ে শুরু করুন:

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

আউটপুটটিকে ফ্ল্যাগের তালিকা নয়, চুক্তি হিসেবে পড়ুন। যে লাইন MPPE দাবি করে অথচ MS-CHAP-এর দুই রূপই প্রত্যাখ্যান করে, তা কোনও ক্লায়েন্টই মেটাতে পারে না, আর MS-CHAP পদ্ধতির দাবি না থাকলে কী-হীন বিনিময়ের দরজা খোলা থাকে। তারপর দেখুন কে আদৌ প্রমাণীকরণ করতে পারে, যা সিক্রেট ফাইল নির্ধারণ করে:

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

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

PPP পর্যায় অনুসারে ব্যর্থতা খুঁজুন

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

জার্নাল পর্যায়ের লাইনগুলো রাখে, আর সেগুলো উঁচু ডিবাগ স্তরের চেয়ে বেশি কাজে লাগে। PPP প্রসেস ও সুরক্ষা বার্তাগুলো চান, তারপর সবকিছুর আগে প্রমাণীকরণের ফল পড়ুন। শেষ লাইনগুলো সাধারণত প্রত্যাখ্যানকারী ধারার নাম বলে:

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

সেই আউটপুটে প্রথমে প্রমাণীকরণের ফল, তারপর সুরক্ষা দাবি করা হয়েছিল কিন্তু আলোচনা হয়নি—এমন অভিযোগ খুঁজুন। দ্বিতীয় বার্তাটি উপরের বিরোধের স্বাক্ষর, আর সার্ভার যতক্ষণ কী উৎপাদনে সক্ষম একমাত্র পদ্ধতি প্রত্যাখ্যান করে, ততবার আবার চেষ্টা করেও তা মুছে যায় না। দুটি ফাঁদ নাম দেওয়া দরকার: পর্যায়ের লাইন না পড়ে ডিবাগ স্তর বাড়ালে কোলাহল তৈরি হয়, আর চ্যালেঞ্জ উপাদান বা পাসওয়ার্ড ধরে রাখলে কনফিগারেশনের কাজটি ক্রেডেনশিয়াল ফাঁসে পরিণত হয়। কোনও অপশন বদলানোর আগে সেই পর্যায়টি লিখে রাখুন।

পুরোনো এন্ডপয়েন্ট বন্ধ হওয়ার আগে প্রস্থানের পরিকল্পনা করুন

MPPE একটি ঐতিহাসিক লিংক সুরক্ষা ব্যবস্থা, আর এর উপস্থিতি PPTP-কে নতুন স্থাপনার জন্য বুদ্ধিমান পছন্দ করে না। বর্তমান Microsoft নির্দেশিকা ইতিমধ্যেই নতুন রিমোট অ্যাক্সেস স্থাপনার জন্য PPTP এবং প্রি-শেয়ার্ড কীসহ L2TP/IPsec-এর বিরুদ্ধে পরামর্শ দেয়। একটি পুরোনো এন্ডপয়েন্ট জীবিত রাখা বিদ্যমান সেবা সম্পর্কে সিদ্ধান্ত, পরেরটির জন্য টেমপ্লেট নয়।

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

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