L2TP/IPsec ব্যর্থ: IPsec, টানেল প্রমাণীকরণ নাকি PPP লগইন আলাদা করুন

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

তিনটি প্রমাণীকরণ ধাপ, তিনটি ভিন্ন পরিচয়

IPsec প্রমাণ করে প্রান্তগুলির মালিক কে, একটি পূর্ব-শেয়ার করা কী বা সার্টিফিকেট দিয়ে। সেই পরিচয় মেশিন বা গেটওয়ের, কখনও কিবোর্ডের সামনের মানুষের নয়। যখন পিয়াররা এই ধাপে একমত হতে পারে না, তখন কোনো L2TP প্যাকেট আদান-প্রদানই হয় না।

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

RFC 2661 সেই নিয়ন্ত্রণ-সংযোগ প্রমাণীকরণকে ঐচ্ছিক করে, যা ব্যাখ্যা করে একই ভুল দুটি সার্ভারে ভিন্ন লক্ষণ কেন দেয়। যে ডিপ্লয়মেন্ট কখনও টানেল গোপন তথ্য সেট করেনি সেটি ধাপটি সম্পূর্ণ এড়িয়ে যায়; যে একপাশে সেট করেছে সেটি PPP প্রস্তাবিত হওয়ার আগেই ব্যর্থ হয়। তারপর PPP ব্যবহারকারীকে PAP, CHAP বা MSCHAPv2 দিয়ে প্রমাণীকরণ করে এবং নামটি এমন একটি অ্যাকাউন্ট স্টোরে দেয় যা স্থানীয়, chap-secrets-এ, বা RADIUS-এ থাকতে পারে। সেই মুহূর্তে ভুল পাসওয়ার্ড আপনাকে কাজ করা টানেল আর ব্যর্থ সেশন নিয়েই রেখে দেয়।

কনফিগ সম্পাদনা করার আগে থামার বিন্দুটি পড়ুন

ipsec --version দিয়ে শুরু করুন যাতে জানেন স্ট্যাটাস আউটপুট strongSwan-এর না Libreswan-এর। তারপর ক্লায়েন্ট ডায়ালগ নয়, সার্ভার লগ পড়ুন, কারণ কোন ধাপ অস্বীকার করেছে তা সার্ভারেই লিখিত থাকে।

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

কী উপাদান ও পাসওয়ার্ড সেই পেস্টের বাইরে রাখুন; ধাপের নামই কাজটি চালায়, আর ফাঁস হওয়া পূর্ব-শেয়ার করা কী আরও খারাপ পরিণতিতে টিকেটটি আবার খুলে দেয়।

ধাপ এক: IPsec-এর কি অ্যাসোসিয়েশন আছে?

strongSwan-এ ipsec statusall অথবা Libreswan-এ ipsec whack --status চালান এবং শূন্য নয় এমন কাউন্টারসহ প্রতিষ্ঠিত চাইল্ড অ্যাসোসিয়েশন খুঁজুন। ip xfrm state উভয় ক্ষেত্রেই কার্নেলের দৃশ্য দেখায়। কাউন্টার বাড়তে থাকা ইনস্টল করা SA জোড়া মানে প্রথম ধাপ শেষ এবং আপনি এগোতে পারেন।

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

অ্যাসোসিয়েশন অনুপস্থিত থাকতেই থামুন। সেই মুহূর্তে PPP অপশন সম্পাদনা কিছুই বদলায় না এবং পরের ব্যক্তির কাছ থেকে আসল ত্রুটিটি লুকিয়ে রাখে।

ধাপ দুই: L2TP নিয়ন্ত্রণ সংযোগ কি প্রমাণীকরণ করেছে?

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

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

কেবল যে সেশন PPP নিয়ে দরকষাকষি শুরু করে সেটিই সত্যিই টানেল ধাপ পেরিয়েছে।

ধাপ তিন: PPP কি অ্যাকাউন্ট প্রত্যাখ্যান করছে?

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

Linux সার্ভারে ডেমন PPP-কে যে অপশন ফাইল দেয়, সাধারণত /etc/ppp/options.xl2tpd, সেটি দেখুন এবং কোন পদ্ধতি গৃহীত হয় ও অ্যাকাউন্ট কোথায় সমাধান হয় তা নিশ্চিত করুন। যে নাম RADIUS-এ আছে কিন্তু স্থানীয় সিক্রেট ফাইলে নেই সেটি পরিষ্কারভাবে ব্যর্থ হয় এবং খারাপ পাসওয়ার্ডের মতো দেখায়। তারপর দেখুন ক্লায়েন্ট এমন পদ্ধতি দিচ্ছে কি না যা সার্ভার গ্রহণ করে, বরং আরও শক্তিশালী কোনো পদ্ধতি নয় যা সার্ভার দরকষাকষি করতে অস্বীকার করে। এই ধাপ সারাতে পূর্ব-শেয়ার করা কী বদলানো একটি দুপুর নষ্ট করে এবং কিছুই বদলায় না।

সেশনটি অবশেষে উঠলে, ঠিকানা বণ্টন, DNS ও রুট এখনও অপরীক্ষিত, এবং প্রত্যেকটি নিজের মতো নিঃশব্দে ব্যর্থ হয়। নোটে তিনটি স্তর আলাদা রাখুন: সঠিক কী আর ভুল অ্যাকাউন্ট সবসময় ব্যর্থ হয়, আর একটি স্তর সারানো কখনও অন্য স্তর সারায় না।