L2TP সংযুক্ত হয় কিন্তু PPP আলাপচারিতা ব্যর্থ: কোন পর্যায়?

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

টানেল কেবল প্রথম স্তর

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

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

শেষ যে পর্যায়টি সফল হয়েছে সেটি পড়ুন

লগটি সামনের দিকে হাঁটুন এবং প্রথম যে পর্যায়টি সম্পন্ন হয়নি সেখানে থামুন। প্রথমে LCP, তারপর প্রমাণীকরণ, তারপর IPv4 প্যারামিটারের জন্য IPCP।

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

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

টিকিটে পর্যায়ের নামের সঙ্গে লগের অংশটি একসঙ্গে রাখুন। পর্যায়ের সীমা ছাড়া পেস্ট করা লেজ পরের পাঠককে অনুমান করতে আমন্ত্রণ জানায়, আর এখানে অনুমান করতে এক ঘণ্টা লাগে।

ক্লায়েন্ট ও সার্ভারের মধ্যে সম্মতি

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

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

ঠিকানা যাচাই করুন, লগইন নয়

সম্পন্ন লগইন ব্যবহারযোগ্য সেশন নয়। IPCP ভেতরের ঠিকানা নিয়ে আলাপ করে, আর নিঃশেষিত পুল বা ক্লায়েন্টকে অস্বীকার করা নীতি সংযুক্ত টানেলকে রুট করার মতো কিছু ছাড়াই রেখে যেতে পারে।

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

আগে ভেতরের ঠিকানা দেখুন, তারপর আপনার সত্যিই প্রয়োজনীয় সম্পদের রুট ও রিজলভার। ভেতরের ঠিকানা কোনো ওয়েবসাইট যে পাবলিক এক্সিট জানায় তা নয়, আর দুটিকে গুলিয়ে ফেললে মানুষ নেই এমন লিক খুঁজতে যায়। ব্যক্তিগত সম্পদ নামে পরীক্ষার আগে ঠিকানায় পরীক্ষা করুন, যাতে DNS ব্যর্থতা রাউটিং ব্যর্থতা বলে ভুল না হয়।

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