L2TP/IPsec PSK প্রত্যাখ্যাত: আগে ডায়ালগ, তারপর ফাইলগুলো দেখুন

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

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

ডায়ালগ থেকেই শুরু করুন, কিন্তু ক্ষেত্রটিকে বিশ্বাস করবেন না

সংযোগের IPsec ট্যাব খুলে কী-টি পেস্ট না করে আবার টাইপ করুন। চ্যাট বার্তা, PDF বা পাসওয়ার্ড ম্যানেজার থেকে কপি করা কী-এর শেষে এমন লাইন ব্রেক থাকতে পারে যা ক্ষেত্র দেখায় না, আর দেখা যাওয়া অক্ষরগুলো তখনও ঠিক দেখায়।

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

কী-টি যদি লম্বা লাইন মোড়ানো টিকিট সিস্টেম থেকে আসে, তবে যে চ্যানেল লাইন মোড়ায় না সেটি দিয়ে চেয়ে নিন। দুটি স্ট্রিং পাশাপাশি দেখার বদলে দৈর্ঘ্য অ্যাডমিনিস্ট্রেটরের সাথে মিলিয়ে নিন; মোড়ানোর জায়গায় হারানো অক্ষর সমানুপাতিক ফন্টে অদৃশ্য।

/etc/ipsec.d-এ কী-টির পথ অনুসরণ করুন

প্লাগইন কখনও PSK-টি IPsec ডেমনকে কমান্ড লাইনের আর্গুমেন্ট হিসেবে দেয় না। বরং এটি মানটি একটি সিক্রেট ফাইলে রাখে এবং ডেমন যাতে সেই ফাইলটি টেনে নেয় তা ব্যবস্থা করে, প্রয়োজনে /etc/ipsec.secrets-এ একটি include লাইন যোগ করে। ডায়ালগ যা ধরে রাখে তা ওই তৈরি হওয়া ফাইলের ইনপুট, ব্যবহারে থাকা মান নয়।

কিছু বদলানোর আগে দেখে নিন কী কী আছে:

ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets

পুরোনো প্লাগইন সংস্করণগুলো প্রতি সংযোগে একটি ফাইল লিখত, সংযোগের UUID দিয়ে নামকরণ করা, উদাহরণস্বরূপ /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets। অ্যাপলেটে প্রোফাইল মুছে ফেললে সেই ফাইলটি নির্ভরযোগ্যভাবে মুছে না। আগের সার্ভারের পুরোনো ফাইল যদি এখনও ডিস্কে থাকে এবং এখনও অন্তর্ভুক্ত থাকে, তবে ডেমন এমন সিক্রেট বেছে নিতে পারে যা আপনি আর ব্যবহার করেন না এমন প্রোফাইলের, আর দৃশ্যমান ক্ষেত্র ঠিক থাকা সত্ত্বেও সংযোগ ব্যর্থ হয়।

1.2.12 পরিবর্তন আপগ্রেডে কী করেছিল তা বুঝুন

প্লাগইন সংস্করণ 1.2.12 প্রতি-সংযোগ সিক্রেট ফাইলগুলোকে একটি একক ভাগ করা ফাইলে বদলে দেয়, /etc/ipsec.d/ipsec.nm-l2tp.secrets। আপগ্রেড পুরোনো প্রতি-UUID ফাইলগুলো পরিষ্কার করে না, আর বিদ্যমান include /etc/ipsec.d/*.secrets লাইন এখনও সেগুলো টেনে আনে। সংস্করণ 1.2.16 ডিফল্ট প্রস্তাব পরিচালনা বদলেছে, সিক্রেট বিন্যাস নয়।

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

স্টোরেজ বিন্যাস যেসব অক্ষর ধরে রাখতে পারে না সেগুলো আলাদা করুন

ভাগ করা সিক্রেট স্ট্রিংয়ের জন্য strongSwan ডকুমেন্টেশন বলে যে মানটিতে নতুন লাইন বা ডাবল-কোট অক্ষর থাকতে পারে না। নথি থেকে পেস্ট করা কী সাধারণ ডায়ালগে কোনো দৃশ্যমান পার্থক্য ছাড়াই দুটোর যেকোনোটি বহন করতে পারে।

1.2.12 থেকে সংরক্ষিত মান আর সাধারণ টেক্সট নয়। প্লাগইন ফাইলে পৌঁছানোর আগে PSK-টি base64-এ এনকোড করে, আর রিলিজ নোট সেই এনকোডিংকেই কারণ হিসেবে দেখায় যে ডাবল কোট এখন কী-তে গ্রহণযোগ্য। তাই ক্ষেত্রে টাইপ করা কোট উপস্থাপনযোগ্য; প্রতিটি নিয়ন্ত্রণ অক্ষরের ক্ষেত্রে তা সত্য নয়।

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

কোন প্রমাণীকরণ স্তর ব্যর্থ হয়েছে তা পড়ুন

প্রথমে ipsec --version চালান, কারণ strongSwan ও Libreswan ভিন্ন ফাইলনাম ও সিনট্যাক্স ব্যবহার করে, আর একটির জন্য দেওয়া পরামর্শ অন্যটির ক্ষতি করতে পারে। তারপর ক্লায়েন্টের বার্তা বা ডেমন লগ থেকে ব্যর্থতার স্তরটি পড়ুন: প্রি-শেয়ার্ড কী নিয়ে অভিযোগ প্রত্যাখ্যাত ব্যবহারকারীনাম ও পাসওয়ার্ডের চেয়ে ভিন্ন ঘটনা।

PSK টানেলের প্রান্তগুলোকে প্রমাণীকরণ করে। ব্যবহারকারীনাম ও পাসওয়ার্ড L2TP-এর ভিতরের ব্যক্তিকে প্রমাণীকরণ করে, আর IPsec অ্যাসোসিয়েশন ওঠার পর PPP সেগুলো সামলায়। সঠিক PSK-সহ ভুল অ্যাকাউন্টও ব্যর্থ হয়, আর অ্যাকাউন্ট বদলালে এমন কী মেরামত হবে না যা ডেমন কখনও ঠিকভাবে পড়েনি।

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